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

From: Joseph Yee <[email-masked]>
Date: Wed, 3 Aug 2011 14:44:06 -0400

On 2011-07-26, at 9:57 AM, Chris Newman wrote:

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

I believed that RFC5337bis (section 3) covered this already.  Maybe just need to add text to reference RFC5337bis.

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

Personally I see this as best practice, but I think adding either text is ok.

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

I'm not sure if a different error code can help end users at the moment.  Unless you mean MSA/MTA to detect and report U-label => A-label failure, otherwise it is only "recipient-can't-handle" or "host-not-found".

Would love to hear more feedback from everyone regarding this.

Best
Joseph

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

---

From: Chris Newman <[email-masked]>
Date: Wed, 03 Aug 2011 16:17:54 -0700

--On August 3, 2011 14:44:06 -0400 Joseph Yee <[email-masked]> wrote:
>> 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.
>
> I believed that RFC5337bis (section 3) covered this already.  Maybe just
> need to add text to reference RFC5337bis.

Rules in RFC 5337bis do not impact RFC 5336bis implementations, unless RFC 
5336bis explicitly states that implementations MUST follow that rule (or 
all rules) in RFC 5337bis.

		- Chris

---

From: "Jiankang Yao" <[email-masked]>
Date: Fri, 5 Aug 2011 12:03:00 +0800

----- Original Message ----- 
From: "Chris Newman" <[email-masked]>
To: "Joseph Yee" <[email-masked]>
Cc: <[email-masked]>; "Jiankang Yao" <[email-masked]>
Sent: Thursday, August 04, 2011 7:17 AM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt

> all rules) in RFC 5337bis.

in the end of  section  3.2.  The UTF8SMTPbis Extension

how about adding one sentence below?

If the UTF8SMTPbis-aware SMTP servers try to support DSN[RFC 3461] , they MUST support 
RFC5337bis.

does such sentence satisify your expectation?

Jiankang Yao

---

From: Chris Newman <[email-masked]>
Date: Fri, 05 Aug 2011 16:27:53 -0700

--On August 5, 2011 12:03:00 +0800 Jiankang Yao <[email-masked]> wrote:
> If the UTF8SMTPbis-aware SMTP servers try to support DSN[RFC 3461] , they
> MUST support  RFC5337bis.
>
>

I don't know what "try to support" means in a spec. How about:

If a UTF8SMTPbis-aware SMTP server advertises the Delivery Status 
Notification [RFC3461] extension, it MUST implement RFC 5337bis.

		- Chris

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 8 Aug 2011 11:26:46 +0800

I agree with Joseph's comments about this issue.
On the other hand, SMTP does not allow to judge whether the domain name is valid or not.

Jiankang Yao

----- Original Message ----- 
From: "Joseph Yee" <[email-masked]>
To: "Chris Newman" <[email-masked]>
Cc: "Jiankang Yao" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 04, 2011 2:44 AM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt

Best
Joseph

---

From: Chris Newman <[email-masked]>
Date: Mon, 08 Aug 2011 13:39:30 -0700

--On August 3, 2011 14:44:06 -0400 Joseph Yee <[email-masked]> wrote:
>>>> 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
>>>
>> 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.
>
> I'm not sure if a different error code can help end users at the moment.
> Unless you mean MSA/MTA to detect and report U-label => A-label failure,
> otherwise it is only "recipient-can't-handle" or "host-not-found".
>

A "host-not-found" error is close but not entirely accurate since a UTF-8 
domain that can't be converted to an A-label can't even be looked up to 
determine if the host exists...

But I looked in RFC 3463 again and noticed there are correct codes that an 
MSA/MTA could use for this case.

MAIL FROM:   501 5.1.7 Bad sender's mailbox address syntax
RCPT TO:     501 5.1.3 Bad destination mailbox address syntax

So I think mentioning those codes for the case where a UTF-8 domain can't 
be converted to an A-label would be helpful.

		- Chris

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 9 Aug 2011 14:50:13 +0800

----- Original Message ----- 
From: "Chris Newman" <[email-masked]>
To: "Joseph Yee" <[email-masked]>
Cc: <[email-masked]>; "Jiankang Yao" <[email-masked]>
Sent: Tuesday, August 09, 2011 4:39 AM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt

> be converted to an A-label would be helpful.

In the  case where a UTF-8 domain can't  be converted to an A-label, 
 we can regard it as the bad mailbox address syntax as pointed out by your example above.
The invalid address may be caused by invalid U-lable or Local-part.

Since the RFC 3463 has defined it, giving it more detailed distinction may not bring us more help.

Jiankang Yao

---

From: [email-masked]
Date: Wed, 10 Aug 2011 23:53:43 -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-12.txt
	Pages           : 20
	Date            : 2011-08-10

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 11 Aug 2011 12:42:00 +0100

Jiankang Yao wrote:

