Subject: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

From: [email-masked]
Date: Wed, 01 Jun 2011 19:56:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF.

	Title           : SMTP Extension for Internationalized Email Address
	Author(s)       : Jiankang Yao
                          W. Mao
	Filename        : draft-ietf-eai-rfc5336bis-10.txt
	Pages           : 20
	Date            : 2011-06-01

   This document specifies an SMTP extension for transport and delivery
   of email messages with internationalized email addresses or header
   information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5336bis-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-rfc5336bis-10.txt

---

From: "Jiankang YAO" <[email-masked]>
Date: Thu, 2 Jun 2011 11:03:38 +0800

The so called "extended" model for ABNF syntax is used.

Thanks Dave and all for the kind comments to the last version and ABNF issues.

Jiankang Yao

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 02, 2011 10:56 AM
Subject: I-D Action: draft-ietf-eai-rfc5336bis-10.txt

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 02 Jun 2011 06:49:15 -0700

Two questions about the newest draft:

> Updates: RFC5321 and 5322                                   June 2, 2011

Does this document update RFC 5322?  If it does, which places in the document do 
that?

If someone is implementing RFC5322, how will they be able to find the 
modifications in this specification?  (The same question applies for RFC5321, of 
course.)

I did a scan of RFC5322 and looked for references to RFC5321, to see whether 
there were any places in the document that appear to incorporate normative 
detail from RFC5321.  These would be candidates for being updated by the current 
specification.

I did not find any text citing RFC5321 normatively.

> 3.2.  The UTF8SMTPbis Extension
...
>    An EAI-aware MUA/MSA sending to a legacy SMTP server [RFC5321] and
>    [RFC5322] MAY convert an ASCII@U-label [RFC5890] address into the
>    format of ASCII@A-label [RFC5890] if the email address is in the
>    format of ASCII@U-label.

Is this defining a new capability that is specific to this specification?  I 
thought that converting from a U-label form to the A-label form was already 
defined in RFC5890.  If it is, then the specification here is redundant and I 
suggest it be replaced with a short, non-normative advisory statement, such as:

      [RFC5890] specifies rules for converting between U-label and A-label formats.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 2 Jun 2011 15:45:21 -0000

>Does this document update RFC 5322?  If it does, which places in the
>document do that?

That appears to be a mistake, since I don't find any changes to 5322 either.
Presumably the updates to 5322 will be in 5335bis.

>Is this defining a new capability that is specific to this specification?

Section 2.3.2.6 of RFC 5890 mentions the domain part of an e-mail address
as a domain name slot, and distinguishes between slots that are IDNA-aware
and those that aren't, but it doesn't offer any suggestions about when
one should convert.  I think it's reasonable to leave this in to say that
this ugly hack is specifically allowed.

Here's an unrelated question: in section 3.2, there is a list describing
what an EAI client can do when faced with a non-EAI server.  The first
item in the list says that the client rejects the message or creates
a DSN, which makes no sense as stated, since those are things a server
does.  I presume the intention is to describe the behavior of a relay
that is acting both as an SMTP client and server, facing in different
directions.  Assuming I guessed right, it would be good to say so.

R's,
John

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 3 Jun 2011 11:56:03 +0800

----- Original Message ----- 
From: "Dave CROCKER" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 02, 2011 9:49 PM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

> Does this document update RFC 5322?  If it does, which places in the document do 

The issue of whether rfc5336bis updates rfc5322 was discussed a few months ago.
finally, we decided to add the following section to address this concern:

In section 1.3.  Updates to Other Specifications

   This specification modifies RFC 5321 by permitting internationalized
   email address in the envelope.  It also updates some syntax rules
   defined in RFC 5321.  It modifies RFC 5322 by permitting data formats
   defined in [RFC5335bis]. 

> ..

This idea was suggested and discussed in the previous version. 
This is for reminder to the implementors.

>I 
> defined in RFC5890. 

I have a quick scan of rfc5890, which does not explicitly say it.

