[EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01

[Ernie Dainow <[e-mail]>]

2. Role of This Specification
[[anchor2: Note in Draft: Is 5825 still relevant, or is a victim of the 
"no in-transit downgrade" decision.??]]

Comment:  RFC 5825 describes how to construct the original headers from 
the "Downgraded-" headers. This is not relevant unless we are planning 
to use such headers (defined in 5504) for specifying how a final 
delivery SMTP server/mail store should downgrade messages that POP or 
IMAP can restore for UTF8 clients.

7.1 SMTP Extension for Internationalized Email Address
Conformance to the group of standards specified here for email transport 
and delivery requires implementation of the SMTP Extension 
specification, including recognition of the keywords associated with 
alternate addresses, and the UTF-8 Header specification.

Comment:  remove "including recognition of the keywords associated with 
alternate addresses".

8. Downgrading before and after SMTP Transactions
While the experiments that preceded these specifications included a 
mechanism for passing backup ASCII addresses to intermediate relay 
systems and having those systems alter the relevant message header 
fields and substitute the addresses,

Comment:  add a reference to RFC 5504 for future readers who may not 
know anything about the Experimental drafts.

9. Downgrading in Transit
[[anchor16: ... this section will simply be dropped.]]

Comment:  Leading up to the recharter, there was a lot of heated 
discussion on algorithmic/ACE transformations, even though it had been 
covered at the beginning of the working group. I think we need to 
capture some of this history or future readers of the standard will 
raise the same questions again. I suggest the following as a starting point.

Section 2.3.11 of RFC 2321, and RFC 2821 before that, states that "due 
to a long history of problems when intermediate hosts have attempted to 
optimize transport by modifying them, the local-part MUST be interpreted 
and assigned semantics only by the host specified in the domain part of 
the address".

Adherence to this rule means that a downgrade mechanism that transforms 
the local-part of an email address cannot be done in transit. It can 
only be done at the endpoints, namely by the MUA or submission server or 
by the final delivery SMTP server.

One of the reasons for this rule has to do with legacy email systems 
that use source routing in the local-part of the address field. 
Transforming the email address destroys such routing information. There 
is no way a server other than the final delivery server can know, for 
example, whether the local-part of [e-mail] is a route 
("user" is reached via "foo") or simply a local address.


     - Ernie