>To: <[email-masked]>
>Sent: Monday, July 25, 2011 10:16 PM
 [...]

>>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.    
>>
>
>I agreed it here.
>  
>
I am very happy that this ABNF rule is gone.

---

From: Chris Newman <[email-masked]>
Date: Wed, 17 Aug 2011 15:04:04 -0700

I've reviewed revision -12 and find it acceptable except the ABNF does not 
allow UTF-8 in ESMTP parameter values. So we need:

   esmtp-value  =/  UTF8-non-ascii

added to the ABNF.

		- Chris

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 18 Aug 2011 01:21:10 +0200

On 18 August 2011 00:04, Chris Newman wrote:

> So we need:

> added to the ABNF.

My personal EAI 2011 experiment, can I grok what folks are talking
about if it is not related to Message-IDs...

RFC 5321 says that <esmtp-value> follows the RFC 3461 <xtext> syntax
for addresses, and I-D.eai-rfc5337bis specifies <utf-8-addr-xtext>
for this job.  That is hex. encoded UTF-8, or in other words ASCII.

With <UTF8-non-ascii> in <esmtp-value> that has (obviously) to be
limited to states when UTF8SMTPbis is already negotiated.  And if
that is the case using <utf-8-addr-xtext> outside of ORCPT could be
confusing.  If it is not only me who is confused, please add also
an explanation in I-D.eai-rfc5336bis when you update <esmtp-value>.

Examples in the direction of "do this if outside of UTF8SMTPbis" vs.
"do that in UTF8SMTPbis" maybe followed by a BUT for ORCPT could be
good.

-Frank

---

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 18 Aug 2011 14:43:37 +0800

----- Original Message ----- 
From: "Chris Newman" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 18, 2011 6:04 AM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt

> I've reviewed revision -12 and find it acceptable 
>

thanks a lot for your kind review.

>except the ABNF does not 

If your proposed esmtp-value syntax extension in rfc5336bis  is used for ORCPT in DSN, then 
RFC5336bis has already said "
   If a UTF8SMTPbis-aware SMTP server advertises the Delivery Status
   Notification (DSN) [RFC3461] extension, it MUST implement
   [RFC5337bis].
"

Does it satisfy your expectation?

I also like to hear your comments to Frank Ellermann's comments to this issue.

thanks a lot.

Jiankang Yao

---

From: Chris Newman <[email-masked]>
Date: Fri, 19 Aug 2011 14:14:01 -0700

> for this job.  That is hex. encoded UTF-8, or in other words ASCII.

That comment in 5321 is confusing and unnecessary. If we were to ever 
revise 5321, I'd support removing it.

The "utf-8-addr-xtext" in RFC 5337 has a misleading name as it is unrelated 
to the 3461 xtext construction. I suggested renaming it to 
"utf-8-addr-7bit" in 5337bis (on July 28).

> an explanation in I-D.eai-rfc5336bis when you update <esmtp-value>.

I see no confusion on this matter in 5336bis. When UTF8SMTPbis is 
negotiated, the ABNF in 5335bis/5336bis applies. When it is not negotiated, 
the ABNF in 5321/5322 applies.

> "do that in UTF8SMTPbis" maybe followed by a BUT for ORCPT could be

5336bis has to describe what is allowed in ESMTP parameter values when 
UTF8SMTPbis is negotiated. But discussion of what goes in ORCPT belongs in 
RFC 5337bis.

		- Chris

---

From: Chris Newman <[email-masked]>
Date: Fri, 19 Aug 2011 14:21:44 -0700

> Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt
...
> If your proposed esmtp-value syntax extension in rfc5336bis  is used for
> ORCPT in DSN, then  RFC5336bis has already said "

That creates a contradiction. RFC 5337bis discusses using UTF-8 in the 
ORCPT parameter value, but 5336bis ABNF presently disallows use of UTF-8 in 
ESMTP parameter values. We can make the specifications consistent by 
allowing UTF-8 in ESMTP parameter values.

> I also like to hear your comments to Frank Ellermann's comments to this

See separate message.

		- Chris

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Aug 2011 18:35:56 +0100

Chris Newman wrote:

> ORCPT parameter value, but 5336bis ABNF presently disallows use of 
> UTF-8 in ESMTP parameter values. We can make the specifications 
> consistent by allowing UTF-8 in ESMTP parameter values.

Good point. I support your proposal.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Aug 2011 12:04:33 -0700

+1

/d

--
Dave Crocker
bbiw.net

via mobile

_____________________________________________
From: Alexey Melnikov <[email-masked]>
Sent: Sat Aug 20 10:35:56 PDT 2011
To: Chris Newman <[email-masked]>
Cc: [email-masked], Jiankang Yao <[email-masked]>
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-12.txt

_____________________________________________

IMA mailing list
[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Mon, 22 Aug 2011 08:33:51 -0400

+1

     Tony Hansen