Subject: [EAI] review of 4952bis-03

From: Tony Hansen <[email-masked]>
Date: Wed, 18 Aug 2010 14:08:14 -0400

overall +1

     Tony Hansen

I started working on this review using -02, but then changed to using 
-03. Here are some items I found worth considering changing:

Introduction

I had to read and re-read the very 1st sentence several times before I 
was finally able to parse how all of the commas parsed out. I think 
changing them to parenthetical clauses makes the sentence much clearer.

<   Full use of electronic mail throughout the world requires that,
<   subject to other constraints, people be able to use close variations
<   on their own names, written correctly in their own languages and
<   scripts, as mailbox names in email addresses.
--
 >   Full use of electronic mail throughout the world requires that
 >   (subject to other constraints) people be able to use close variations
 >   on their own names (written correctly in their own languages and
 >   scripts) as mailbox names in email addresses.

I think the following sentence reads better adding a break in the 
middle. (The word "that" is slightly ambiguous as to what its target 
is.) The sentence is in both the Abstract and the Introduction.

<   This document is an update of RFC 4952 that
**  reflects additional issues identified since that document was
**  published.
--
 >   This document is an update of RFC 4952; it
**  reflects additional issues identified since that document was
**  published.

<    This document is an update of RFC 4952 [RFC4952] that reflects
---
 >    This document is an update of RFC 4952 [RFC4952]; it reflects

Section 4.3 User Types

The ASCII user and i18mail user definitions do not cover the entire 
gamut of users. You can also have users who do NOT have any non-ASCII 
email addresses, but *can* generate recipient addresses that contain 
non-ASCII characters. Instead of creating a third class, I think we 
should extend i18mail user to cover this latter case.

<    An "i18mail user" has one or more non-ASCII email addresses.  Such a
---
 >    An "i18mail user" has one or more non-ASCII email addresses, or
 >    is able to generate recipient addresses that contain non-ASCII 
characters. Such a

Section 4.7

Message receipts are also generated as notifications back to the sender. 
I don't have a suggested fix for dealing with this.

Section 7.2

I think we can be less wishy-washy about this statement now.

<    When email local parts are internationalized, it seems clear that
**   they should be accompanied by arrangements for the message headers to
**   be in the fully internationalized form.
---
 >    When email local parts are internationalized,
**   they should be accompanied by arrangements for the message headers to
**   be in the fully internationalized form.

Section 8.

There's an extra "and" in this sentence that is hidden by the 
conditional clause. Make the conditional clause a parenthetical clause 
and remove the "and".

**   proved too complex to be satisfactory.  Consequently, if an
<    intermediate SMTP relay that is transmitting a message that requires
<    these extensions and discovers that the next system in the chain does
**   not support them, it will have little choice other than to reject or
**   return the message.
---
**   proved too complex to be satisfactory.  Consequently, if an
 >    intermediate SMTP relay (that is transmitting a message that requires
 >    these extensions) discovers that the next system in the chain does
**   not support them, it will have little choice other than to reject or
**   return the message.

Section 8.1

This extremely long sentence would be improved by using semi-colons 
instead of commas to delineate the list.

**   In this context, one can easily imagine modifications to message
**   submission servers (as described in [RFC4409]) so that they would
<    perform downgrading, or perhaps even upgrading, operations, receiving
**   messages with one or more of the internationalization extensions
<    discussed here and adapting the outgoing message, as needed, to
**   respond to the delivery or next-hop environment it encounters.
--
**   In this context, one can easily imagine modifications to message
**   submission servers (as described in [RFC4409]) so that they would
 >    perform downgrading, or perhaps even upgrading, operations; receiving
**   messages with one or more of the internationalization extensions
 >    discussed here; and adapting the outgoing message, as needed, to
**   respond to the delivery or next-hop environment it encounters.

Section 8.2

This extremely long sentence reads better by removing the word "either" 
and adding a comma to make the list structure stand out better.

**   Since the final delivery MTA (or, to be more specific, its
**   corresponding mail storage agent) cannot safely assume that agents
**   accessing email storage will always be capable of handling the
<    extensions proposed here, it MAY either downgrade internationalized
**   emails or specially identify messages that utilize these extensions,
**   or both.  If this is done, the final delivery MTA SHOULD include a
--
**   Since the final delivery MTA (or, to be more specific, its
**   corresponding mail storage agent) cannot safely assume that agents
**   accessing email storage will always be capable of handling the
 >    extensions proposed here, it MAY downgrade internationalized
