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

Unless there is disagreement with any of these changes, they
will be incorporated in -02 (which will probably be posted
before the weekend).

  john

--On Wednesday, July 07, 2010 09:41 -0400 Ernie Dainow
<edainow@ca.afilias.info> wrote:

> 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 user%foo@example.com is a route ("user" is
> reached via "foo") or simply a local address.
> 
> 
>      - Ernie
> 
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima