Harald Alvestrand | 12 Nov 18:02 2007
Picon

[Fwd: EAI - Requested session has been scheduled for IETF 70]

Rescheduled for Wednesday.

            Harald

Picon
From: IETF Secretariat <agenda <at> ietf.org>
Subject: EAI - Requested session has been scheduled for IETF 70
Date: 2007-11-12 16:56:48 GMT
Dear Harald Alvestrand,

The sessions that you have requested have been scheduled.
Below is the scheduled session information followed by 
the information of sessions that you have requested.

EAI Session 1 (2 hours)
Wednesday, Morning Session I 0900-1130
Room Name: Salon 3
----------------------------------------------

Requested Information:

---------------------------------------------------------
Working Group Name: eai
Area Name: Applications Area
(Continue reading)

Chris Walker | 12 Nov 19:06 2007

The need for an ASCII Compatible Encoding (ACE) standard for email 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 
(Continue reading)

YAO Jiankang | 12 Nov 21:15 2007
Picon

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

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" <cw-eai-ietf <at> iespresio.com>
To: "eai list" <ima <at> ietf.org>
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.
> 
(Continue reading)

Yangwoo Ko | 13 Nov 02:15 2007
Picon

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


Chris Walker wrote:
> (snip)
>        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.
> (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?.
Chris Walker | 13 Nov 17:58 2007

Additional Clarification re: Need of an ACE for EAI

Additional Clarification re: Need of an ACE for EAI.

Having read the EAI working groups drafts, the Internet Mail Consortiums 
draft (prior to its dissolution in this process) and the EAI working 
group’s message archive going back to summer of 2006…

There were at several points in time in the past, where there were 
proposals to use ACE representation of the local part as a MEANS for 
implementing internationalized email addresses. That is, encode Unicode 
to ASCII at or very near to the user interface level, and transmit the 
ACE over SMTP then convert the ACE back to Unicode at or near the 
recipients user interface. This method for IMPLEMENTING the transmission 
of email has died, among the earliest and loudest arguments that this is 
not acceptable are:

The ACE representations will leak, as RFC 4952 now states

QUOTE If non-obvious encodings, such as protocol-specific ASCII-
Compatible Encoding (ACE) variants, are used,   the user will 
inevitably, if only occasionally, see them rather than "native" 
characters and will find that discomfiting or astonishing. ENDQUOTE

And the argument that interpreting the local part was only in the domain 
of the system(s) in the domain part of the email address, also from RFC 
4952 referencing RFC 2821 et al.

QUOTE This is the SMTP server that controls the format of the local 
parts of addresses and is permitted to inspect and interpret them. 
ENDQUOTE

(Continue reading)

Andrew Sullivan | 13 Nov 18:11 2007

Re: Additional Clarification re: Need of an ACE for EAI

On Tue, Nov 13, 2007 at 09:58:08AM -0700, Chris Walker wrote:

> There is no STANDARD for systems outside of email protocols that cannot 
> support Unicode to use for the encoding of internationalized email 
> addresses. 

In my opinion, to the extent that is true (and I note there is in fact
a fallback mechanism proposed -- see below), it's a feature.  In my experience, the
ability of non-IDNA-aware user agents (not to mention users!) to see
the "Punycode" version of the domain turns out to be a giant problem
for the non-geek set.  Some of them would rather the domain _not work_
than that people get a possibly confusing bunch of ASCII.

Explanations of why this backward compatibility was a good thing
have tended to elicit blank stares or else angry denunciations about
how computer geeks don't care about "real usability" in "the real world".

> Now along comes internationalized email addresses, now you have a 
> customer with Unicode in the local part of their email address, how do 
> you put that into your ASCII text file? Is there a standard for doing 

Isn't this what the ALT-ADDRESS is for?

A

--

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew <at> ca.afilias.info>                              M2P 2A8
jabber: ajsaf <at> jabber.org                 +1 416 646 3304 x4110
(Continue reading)

Harald Alvestrand | 13 Nov 19:11 2007
Picon

Re: Additional Clarification re: Need of an ACE for EAI

>
> What I am arguing is that as a result of not taking an ASCII encoding 
> route, and by taking the UTF8 over the wire route, the following is the 
> result of that decision.
>
> There is no STANDARD for systems outside of email protocols that cannot 
> support Unicode to use for the encoding of internationalized email 
> addresses. 
>  
> If ACE’ing of the local part was used as the method for email 
> transmission, then (as in the case of IDNA) the ACE representation would 
> be an obvious choice for use in ASCII systems. However there is no 
> ACE’ing of the local part, so there is no obvious standard for ASCII 
> systems.
>
>   
There's an argument to be made that the choice of the ACE mechanism (if 
any) actually depends strongly on the context of the usage.

