Subject: [EAI] proposed text Re: Consensus Result - trace fields and RFC5336bis

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 5 Jul 2011 11:32:24 +0800

removing some principle text that has been repeated in other parts of the document,
the new proposed text for section 3.7.3  is the following:

****************************************

The trace information <Return-path-line>, <Time-stamp-line> and their
   related rules have been defined in in section 4.4 of RFC 5321
   [RFC5321].  This document has updated <Mailbox> and <Domain> to
   support non-ASCII characters.  So Return-path-line may include the
   'Reverse-path' clause where internationalized domain name with the
   U-label form may be used.  Time-stamp-line may include the 'Stamp'
   clause where the internationalized domain name with the U-label form
   may be used.

If the messages including the trace field values are sent by the EAI-
   aware SMTP client or relay server without the EAI parameter at MAIL
   commands,  trace field values  must conform to RFC 5321 regardless the SMTP server's
   capability.  
   If the messages including trace field values are sent by the EAI-
   aware SMTP client or relay server with the EAI parameter at MAIL
   commands, trace field values SHOULD use the U-label form for the
   internationalized domain name.  

   The protocol value of the 'WITH' clause when this extension is used
   is one of the UTF8SMTPbis values specified in the "IANA
   Considerations" section of this document.

******************************************

----- Original Message ----- 
From: "health yao" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, July 04, 2011 8:47 PM
Subject: Re: [EAI] Consensus Result - trace fields and RFC5336bis

> Thanks for your result.
> 
> Based on your result,
> I propose the followin text to 3.7.3 of rfc5336bis:
> 
> 
> ----------------------------------------------
> 3.7.3.  Trace Information
> 
> 
>   The trace information <Return-path-line>, <Time-stamp-line> and their
>   related rules have been defined in in section 4.4 of RFC 5321
>   [RFC5321].  This document has updated <Mailbox> and <Domain> to
>   support non-ASCII characters.  So Return-path-line may include the
>   'Reverse-path' clause where internationalized domain name with the
>   U-label form may be used.  Time-stamp-line may include the 'Stamp'
>   clause where the internationalized domain name with the U-label form
>   may be used.
> 
>  If the message including the trace field values are sent by the
> EAI-aware SMTP client or relay server without the EAI parameter at
> MAIL command, they MUST conform to RFC5321 regardless the server's
> capability.
> 
> If the message including trace field values are sent by the  EAI-aware
> SMTP client or relay server with the EAI parameter at MAIL command,
> trace field values in the "from" clause of "Received:" SHOULD use the
> U-label form for the internationalized domain name.
> 
> An EAI-aware SMTP client MUST either be able to send a
> RFC 5321-conformant message to a non-EAI-aware server or
> MUST reject or return the message.  Only the second is
> plausible in the absence of downgrading facilities if
> the message requires EAI capabilities.
> 
> The protocol value of the 'WITH' clause
>   when this extension is used is one of the UTF8SMTPbis values
>   specified in the "IANA Considerations" section of this document.
> 
> ----------------------------------------------------
> 
> 
> Jiankang Yao
> 
> ----- Original Message -----
> From: "Joseph Yee" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, July 04, 2011 6:01 PM
> Subject: [EAI] Consensus Result - trace fields and RFC5336bis
> 
> 
>> All,
>>
>> Following discussion, the WG agreed that message under SMTP without the EAI parameter at MAIL FROM must conform to RFC5321 regardless the server's capability.  Trace field values must conform to RFC5321, whether it's an initial submission or relay.
>>
>> For message under SMTP with EAI parameter at MAIL FROM, an EAI-capable client SHOULD send messages what require EAI functionality in UTF-8 form to servers that do support EAI functionality.  Trace field values (the domain name) in the "from" clause of "Received:" should use U-label.
>>
>> The exact wording will be determined by editors of RFC5336bis, with help from everyone in the WG.  The principle text derived during discussion can be served as guideline:
>>
>> An EAI-capable client MUST either be able to send a
>> 5321-conformant message to a non-EAI-capable server or
>> MUST reject or return the message.  Only the second is
>> plausible in the absence of downgrading facilities if
>> the message requires EAI capabilities.
>>
>> An EAI-capable client SHOULD send messages what require
>> EAI functionality in UTF-8 form to servers that do
>> support EAI functionality.
>>
>> Last Call announcement will follow very soon once the revision published.
>>
>> [
>> Note:
>>
>> I leave out whether MTA can drop or promote the EAI parameter.  This is an implementation issue (as mentioned by John Levine and Ned Freed) and not scope of RFC5336bis.  Personally I believed that it would be good to say something like "It's up to the MTA but iff the message is all ASCII"  but don't go into details .  An advise (informational) doc, or BCP, or AS doc would be the best place to discuss such in details.  Open to WG's suggestion.
>>
>> ]
>>
>> If you believed that there are any issues not covered that could change the consensus result, please post as soon as possible.  I will post a revised result at July 5, 23:59 US Eastern if necessary.  Thanks.
>>
>> Regards,
>> Joseph Yee, co-chair of EAI
>> _______________________________________________
>> IMA mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ima
>>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 05 Jul 2011 08:39:10 -0700