> If it is, then the specification here is redundant and I 

how about the one below:

 An EAI-aware MUA/MSA sending to a legacy SMTP server  and
may convert an ASCII@U-label  address into the
   format of ASCII@A-label if the email address is in the
   format of ASCII@U-label.

Jiankang Yao

> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 03 Jun 2011 14:59:06 +0100

> Does this document update RFC 5322?  If it does, which places in the  

Actually, it might have been better to say "Augments RFC5321 and 5322".  
What is defines is a superset of those - perhaps someday those will indeed  
be updated to EAI, but that is not for now.

-- 
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: Dave CROCKER <[email-masked]>
Date: Fri, 03 Jun 2011 08:15:51 -0700

Jiankang,

Thank you for the quick response and explanation.

My responses...

On 6/2/2011 8:56 PM, Jiankang YAO wrote:
> The issue of whether rfc5336bis updates rfc5322 was discussed a few months
> ago. finally, we decided to add the following section to address this
> concern:
>
> This specification modifies RFC 5321 by permitting internationalized email
> address in the envelope.  It also updates some syntax rules defined in RFC
> 5321.  It modifies RFC 5322 by permitting data formats defined in
> [RFC5335bis].

When one document "updates" another, it's core action is to change text within
the target document.  Hence RFC5335bis very much DOES modify (update) RFC5322.
And, of course, RFC5336bis DOES modify RFC5321.

However, RFC5336bis makes no changes to the text of RFC5322.  The change that
you cite is actually made by RFC5335bis.

The fact that RFC5336bis defines use of the "extended" RFC5322 message format is
important, but the enhancement that permits this use is a change to RFC5321, not 
to RFC5322.

Here is a simple test for when the RFC Updates field is appropriate to use:  If
someone is building software that implements the target (original) 
specification, does the document claiming to Update the target cause a change to 
the software?

(An update might also make changes that do not affect software, such as adding 
text to clarify some aspect of the original specification.  However I think that 
the software test is simple and useful for situations such as we have here.)

Hence, RFC5336bis needs to cite RFC5335bis AND RFC5322, but RFC5336bis does not 
"update" RFC5322.

(By the way, note that the use of this SMTP extension does not /require/ using 
any of RFC5335bis!  It is entirely legal to have the SMTP option be used and 
then to transmit a legacy ASCII message that conforms to RFC5322 and uses none 
of RFC5335bis...)

>> I thought that converting from a U-label form to the A-label form was
>> already defined in RFC5890.
>
>> If it is, then the specification here is redundant and I suggest it be
>> replaced with a short, non-normative advisory statement, such as:
>>
> An EAI-aware MUA/MSA sending to a legacy SMTP server  and may convert an
> ASCII@U-label  address into the format of ASCII@A-label if the email address
> is in the format of ASCII@U-label.

Note that your text uses the word "may".  In fact, your text is a specification 
of protocol detail, rather than a citation to detail in another document.  And 
indeed it is redundant with text in RFC5890:

> 2.3.2.1. IDNA-valid strings, A-label, and U-label
...
>    o  A "U-label" is an IDNA-valid string of Unicode characters, in
...
>                                                       Conversions
>       between U-labels and A-labels are performed according to the
>       "Punycode" specification [RFC3492], adding or removing the ACE
>       prefix as needed.

Again, I think that the current document should contain only a very simple 
statement, such as I suggested:

d/

-- 

   Dave Crocker

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 7 Jun 2011 17:03:53 +0800

----- Original Message ----- 
From: "Dave CROCKER" <[email-masked]>
To: "YAO Jiankang" <[email-masked]>
Cc: "ietf-eai" <[email-masked]>
Sent: Friday, June 03, 2011 11:15 PM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

> important, 

If we can say "RFC5336bis  modifies RFC 5322 by permitting data formats defined in
[RFC5335bis].", then we can say RFC5336bis updates RFC5322. otherwise, not.

