Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-03.txt

From: [email-masked]
Date: Tue, 13 Feb 2007 15:50:03 -0500

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		: SMTP extension for internationalized email address
	Author(s)	: J. Yao, W. Mao
	Filename	: draft-ietf-eai-smtpext-03.txt
	Pages		: 19
	Date		: 2007-2-13
	
Internationalized email address includes two parts, the local part
   and the domain part.  The ways email addresses are used by protocols
   are different from the ways domain names are used.  The most critical
   difference is that emails are delivered through a chain of peering
   clients and servers while domain names are resolved by name servers
   by looking up their own tables.  In addition to this, email transport
   protocols SMTP and ESMTP provide a negotiation mechanism through
   which clients can make decisions for further processing.  This
   document specifies the use of SMTP extension for internationalized
   email address delivery.  It also mentions the backward compatible
   mechanism for downgrade procedure, as specified in an associated
   specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-03.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-smtpext-03.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-smtpext-03.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: Mon, 19 Feb 2007 05:13:58 +0100

> Filename        : draft-ietf-eai-smtpext-03.txt

Some ABNF nits:

1:
Please replace all <Non-ASCII> by UTF8-2 / UTF8-3 / UTF8-4.
<Non-ASCII> is an ambiguous term.  RFC 3977 uses the term
<UTF8-non-ascii> if you insist on some kind of shorthand.

2:
-  ; Let-dig in the right of '=' is defined in RFC 2822
+  ; Augment Let-dig in RFC 2821, section 4.1.3

3:
-  ; Replace Ldh-str in RFC 2821, section 4.1.2
+  ; Replace Ldh-str in RFC 2821, section 4.1.3

Do we really want an <uAt-domain> for UTF8SMTP source routing ?
IMO relays should simply use the ASCII version of domain names
in reverse or forward paths.  It's anyway deprecated.  Without
<uAt-domain> there's of course also no <uA-d-l>.

-  sender, the email must be bounced to the original sender.  If the
-  email is bounced due to the incapability of supporting UTF8SMTP, the
+  sender, the email must be rejected.  If the email is rejected due
+  to the incapability of supporting UTF8SMTP, the

Better don't talk about "bounces to the original sender", that's a
wild and dangerous battlefield reserved for 2821bis.

The start of section 2.5 is rather obscure:

   The "ALT-ADDRESS" requires an all-ASCII address.  There are two
   alternative ways to set ALT-ADDRESS value: one is set by the sender
   using the all-ASCII address, the other is set using the transformed
   email address.

IMO the other way is that the MSA (knowing the sender) could supply an
ALT-ADRESSS for the MAIL FROM.  If that's in some way "transformed" or
not is the local business of the MSA.

The following discussion about "transformations" could be deleted, we
didn't pick that option.  It's also unclear what "the predefined way"
is, (quote) the sender can specify that these addresses are safe to be
converted in the predefined way (unquote).  For the RHS there is a
clear predefined way, but not for the LHS.

   Assuming that the server advertises UTF8SMTP and 8BITMIME, and at
etc.

IMO that paragraph should be deleted, it's obscure and unnecessary.
Of course BODY=8BITMIME and BODY=BINARY mean what they always mean,
that doesn't depend on UTF8SMTP, as explained in the first paragraph
in 2.6.

It's IMO misleading to assume that the presence of non-ASCII addresses
in the envelope _always_ announces a message/utf-8.  For a RCPT TO it
could be still a message/rfc822 (depending on the generated timestamp
lines).  The oppposite also isn't necessarily true, the envelope could
be ASCII, but the message header can contain UTF-8.

   This alternate-MX-or-retry-later technique SHOULD NOT be used when

It SHOULD NOT be discussed at all, it's really odd.  Especially "retry
later", what's the idea, the receiver just happens to upgrade their MX
today ?

-   uFor = "FOR" FWS 1*( Path / uMailbox ) CFWS
+   uFor = "FOR" FWS 1*( uPath / uMailbox ) CFWS

2.7.5:  Please delete the complete section, there's no "Header-Type"
anymore.  2.7.6 could be also deleted, POP3 and IMAP are introduced
in the framework RFC, they will get their own RFCs.  No SMTP business,
no case for a "SHOULD".  Or is that about the job of MDAs ?  Then it
doesn't say what special actions an MDA is expected to perform (after
it got the uReturn-path-line right as specified in 2.7.3).

3.1:  Please delete this section, mailto URIs are no SMTP business.
3.2:  s/2476/4409/ everywhere, and s/EAI protocol/UTF8SMTP/ (?)
The complete chapter 3 should go.  Chapter 4 is also unnecessary.
How about some nice example sessions ?

Another nit in 2.2:

-  transmit a mail body which contains internationalized mail headers
+  transmit a message which contains internationalized mail headers

Maybe 'mail data', SMTP transports complete messages, header + body.

Frank