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

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 13 Nov 2007 04:15:25 +0800

Dear Chris Walker,
     If you fllow our EAI discussion throughtly, you may notice that this issue has been raised and discussed many times and has been solved by the EAI WG. As EAI mailing list, I noticed that you just join this mailing list. Could I suggest you to read more discussions about EAI in http://www1.ietf.org/mail-archive/web/ima/current/index.html .

Thanks a lot for your kind questions.

YAO Jiankang
     
----- Original Message ----- 
From: "Chris Walker" <[email-masked]>
To: "eai list" <[email-masked]>
Sent: Tuesday, November 13, 2007 2:06 AM
Subject: [EAI] The need for an ASCII Compatible Encoding (ACE) standard foremail address internationalization outside of email protocols

> -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
>

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