Bruce Lilly a dit :
RFC 1958 says
that names "should be in case-independent ASCII". Case-independence
is a compatibility issue that would need to be addressed (e.g. by
noting that newgroups SHOULD be recognized in a case-independent
manner, but MUST be generated in lower-case only (for backward
compatibility), with a note that a subsequent editions of the standard
are expected to require case-independent recognition and permit
arbitrary case in generation).
The ASCII in "case-independant ASCII" is an extremly important part.
When the name is not ASCII, the case-independance rules are ultimately
dependant on the locale used.
Case-independance for non-ASCII strings is a bad idea.
It a whole can of worms there.
What's the IETF policy here ? I haven't seen it discussed yet.
For me, the good thing is to either :
- give up case-independance for things that are not restricted to ASCII
- make this a ASCII restricted case-independance, ie case-independance
only applies to characters that are part of the ASCII repertoir.
The second choice will be surprising in some respects for unwarned people.
But if you try do better than this, you'll discover that there NO
absolute solution.
In my opinion, the first solution is better, to be used where ASCII is
the only authorised encoding, when the value belongs to a fixed list all
of which are ASCII, or when extension to the list are explicitly
restricted to never being anything but ASCII.
In the last case, someday someone will want to not only use ASCII, so
it's not a good idea to be case-independant.
I do not see a problem, within this context, on the other hand with
saying for exemple that the string "poster" will be recognized in all
variations of casing.