Hi Andrew,
On 9/2/2014 11:46 PM, Andrew Sullivan wrote:
On Tue, Sep 02, 2014 at 05:42:28PM -0700, Dan Chiba wrote:
usernames "fussball" and "fußball" should be treated as equal for case
insensitive matching, or as distinct for case sensitive matching.
I don't see any case in those two strings. What am I missing?
My bad, both of them are lowercase. My intent was to present two
distinct strings that are evaluated as equal in case insensitive
matching. "fussball" and "Fussball" would be good examples.
But anyway, it's not clear to me that the usernames "fussball" and
"fußball" should in fact always and everywhere be treated as equal.
In my understanding that is not always the case.
For my understanding is that the use of ß is very much a localization
issue: the ligature is never used in Swiss written German. One could
argue that it'd be extremely unwise to permit distinct user
registrations that are otherwise identical except for ss and ß
(certainly I would). But if we think that's a good reason to insist
on a mapping, then that would also seem to be a good reason to say,
"No case folding, period." Indeed, that's one of the big differences
between IDNA2003 and IDNA2008; IDNA2008 violates a deep tradition in
the DNS in this way, basically because we couldn't make the mapping
work the way we'd like.
I used the ß character as a case in which distinct strings are to be
evaluated equal after precis preparation. I think it is a good idea to
disallow confusable characters like this. I do not know the background
of IDNA well, but I think there could be a precis profile for it.
username string matching. If the profile doesn't fully specify the spec but
it's up to the deployment/service policies, I would like the components to
be able to identify the policies precisely.
While I agree with that in principle, it sounds like an
interoperability and implementation nightmare (which issue is, I
think, what got us the current compromise text).
I am concerned about interoperability problems that may happen due to
the ambiguity in the profile spec. Right now, an implementation of
UsernameIdentifierClass may use arbitrary character mappings. I agree
the compromise was required, but I think it has introduced the problems
while partially resolving the other requirement to match the various
current practices of mapping some characters in username handling.
Best regards,
Dan
Best regards,
A
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