Jiankang,

>     commands,  trace field values  must conform to RFC 5321 regardless the SMTP server's

I just noticed that the term "EAI" is not defined in the document; it is used 
quite a bit.  Whatever term is used, it needs to be defined.  For simplicity, I 
suggest that the term XXX-aware have the XXX be the same as the actual parameter 
name.  Currently, that is: UTF8SMTPbis (to be replaced when the working group 
chooses the final name of the parameter.)

Much more significantly:

    In Section 3.2, there is extended text that covers the case of an EAI-aware 
SMTP client attempting to transfer a UTF-8 message to a non EAI-aware server. 
That text ends with:

> This document applies only when an EAI-aware SMTP client is trying to
>    send an internationalized message to an EAI-aware SMTP server.

    The text that you are have just circulated runs contrary to this statement 
of the document's limits.  I also believe that there is no other place in the 
document that specifies interactions with non-EAI-aware servers.

    If the above sentence is removed from your new text, then the text will read 
well and will stay within the defined limits of the document.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Jul 2011 13:16:55 -0400

Hi.   Several small editorial suggestions...
 (personal opinions only, not as co-chair)

--On Tuesday, July 05, 2011 11:32 +0800 Jiankang Yao
<[email-masked]> wrote:

>...
> The trace information <Return-path-line>, <Time-stamp-line>
> and their    related rules have been defined in in section 4.4

s/have been defined in in section/were defined in section/

> of RFC 5321    [RFC5321].  This document has updated <Mailbox>

s/has updated/updates/

> and <Domain> to    support non-ASCII characters.  So
> Return-path-line may include the    'Reverse-path' clause
> where internationalized domain name with the    U-label form
> may be used.

s/So...used/When this extension is used, the
	'Reverse-path' clause of the Return-path-line may
	include an internationalized domain name that uses the
	U-label form./

or something more like that.  The next sentence might use a
parallel organization.

>  Time-stamp-line may include the 'Stamp'
> clause where the internationalized domain name with the
> U-label form may be used.

> If the messages including the trace field values are sent by
> the EAI-    aware SMTP client or relay server without the EAI

Do you mean "messages that include trace fields"?  If so, maybe
you don't care because the issue is just "messages" (see below).

s/sent by the EAI-aware/sent by an/

Comment: An EAI-aware server that receives a message doesn't
have any way to know whether a client that sends it a message
without the UTF8SMTPbis parameter (I agree with Dave about that
usage) is EAI-aware or not.  Fortunately, it also doesn't care:
the only things with which it should be interested are what it
receives and what it is supposed to do with it.

> parameter at MAIL    commands,  trace field values  must
> conform to RFC 5321 regardless the SMTP server's

s/regardless/regardless of/

>    If the messages including trace field values are sent by
> the EAI-    aware SMTP client or relay server with the EAI
> parameter at MAIL    commands, trace field values SHOULD use
> the U-label form for the    internationalized domain name.  

