headers
internet-drafts | 2 Jun 2011 04:56
Picon
Favicon

I-D Action: draft-ietf-eai-rfc5336bis-10.txt

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
Permalink | Reply | 4 comments |
headers
Jiankang YAO | 2 Jun 2011 05:03
Picon

Re: I-D Action: draft-ietf-eai-rfc5336bis-10.txt


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: <internet-drafts <at> ietf.org>
To: <i-d-announce <at> ietf.org>
Cc: <ima <at> ietf.org>
Sent: Thursday, June 02, 2011 10:56 AM
Subject: I-D Action: draft-ietf-eai-rfc5336bis-10.txt

>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:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave CROCKER | 2 Jun 2011 15:49

Re: I-D Action: draft-ietf-eai-rfc5336bis-10.txt

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 <at> U-label [RFC5890] address into the
>    format of ASCII <at> A-label [RFC5890] if the email address is in the
>    format of ASCII <at> 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:
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Levine | 2 Jun 2011 17:45

Re: I-D Action: draft-ietf-eai-rfc5336bis-10.txt

>> Updates: RFC5321 and 5322                                   June 2, 2011
>
>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.

>> 3.2.  The UTF8SMTPbis Extension
>...
>>    An EAI-aware MUA/MSA sending to a legacy SMTP server [RFC5321] and
>>    [RFC5322] MAY convert an ASCII <at> U-label [RFC5890] address into the
>>    format of ASCII <at> A-label [RFC5890] if the email address is in the
>>    format of ASCII <at> U-label.
>
>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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jiankang YAO | 3 Jun 2011 05:56
Picon

Re: I-D Action: draft-ietf-eai-rfc5336bis-10.txt


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

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

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

> 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.)
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jiankang YAO | 3 Jun 2011 05:59
Picon

Re: I-D Action: draft-ietf-eai-rfc5336bis-10.txt


----- Original Message ----- 
From: "John Levine" <johnl <at> taugh.com>
To: <ima <at> ietf.org>
Cc: <dcrocker <at> bbiw.net>
Sent: Thursday, June 02, 2011 11:45 PM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

>>> Updates: RFC5321 and 5322                                   June 2, 2011
>>
>>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.
> 

It modifies RFC 5322 by permitting data formats
   defined in [RFC5335bis].  

Jiankang Yao
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 3 Jun 2011 15:59
Picon
Picon

Re: I-D Action: draft-ietf-eai-rfc5336bis-10.txt

On Thu, 02 Jun 2011 14:49:15 +0100, Dave CROCKER <dhc2 <at> dcrocker.net> wrote:

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

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: chl <at> clerew.man.ac.uk      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
Permalink | Reply | 0 comments |
headers
Dave CROCKER | 3 Jun 2011 17:15

Re: I-D Action: draft-ietf-eai-rfc5336bis-10.txt

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:
>
> 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].

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shawn Steele | 3 Jun 2011 23:06
Picon
Favicon

Re: I-D Action: draft-ietf-eai-rfc5336bis-10.txt

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

I think this is extraneous and not necessary.

I think we mentioned before that when EAI-aware servers are communicating with legacy SMTP servers, then
the EAI standards no longer apply.  Then the legacy SMTP RFCs apply.  The IDN RFCs are already clear about
that happens to U-Labels in an ASCII environment, so this isn't necessary.

Also, with a "strict" interpretation of the legacy SMTP behavior, the EAI RFCs wouldn't apply, which would
include this RFC and any of this language within it.

Eg: Legacy SMTP + IDN "works fine" regardless of these RFCs.  Nothing we add here will help or hinder that. 
*IF* we want to address this type of thing, then it should go into a separate document about mitigating the
legacy compatibility issues.  (Eg: alternate routes, try different addresses, etc.)

-=Shawn
Permalink | Reply | 1 comment |
headers
Dave CROCKER | 4 Jun 2011 17:49

Re: I-D Action: draft-ietf-eai-rfc5336bis-10.txt


On 6/3/2011 2:06 PM, Shawn Steele wrote:
>> An EAI-aware MUA/MSA sending to a legacy SMTP server  and may convert an
>> ASCII <at> U-label  address into the format of ASCII <at> A-label if the email
>> address is in the format of ASCII <at> U-label.
>
> I think this is extraneous and not necessary.
>
> I think we mentioned before that when EAI-aware servers are communicating
> with legacy SMTP servers, then the EAI standards no longer apply.

Oh.  Right.

I completely missed that the conversion issue is appropriate for gateways 
between UTF-8 and ASCII environments, but no longer is needed for the current 
specifications, because the current specifications require a UTF8-clean 
environment, end-to-end.

d/

--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
Permalink | Reply | 0 comments |

Gmane