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