Same comment as above.  Here, if the UTF8SMTPbis parameter is
sent,  the information that the sender is EAI-aware is just
useless noise -- it has to be to send the parameter (or there
are far more serious problems that you don't need to discuss).

>...

    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Jul 2011 13:26:59 -0400

> I just noticed that the term "EAI" is not defined in the
> document; it is used quite a bit.  Whatever term is used, it
> needs to be defined.  For simplicity, I suggest that the term
> XXX-aware have the XXX be the same as the actual parameter
> name.  Currently, that is: UTF8SMTPbis (to be replaced when
> the working group chooses the final name of the parameter.)

This works for me and is consistent with usage elsewhere.
Thanks for catching it.

> Much more significantly:
> 
>     In Section 3.2, there is extended text that covers the
> case of an EAI-aware SMTP client attempting to transfer a
> UTF-8 message to a non EAI-aware server. That text ends with:
> 
>> This document applies only when an EAI-aware SMTP client is
>> trying to send an internationalized message to an EAI-aware
>>    SMTP server.
> 
>     The text that you are have just circulated runs contrary
> to this statement of the document's limits.  I also believe
> that there is no other place in the document that specifies
> interactions with non-EAI-aware servers.
> 
>     If the above sentence is removed from your new text, then
> the text will read well and will stay within the defined
> limits of the document.

Agreed.

    john

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 6 Jul 2011 13:47:13 +0800

----- Original Message ----- 
From: "Dave CROCKER" <[email-masked]>
To: <[email-masked]>; "YAO Jiankang" <[email-masked]>
Sent: Tuesday, July 05, 2011 11:39 PM
Subject: Re: [EAI] proposed text Re: Consensus Result - trace fieldsand RFC5336bis

> quite a bit.  Whatever term is used, it needs to be defined. 
>

there are dozens of "EAI" in the documents.

 I propose the following text in the terminology section:

"The term "EAI" refers to Email Address Internationalization.
If the clients or servers are "EAI-aware", it means that they support the "&EAISMTPkeyword;" extension
defined in this document."

thanks for catching it.

> well and will stay within the defined limits of the document.

the original text in this paragraph is 
" This document applies only when an EAI-aware SMTP client is trying to
   send an internationalized message to an EAI-aware SMTP server.  For
   all other cases, and for addresses and messages that do not require
   an UTF8SMTPbis extension, EAI-aware SMTP clients and servers do not
   change the behavior specified in [RFC5321].

"

I propose the following text

"This document applies when an EAI-aware SMTP client or server supports the UTF8SMTPbis extension.
For all other cases, and for addresses and messages 
that do not require an &EAISMTPkeyword; extension, EAI-aware SMTP clients and servers do 
not change the behavior specified in  RFC5321. "

Thanks a lot for your kind comments.

Jiankang Yao

---

From: Yangwoo Ko <[email-masked]>
Date: Wed, 6 Jul 2011 15:05:05 +0900

> not change the behavior specified in  RFC5321. "

A standard document specifies what is the right thing for a standard
conformant program (or whatever) to do. You don't need to specify how
all other non conformant programs should do unless such an explanation
is useful for readers to understand what the document specifies.

-- 
a human known as [email-masked] @ gtalk

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 6 Jul 2011 14:12:27 +0800

It is due to the previous discussion about this issue.

It is for the clarification. If you dig this issue, you will find some related discussion.

Some colleagues suggests to clarify what rfc5336bis does and  some relation to rfc5321.

Jiankang Yao

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Jul 2011 06:21:00 -0400

--On Wednesday, July 06, 2011 13:47 +0800 Jiankang Yao
<[email-masked]> wrote:

> If the clients or servers are "EAI-aware", it means that they
> support the "&EAISMTPkeyword;" extension defined in this
> document."

Personal opinion:

Filling these documents with more and more acronyms and
abbreviations, no matter how well defined, makes them hard to
read (and easy to misunderstand when readers can't keep track of
the abbreviations).   If possible, consider eliminating the
term, as Dave suggested.  I've done a small sample and it
appears to me that most or all of the cases that cannot be fixed
by substituting "&EAISMTPkeyword;" and appropriate wording can
be fixed with language like "conforming to this specification"
or "conforming to this set of specifications".  If you need a
definition of the latter, point to the framework spec (4592bis).

We do owe ourselves (and the community) a final check on the
contents of that document when 5335bis...5337bis are ready to go.

    john

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 06 Jul 2011 12:28:03 +0100

>  I propose the following text in the terminology section:

Alternatively, abolish the term "EAI" and use something else. It is an  
historical artefact of the way we got here, and is well past its  
sell-by-date.

Perhaps this problem should be considered alongside the question of what  
to use in place of "UTF8SMTPbis".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: [email-masked]
Date: Wed, 06 Jul 2011 11:46:38 -0700 (PDT)

+1

				Ned