On 3/2/10 10:45 AM, John Levine wrote: > > "The domain part of email addresses is already internationalized > > [RFC3490], while the local part is not." > > Right. There is a standard way to encode Unicode domain names, but > there is no standard way to represent email addresses with non-ASCII > local parts. EAI is working on it, slowly, and I think it would a > poor idea to attempt to guess what they might eventually send down > the standards track. EAI docs so far are experimental or > informational.
IDN is at the beginning of a dramatic change. As such, DKIM work should consider long term impacts. Soon there will be a proliferation of human Unicode input for both right and left hand portions of an email address. Does anyone really doubt that? To satisfy human desires of obtaining "equivalent" names, similar to ASCII case folding, UTF-8 to puny-code conversion is changing. As such, there is ongoing efforts to utilize name equivalency to deal with UTF-8 to puny-code conversion inconsistencies. Reasons have been offered in RFC 5242 and Unicode Technical Report #36, http://www.unicode.org/reports/tr36/ rule sets. Evolution of this process should also be expected to continue many years. > This means that in DKIM, the d= value is a domain, it's punycoded, > no question about that. The i= value has the syntax of an email > address, so its domain part is also punycoded. Agreed. But that does not mean headers communicating with human recipients will be in puny-code, or that input accepted from humans will be puny-code either. If that were the case, there would be little advantage in having IDNs. Newer name services already utilize UTF-8 for domain queries. As such, puny-code may someday become an interim solution. IEEE/EIA 12207.1-1997 and US Government 2007 CSR require systems to accommodate UTF-8. > But if the mailbox part is not ASCII, you're out of standards > territory. For the copied headers, they should all be in ASCII > already unless you're doing 8bit, but 8->7 downcoding will break a > lot more than the copied headers, so fugeddaboudit. There are methods to encode headers using ASCII which could be extended to include email-addresses. As such, DKIM should be able to play a role in the confirmation of "equivalent" names, in a manner similar to what might be used to authenticate third-party signers. Introduction of IDN will then be less disruptive when DKIM is able to accommodate an array of UTF-8 equivalent or alt names. > Basically, for non-ASCII domains, the solution is obvious, for > general non-ASCII mail addresses, we do what everyone else is doing > and wait for EAI. EAI has already produced a general framework. This framework, along with mailing-list issues, should be enough to justify having methods in DKIM to affirm related names. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