**   emails, or specially identify messages that utilize these extensions,
**   or both.  If this is done, the final delivery MTA SHOULD include a

---

From: John C Klensin <[email-masked]>
Date: Thu, 19 Aug 2010 13:56:21 -0400

Hi.

These suggested changes all seem like improvements.  I'll try to
get them incorporated into a -04 and get that posted tonight or
tomorrow.  If anyone else has further editorial (or other)
suggestions, please make them as soon as possible -- I'd like to
ask Joseph to hand this document off to the IESG RSN.

   john

--On Wednesday, August 18, 2010 14:08 -0400 Tony Hansen
<[email-masked]> wrote:

> overall +1
> 
>      Tony Hansen
> 
> I started working on this review using -02, but then changed
> to using -03. Here are some items I found worth considering
> changing:
> 
> Introduction
> 
> I had to read and re-read the very 1st sentence several times
> before I was finally able to parse how all of the commas
> parsed out. I think changing them to parenthetical clauses
> makes the sentence much clearer.
> 
> I think the following sentence reads better adding a break in
> the middle. (The word "that" is slightly ambiguous as to what
> its target is.) The sentence is in both the Abstract and the
> Introduction.
> 
> The ASCII user and i18mail user definitions do not cover the
> entire gamut of users. You can also have users who do NOT have
> any non-ASCII email addresses, but *can* generate recipient
> addresses that contain non-ASCII characters. Instead of
> creating a third class, I think we should extend i18mail user
> to cover this latter case.
> 
>  >    is able to generate recipient addresses that contain
> non-ASCII characters. Such a
> 
> Section 4.7
> 
> Message receipts are also generated as notifications back to
> the sender. I don't have a suggested fix for dealing with this.
> 
> Section 7.2
> 
> conditional clause. Make the conditional clause a
> parenthetical clause and remove the "and".
> 
> This extremely long sentence would be improved by using
> semi-colons instead of commas to delineate the list.
> 
> This extremely long sentence reads better by removing the word
> "either" and adding a comma to make the list structure stand
> out better.
> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 20 Aug 2010 09:22:55 +0800

new version of 5335bis just posted  has change the "<utf8-local-part>" to  "uLocal-Part " (agreement on mailing list)

so the rfc4952bis  section 11.5.  Other Uses of Local Parts
should do some similar change about "utf8-local-part"

thanks.

Jiankang Yao

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 Aug 2010 03:55:01 -0400

Hi.

4952bis-04 is now in the posting queue and reflects all of these
suggestions in one way or another.  In a few places, I made
slightly different changes than those suggested.  In particular,
I couldn't get 8.1 to parse very well even after the suggested
change, found an old note from the RFC Editor expressing concern
about the sentence, and rewrote it.

I hope  that this is now close enough to finished that we can
hand it off to the IESG and request IETF Last Call.

   john

---

From: Tony Hansen <[email-masked]>
Date: Fri, 20 Aug 2010 10:27:14 -0400

All the changes look good, including 8.1.

+1 to ship.

     Tony Hansen

---

From: Joseph Yee <[email-masked]>
Date: Sun, 22 Aug 2010 17:22:07 -0400

Read -04 and quick scan of -05, believed that it is ready for last call.

Joseph

---

From: Tony Hansen <[email-masked]>
Date: Sun, 22 Aug 2010 21:42:05 -0400

ditto, +1

On 8/22/2010 5:22 PM, Joseph Yee wrote:
>>>>   Full use of electronic mail throughout the world requires
>>>>          
>>> that
>>>        
>>>>   (subject to other constraints) people be able to use
>>>>          
>>> close variations
>>>        
>>>>   on their own names (written correctly in their own
>>>>          
>>> languages and
>>>        
>>>>    This document is an update of RFC 4952 [RFC4952]; it
>>>>          
>>> reflects
>>>
>>> Section 4.3 User Types
>>>
>>>>    An "i18mail user" has one or more non-ASCII email
>>>>          
>>> addresses, or
>>>        
>>>>    intermediate SMTP relay (that is transmitting a message
>>>>          
>>> that requires
>>>        
>>>>    these extensions) discovers that the next system in the
>>>>          
>>> chain does
>>>>    perform downgrading, or perhaps even upgrading,
>>>>          
>>> operations; receiving
>>>>    discussed here; and adapting the outgoing message, as
>>>>          
>>> needed, to
>>>>    extensions proposed here, it MAY downgrade
>>>>          
>>> internationalized