For instance, if we ever get around to defining a Mailto:-like IRI, 
which will then support the UTF-8 encoding of EAI's mailbox names, then 
by the rules of converting IRIs to URIs, the logical "ACE" format for 
the corresponding mailto: URI would be the percent-escaped, hex-encoded 
string that corresponds to the UTF-8 byte sequence.

I'll be very surprised if I *ever* encounter a business card with such 
an address upon it, just as I've never (so far) seen a business card 
with the Punycode form of a domain name on it.

I expect people with two-sided business cards to continue to have an 
(Continue reading)

Stephane Bortzmeyer | 13 Nov 20:19 2007
Picon

Re: Additional Clarification re: Need of an ACE for EAI

On Tue, Nov 13, 2007 at 09:58:08AM -0700,
 Chris Walker <cw-eai-ietf <at> iespresio.com> wrote 
 a message of 121 lines which said:

> Consider the following scenario, 

Let's use a real case. ICANN just announced the implementation of the
Registrar Data Escrow system:

http://www.icann.org/announcements/announcement-2-09nov07.htm

The technical documentation for the ICANN registrars states:

4.1.1 Escrow records shall be compiled into a single (uncompressed) CSV
      text file or multiple (uncompressed) text files approximately 1 gigabyte
      or one million rows in size, in compliance with RFC 4180                
      <http://tools.ietf.org/html/rfc4180>. In accordance with RFC 4180, the
      character encoding for the CSV file should be US-ASCII, although      
      UTF-8 is also permissible.                                      

If a technical or administrative contact has an internationalized
email address, the only way is to send UTF-8 (which is only
"permissible"). At the present time, we have no standard way to encode
the internationalized address in US-ASCII so the registrar cannot
comply with the "should be" above.

[This is just an example of a real-life case. It is not an opinion.]
Stephane Bortzmeyer | 13 Nov 20:27 2007
Picon

Re: Additional Clarification re: Need of an ACE for EAI

On Tue, Nov 13, 2007 at 12:11:02PM -0500,
 Andrew Sullivan <andrew <at> ca.afilias.info> wrote 
 a message of 36 lines which said:

> Isn't this what the ALT-ADDRESS is for?

The way I understand it, ALT-ADDRESS is a human-made alternative, that
has to be configured by the user, not an encoding which can be done
algorithmically.
Harald Alvestrand | 13 Nov 21:39 2007
Picon

Re: Additional Clarification re: Need of an ACE for EAI

Stephane Bortzmeyer wrote:
> On Tue, Nov 13, 2007 at 09:58:08AM -0700,
>  Chris Walker <cw-eai-ietf <at> iespresio.com> wrote 
>  a message of 121 lines which said:
>
>   
>> Consider the following scenario, 
>>     
>
> Let's use a real case. ICANN just announced the implementation of the
> Registrar Data Escrow system:
>
> http://www.icann.org/announcements/announcement-2-09nov07.htm
>
> The technical documentation for the ICANN registrars states:
>
> 4.1.1 Escrow records shall be compiled into a single (uncompressed) CSV
>       text file or multiple (uncompressed) text files approximately 1 gigabyte
>       or one million rows in size, in compliance with RFC 4180                
>       <http://tools.ietf.org/html/rfc4180>. In accordance with RFC 4180, the
>       character encoding for the CSV file should be US-ASCII, although      
>       UTF-8 is also permissible.                                      
>
> If a technical or administrative contact has an internationalized
> email address, the only way is to send UTF-8 (which is only
> "permissible"). At the present time, we have no standard way to encode
> the internationalized address in US-ASCII so the registrar cannot
> comply with the "should be" above.
>   
Huh?
(Continue reading)


Gmane