On Thu, Dec 11, 2014 at 08:50:53PM +0000, Viktor Dukhovni wrote: > I have a proposal that solves the ASCII use-case. Sadly, little > can be done for non-ASCII Unicode, those names will just have to > be used consistently by all parties.
Well, domains could publish the local-part canonicalization function they use, or, rather, a small index of well-known canonicalization functions. This is just a tweak to your proposal. You propose just two functions: identity and ASCII-tolower, with the client trying all [two] of them. If we add more functions we'll want to know which function the domain uses, so we'll need that one more lookup. We need just a handful of functions that will work for most cases. E.g., gmail treats periods as if they weren't there. That might need to be part of one ore more standard canon function(s). I realize that your proposal is simpler, and we might want to stop there. > For all-ASCII addresses, (ignoring for the moment Turkish case- > folding of "I" to a non-ASCII "dotless" "i"), the proposal is > as follows: What site would want to permit local-part names that are equivalent but for an i/dotless-i? I realize that the situation can have come up, but going forward a site might want to treat them as equivalents, and, really, to implement Unicode case-folding + some standard mappings, as the canonicalization, at least for SMIMEA purposes (the actual e-mail addresses understood by users as canonical might bear a dotless i even if for SMIMEA purposes it becomes a dotted i). > * Clients that encounter an ascii localpart that is not all lower-case > try both keys, first the localpart as-is, then case-folded with > the "@lower:" prefix. Almost there :) Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
