[Bug 15489] Add an attribute <input type=email idna> that allows IDNA e-mail addresses to be round-tripped

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489

--- Comment #25 from John C Klensin <john+w3cbugs@jck.com> ---
One more observation: it doesn't necessarily predict what is happening on the
browser, etc., side, but the way things seem to be evolving with email user
agents and transport, going out of one's way to support email with IDNs in the
domain part but not the local-part (LHS of the "@") is probably pointless.  It
will work if the domain part is exclusively ASCII (A-labels when needed), but
is probably a tad pointless.   Some peculiar situations aside, we haven't seen
much call for support of email to addresses with ASCII local-parts and IDNA
domain-parts (quite a bit more for the other combination with non-ASCII local
parts and conventional domain parts, actually).

If I understand the relationships, I think that argues for a new form type
(agreeing with Martin's 24 August 2012 note) that is a superset of what is
permitted by "email" and that, over time, will gradually supercede it.  The
theory, supported by the i18n email address ("EAI") specs cited above and the
way mail with UTF-8 addresses or headers is supported, is that halfway models
are just going to introduce errors and problem cases.  So, for mail headers and
addresses, it is strictly UTF-8: no alternate character sets, no "some headers
are ok and others aren't", "headers but not addresses",  and so on.  It can't
be enforced, but the intent is even to get rid of the email-specific ASCII
encoding called "encoded words".

FWIW, most IETF discussions about keywords have tended toward "i18n-email"
(actually a misnomer because of non-ASCII body parts), "SMTPUTF8" and
permutations, and so on.  Martin is right -- don't call or think about it as
IDN-email or IDNA-email.

It seems to me that the the other advantage of a new form type is that it
should be completely opaque to older (current) implementations.  An
implementation that supports the syntax and passing through what is necessary
to a conforming extended mail implementation recognizes it and does the right
thing; one that doesn't just sees it as an invalid form type.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 21 October 2013 21:22:22 UTC