Subject: [EAI] I-D ACTION:draft-ietf-eai-framework-02.txt

From: [email-masked]
Date: Thu, 12 Oct 2006 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Email Address Internationalization Working Group of the IETF.

	Title		: Overview and Framework for Internationalized Email
	Author(s)	: J. Klensin, Y. Ko
	Filename	: draft-ietf-eai-framework-02.txt
	Pages		: 20
	Date		: 2006-10-12
	
Full use of electronic mail throughout the world requires that people
   be able to use their own names, written correctly in their own
   languages and scripts, as mailbox names in email addresses.  This
   document introduces a series of specifications that define mechanisms
   and protocol extensions needed to fully support internationalized
   email addresses.  These changes include an SMTP extension and
   extension of email header syntax to accommodate UTF-8 data.  The
   document set also includes discussion of key assumptions and issues
   in deploying fully internationalized email.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-eai-framework-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-eai-framework-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 13 Oct 2006 06:09:07 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-02.txt

1.3:
| it is not possible to tell from the address that an email sender or
| recipient is an i18mail user.

s/i18mail/ASCII/  If it's an ASCII address the user might also have
non-ASCII addresses, and is an i18mail user.  And if it's a non-ASCII
address the user is obviously an i18mail user.  An "ASCII user" isn't
obvious.

4.1:
/ditto for POP.???/  Should that be /ditto for [I18Nemail-pop]/ ?

13.2:
s/[DKIM-Charter]/[draft-ietf-dkim-base] + [draft-ietf-dkim-overview]/

The DKIM-threats, SSP-requirements, and SSP-proper texts are not
directly affected (unless SSP tries "per user policies", unclear).

7:
For chapter 7 I propose to add a new subsection about any "local part
transformation" schemes like SES, SRS, BATV, or SPF per-user-policies
(or other uses of its %{l} macro as domain label, %{l} = "local part")

For SPF I'm almost sure that it should work, its <target-name> is not
specified, it can contain any octet as found in %{l}.  Almost, the
test suite folks found a case foo...bar (with adjacent dots), that's
putting it mildly "underspecified", but of course no EAI issue.

Frank

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 13 Oct 2006 14:31:00 +0900

> address the user is obviously an i18mail user.  An "ASCII user" isn't

Let me see 2x2 matrix.
(1) An i18mail user using non-ASCII address is obviously identified.
(2) An i18mail user using ASCII address is NOT obviously identified.
(3) An ASCII user using non-ASCII address is just error somewhere.
(4) An ASCII user using ASCII address is NOT obviously identified.

Yes. Problem arises when a given address is all ASCII. In that
case, we cannot tell whether the user is i18mail or ASCII user.
My proposal is that;

... it is not possible to tell from an ASCII address that an email
sender or recipient is an i18mail user or an ASCII user.

Too redundant?

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 13 Oct 2006 10:11:54 +0200

> Too redundant?

No, it's clearer and better than only s/i18mail/ASCII/.  Thanks.

Frank