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

From: [email-masked]
Date: Thu, 07 Jul 2011 18:23:52 -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
	Author(s)       : Jiankang Yao
                          W. Mao
	Filename        : draft-ietf-eai-rfc5336bis-11.txt
	Pages           : 20
	Date            : 2011-07-07

   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-11.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-11.txt

---

From: Chris Newman <[email-masked]>
Date: Mon, 25 Jul 2011 10:16:41 -0400

> 	Filename        : draft-ietf-eai-rfc5336bis-11.txt

I've done an extensive "clean slate" review on this document. I found a 
number of issues I consider largely editorial and some I consider 
substantive (in that the decision has technical impact). I've attached my 
full review with editorial notes embedded in the text. Here are the 
substantive issues:

1. Somewhere this needs to say: If a server advertises both UTF8SMTPbis and 
DSN, then that server MUST support UTF-8 in the ORCPT parameter. This also 
has ABNF impact. We need to add:

   ehlo-param  =/ UTF8-non-ascii

to allow UTF-8 in mail, rcpt and data parameters.

2. I would prefer this ABNF rule be removed:

   quoted-pairSMTP  =/ %d92 UTF8-non-ascii
    ; extend the definition of quoted-pairSMTP in RFC5321, section 4.1.2

This is an unnecessary change and makes 5336bis quoting even less 
consistent with 5335bis quoting. Conservative generators should never emit 
\ followed by anything other than \ or double-quote anyway, so adding 
complexity to explicitly allow generation of useless forms is not helpful.

3. I suggest adding a statement to the end of section 3.5:

      SMTP servers are encouraged to detect that recipients can not
      accept internationalized email headers and return an error
      earlier in the transaction whenever possible.

4. In section 3.5, I suggest adding an enhanced status code for the case 
where a U-label can not be converted to an A-label. This is semantically 
quite different from X.6.7 and X.6.9

5. Section 3.7 says the A-label form SHOULD be used. While I don't object 
to that for relay, I believe it should also say that submission clients MAY 
use U-labels.

6. Section 3.7.3:

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

      This wording suggests servers need to convert from A-label to
      U-label if a previous server did the wrong thing. I don't think
      that's reasonable. I suggest rewording:

    When an SMTP server adds a trace field to a message that was or
    will be transmitted with the UTF8SMTPbis MAIL FROM parameter, that
    server SHOULD use the U-label form for internationalized domain
    names in that new trace field.

7. Section 3.7.3 needs to say (given the current ABNF):

   The Atom form of the ID clause can contain non-ASCII characters.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Jul 2011 17:36:50 -0400

Chris,

I'm only going some points needing clarification...

> earlier in the transaction whenever possible.

MDAs are often (almost always?) the only entities that know anything about 
recipient capabilities.  The statement should probably be revised so that it 
does not confuse transit relay operators.

In addition, I don't know what you mean by "earlier in the transaction".  Do you 
really mean the difference between responding to a RCPT command, versus a DATA 
command in the same session, or did you mean something about the mail relaying 
sequence?

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 26 Jul 2011 19:51:37 +0800

----- Original Message ----- 
From: "Chris Newman" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 25, 2011 10:16 PM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt

> number of issues I consider largely editorial 
>

thanks a lot for your kind and detailed review.

Some of your suggested editorial texts has been changed back and forth many times.
I am sorry that the texts can not make everyone happy.
I will try to adjust the texts based on your editorial suggestion, but will also follow the previous discussion about
this topic to avoid the "back and forth" text problem.

>and some I consider 
> has ABNF impact. 

my concern is that, if we choose to add the sentence above we cause another problems.

Is it really necessary to add such a sentence?

>We need to add:

I agreed it here.

How about Dave's comments about this issue?

>      earlier in the transaction whenever possible.

similar comments to Dave's

http://www.ietf.org/mail-archive/web/ima/current/msg04285.html

another question is 

adding this sentence is more clear than without it?

> quite different from X.6.7 and X.6.9

based on rfc5890, U-label must be transformed to A-label, otherwise, it can not be called U-label.

John should be authoritive about the defintion of U-label.

> to that for relay, I believe it should also say that submission clients MAY 

agree.

>    names in that new trace field.

ok, thanks.

>   The Atom form of the ID clause can contain non-ASCII characters.

I think that the current wording below covers the "ID clause" case:

"When the UTF8SMTPbis extension is used, the 'Reverse-
   path' clause of the Return-path-line may include an internationalized
   domain name that uses the U-label form; The 'Stamp' clause ot the
   Time-stamp-line may include an internationalized domain name that
   uses the U-label form.

"

thanks a lot.

Jiankang Yao

--------------------------------------------------------------------------------

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

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 26 Jul 2011 19:53:12 +0800

----- Original Message ----- 
From: "Chris Newman" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 25, 2011 10:16 PM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt

I agreed it here.

another question is 

agree.

ok, thanks.

"

thanks a lot.

Jiankang Yao

---

From: Chris Newman <[email-masked]>
Date: Tue, 26 Jul 2011 09:57:21 -0400

--On July 26, 2011 19:51:37 +0800 Jiankang Yao <[email-masked]> wrote:
>> 1. Somewhere this needs to say: If a server advertises both UTF8SMTPbis
>> and  DSN, then that server MUST support UTF-8 in the ORCPT parameter.
>> This also  has ABNF impact.
>>
>

Yes.

Without this sentence, a server can implement old DSN and be compliant with 
the old DSN spec and implement UTF8SMTPbis and be compliant with 
rfc5336bis, and not support UTF-8 in ORCPT. Such a server will break 
interoperability with clients that are compliant with 4952bis which 
requires this behavior.

> adding this sentence is more clear than without it?

Let me attempt to re-word based on Dave's feedback:

      SMTP servers are encouraged to detect that recipients can not accept
      internationalized email headers and generate an error after the RCPT
      command rather than waiting until after the DATA command to issue an
      error.

> John should be authoritive about the defintion of U-label.

This does not prevent a broken client from generating a UTF-8 domain that 
is not a valid U-label and thus can not be converted to an A-label. It's an 
error a well-intentioned client implementer can make by mistake. And it's a 
subtle error condition a processor may not expect. For those reasons, I 
think it's useful to distinguish it from the class of 
"recipient-can't-handle" errors.

		- Chris

---

From: Chris Newman <[email-masked]>
Date: Tue, 26 Jul 2011 09:41:11 -0400

--On July 25, 2011 17:36:50 -0400 Dave CROCKER <[email-masked]> wrote:
> MDAs are often (almost always?) the only entities that know anything
> about recipient capabilities.  The statement should probably be revised
> so that it does not confuse transit relay operators.

Often there is an MTA adjacent to an MDA that might be acting like an SMTP 
proxy or a conditional SMTP proxy. Such an MTA can get rejections from the 
MDA in response to the RCPT command.

> In addition, I don't know what you mean by "earlier in the transaction".
> Do you really mean the difference between responding to a RCPT command,
> versus a DATA command in the same session, or did you mean something
> about the mail relaying sequence?

Yes, that's what I meant.

		- Chris