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

Small typo below, plus another reference that goes back to 1989.

    -Ernie

John C Klensin wrote:
> 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
>>     
Change to:

Section 2.3.11 of RFC 5321 states (with equivalent wording in earlier standards RFC 2821 and RFC 1123)

>> 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
>>     
>
>
>
>
>   