RFC5336bis updates RFC5322 or not ?

any other comments about this issue?

The new version  will follow the WG's decision about this issue.

thanks a lot.

Jiankang Yao

>
>but the enhancement that permits this use is a change to RFC5321, not 
> to RFC5322.
>

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 07 Jun 2011 11:58:53 -0700

> [RFC5335bis].", then we can say RFC5336bis updates RFC5322. otherwise, not.

To repeat:

      RFC5335bis is the document that modifies RFC 5322.

      RFC5336bis specifies support for that modification.  Specifying support 
for something is not the same as modifying it.  That is, specifying that 
something is used does not "change" the thing that is being used.

      The modification in RFC5336bis is to change RFC5321, to support 
RFC5335bis.  That is, the change done by RFC5336bis is to SMTP; it does not 
change the message format specifications.

Let me try a comparable example:

      Suppose I operate a conference that is conducted in the language(s) 
specified by some other organization.

      Suppose that that other organization's list originally specified only 
English, but then it modifies the list to include English and Mandarin.

      I must make many changes to the operation of the conference, in order to 
support the language that was added to the list.  However my work does not mean 
that I have changed the list.  It means that I /support/ the list.

Supporting something is very different from modifying (updating) it.

d/

-- 

   Dave Crocker

---

From: Joseph Yee <[email-masked]>
Date: Mon, 13 Jun 2011 16:22:44 -0400

To WG,

Our RFC5336bis draft used to extend syntax rules in RFC5332 hence we have "Updates RFC5322" in the header of the draft.  The recent change in RFC5336bis has no more rules involved from RFC5332, and there is nothing else in the draft (-10) that would update RFC5322, so it is correct to remove "Updates RFC5322"

There are more for RFC "Updates" header.  An RFC XXXX "Updates RFC YYYY" if XXXX changes the base specification of YYYY.  If the draft only extends another, but does not alter behaviour or formal syntax rules, it does not consider as "Updates" since the base specification has not change.

In RFC5336bis, the work is an extension to base SMTP, there is *no change to RFC5322 and even RFC5321*.  Our draft does not alter any current behaviour, nor it changes RFC5321's base specification.  We extends the syntax but did not change any existing rules.

The current RFC5336bis contains all of RFC5336 and modify all necessary parts.  The -bis is to end the experiment and replaces it.  The current RFC5336bis draft is correct in trying to *obsoletes* RFC5335 rather than updating it.

So the next revision of 5336bis (-11) will *not update any RFC*, as the WG work is to  extend, not modify, the SMTP protocol.  Although the draft does not update any RFCs, it should reference RFC5321 and RFC5322, and already did.

We shouldn't spend more time on the update header discussion anymore, it's minor.  We need to focus on the technical details of RFC5336bis and other drafts.  We're 6 weeks from next IETF, it may sounds a lot but time flies!

As co-chair, I ruled this topic closed and need no further discussion, unless new issues provided.  

Thanks.
Joseph Yee, co-chair of EAI

On 2011-06-07, at 2:58 PM, Dave CROCKER wrote:

>     RFC5336bis specifies support for that modification.  Specifying support for something is not the same as modifying it.  That is, specifying that something is used does not "change" the thing that is being used.
> 
>     The modification in RFC5336bis is to change RFC5321, to support RFC5335bis.  That is, the change done by RFC5336bis is to SMTP; it does not change the message format specifications.
> 
>     Suppose I operate a conference that is conducted in the language(s) specified by some other organization.
> 
>     Suppose that that other organization's list originally specified only English, but then it modifies the list to include English and Mandarin.
> 
>     I must make many changes to the operation of the conference, in order to support the language that was added to the list.  However my work does not mean that I have changed the list.  It means that I /support/ the list.
>

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 13 Jun 2011 15:01:12 -0700

> As co-chair, I ruled this topic closed and need no further discussion, unless new issues provided.

Excellent.  Thanks!

d/

-- 

   Dave Crocker