Subject: [EAI] The need for an ASCII Compatible Encoding (ACE) standard for email address internationalization outside of email protocols

From: "Chris Walker" <[email-masked]>
Date: Mon, 12 Nov 2007 11:06:04 -0700

-The need for an ASCII Compatible Encoding (ACE) standard for email 
address internationalization outside of email protocols-

Continuation of existing interoperability between entities that exchange 
email addresses drives the need for a standard ACE for internationalized 
email addresses outside of the domain of email protocols. Email 
addresses are currently stored, used, analyzed, and communicated over 
numerous ASCII based systems including but not limited to databases, 
fixed codepage legacy platforms such as mainframes, and text based batch 
processing. The number of ASCII based systems that still exist to this 
day are so numerous that calculating their number is not likely possible.

-Side effects of EAI and unintended consequences-

Internationalized Domain Names took an approach that applied an ACE, 
specifically punycode, to internationalized domain names.  RFC 3490 
states “Applications can use IDNA to support internationalized domain 
names  anywhere that ASCII domain names are already supported, including 
DNS master files and resolver interfaces.”  As a result, ASCII systems 
had a built-in and unambiguous method for handling internationalized 
domain names.  EAI on the other hand is taking a different approach, 
specifically UFT8 end to end, and as a result EAI does not provide ASCII 
systems a standard methodology for handling the local part of 
internationalized email addresses.

-Protocol owner responsibility-

As expressed in the IETF mission statement (RFC 3935): “Protocol 
ownership - when the IETF takes ownership of a protocol or function, it 
accepts the responsibility for all aspects of the protocol, even though 
some aspects may rarely or never be seen on the Internet.“

-Corporate systems are part of the internet-

Drawing from the IETF mission statement: “The Internet: A large, 
heterogeneous collection of interconnected systems that can be used for 
communication of many different types between any interested parties 
connected to it.  The term includes both the "core Internet" (ISP 
networks) and "edge Internet" (corporate and private networks, often 
connected via firewalls, NAT boxes, application layer gateways and 
similar devices).”

-Making the Internet work better-

Again drawing from the IETF mission statement:  “The goal of the IETF is 
to make the Internet work better. The mission of the IETF is to produce 
high quality, relevant technical and engineering documents that 
influence the way people design, use, and manage the Internet in such a 
way as to make the Internet work better.  These documents include 
protocol standards, best current practices, and informational documents 
of various kinds.”

The efforts of the EAI working group certainly will make the Internet 
work better in regards to sending and receiving internationalized email; 
however without setting a standard for the ACE representation of the 
local part of an internationalized email address they will make other 
parts of the Internet work worse than they do today. This burden could 
itself prevent the adoption of email address internationalization from 
occurring as rapidly as might be possible if the burden did not exist or 
was reduced.

________________________________________________________________________

       I therefore strenuously argue that providing a standard for the
       ACE representation of the local part of an internationalized email
       address for use OUTSIDE OF UTF8SMTP, SMTP, POP, and IMAP 
       is within the scope, the responsibility of, and in the best
       interest of the EAI working group.
        
________________________________________________________________________

Since the domain name part already has an ACE, only local part needs an 
ACE.

It is desirable to only provide a method for encoding the local part, as 
opposed to encoding the entire email address, to allow non email based 
systems to parse the domain part from the entire email address without 
having to decode the entire email address to access the domain part. 
This will also prevent systems from having to handle cases where the 
domain part is encoded multiple times.

Since code that implements the internationalized domain name ACE, the 
RFC 3490 ToASCII operation, uses nameprep and punycode, it would be 
sensible to consider using punycode as an ACE for the local part to 
eliminate the need for additional code that implements a second ACE for 
these systems.

The simplest non destructive, non lossy, method for conversion from a 
UTF8 local part to an ACE representation of the local part, and back 
again to the UTF8 representation, that maintains all the case, quoting, 
escaping, and specials characters of the original is desirable. As the 
name suggests: ASCII Compatible Encoding is just that, encoding, I am 
not suggesting that any functionality other than faithfully representing 
whatever may be encountered in the local part in an ASCII form. There is 
no intent that there is any check for the local part being valid or well 
formed.

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Yangwoo Ko <[email-masked]>
Date: Tue, 13 Nov 2007 10:15:29 +0900

Chris Walker wrote:
> (snip)
> (snip)

Let me understand your proposal more closely. What IETF RFCs are 
concerned with the usage of local parts "OUTSIDE OF UTF8SMTP, SMTP, POP, 
and IMAP"? I guess that this (or very similar) question was raised at 
apparea (or somewhere else) meeting during IETF 6?.