Subject: [EAI] Discussion of draft-ietf-eai-smtpext-04

From: Charles Lindsey <[email-masked]>
Date: Tue, 20 Mar 2007 16:02:16 -0000

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 21 Mar 2007 14:20:31 -0000

------- Forwarded message -------
From: "Charles Lindsey" <[email-masked]>
To: [email-masked]
Subject: [EAI] Discussion of draft-ietf-eai-smtpext-04
Date: Tue, 20 Mar 2007 16:02:16 -0000

I don't know how that empty message happened. It certainly existed and was  
apparently posted, but no trace of it can be found on my machine :-(.

This smtpext draft is now in reasonable shape, but as ever I have lots of  
niggles.

1.2.  Proposal Context

    This specification describes a change to the email transport
    mechanism that permits non-ASCII address in both the envelope and
    header fields of messages.  The context for the change is described
    in [EAI-overview] and the details of the header changes are described
    in [EAI-utf8header].

No, this specification does not describe any changes in the "header fields  
of messages".

2.2.  The Address Internationalization Service Extension

    ... It MAY transmit the
    domain part of that string in either punycode (derived from the IDNA
    process) or UTF-8 form.

I remember that we discussed whether to use the term "punycode" (as  
opposed to IDNA or something like it) in contexts such as this, but I  
cannot remember what we actually decided.

    ... If it sends the domain in UTF-8 form, the
    original SMTP client SHOULD first verify that the string is valid for
    a domain name according to IDNA rules.  As required by RFC 2821, it
    MUST not attempt to parse, evaluate, or transform the local part in
    any way if the UTF8SMTP SMTP extension is offered by the server.  If
    the UTF8SMTP SMTP extension is not offered by the Server, the SMTP
    Client MUST NOT transmit an internationalized address and MUST NOT
    transmit a mail message which contains internationalized mail headers
    [EAI-utf8header].

Please add, after "internationalized mail headers", "at any level within  
its MIME structure", since that is what [EAI-utf8header] implies.

Also, [EAI-utf8header] deines the term "UTF-8 headers" rather than  
"internationalized mail headers", so please can we use that term so as to  
be consistent between our various drafts.

    ... Instead, it MUST either return the message to the
    user as undeliverable or replace it with the alternate ASCII address.
    If it is replaced, the replacement MUST be the ASCII-only address
    specified with the ALT-ADDRESS parameter.[EAI-downgrading].

No, you don't replace "the message" with "the alternate ASCII address";  
you replace some address in the envelope and/or some headers in the  
message (which might not even have addresses within them).

2.3.  Extended Mailbox Address Syntax

    o  Change the definition of "sub-domain" to permit either the
       definition above or a UTF-8 string representing a DNS label that
       is conformant with IDNA [RFC3490].  That label MUST NOT contain
       the characters "@" or ".", even though those characters can
       normally be inserted into a DNS label.

Do you mean that the UTF-8 string must pass successfully through Nameprep?  
If so, please mention "Nameprep" explicitly here, otherwise people will  
mis-read it as requiring the full IDNA (punycode) form.

          ucharacter = atext / UTF8-non-ASCII
                    ; Replace character in RFC 2821, section 4.1.2
                    ; atext is defined in RFC 2822

Please s/UTF8-non-ASCII/UTF8-xtra-char/ throughout, since that is the name  
of the ABNF rule for exactly the same concept in Utf8headers, and we want  
to have consistent terminology.

And please be careful when using terms from RFC 2822 such as <atext> to  
make sure that Utf8headers has not redefined them (that particular one is  
safe, but you need to check). Actually, you could replace that whole rule  
by

          ucharacter = utf8-atext

using <utf8-atext> as defined in Utf8headers, and similarly elsewhere.

    The value of "udomain" SHOULD be verified with [RFC3490]; If failed,
    the email address with that udomain can not be regarded as the valid
    email address.

Again, do you mean checking it against Nameprep? If so, please mention  
"Nameprep" explicitly. And perhaps that SHOULD would be better as MUST.

2.4.  The ALT-ADDRESS parameter

    ... If the
    email is rejected due to the incapability of supporting UTF8SMTP, the
    relative server should issue the response error code "5.3.3" defined
    in [RFC3463] which means that System is not capable of selected
    features, permanent failure.

You have not mentioned RFC 3463 in your References.

However, on this topic,should we not be defining some extra error codes  
for RFC 3463 (e.g. "Rejected because next hop does not support UFT8SMTP",  
or "downgrade not possible")? RFC 3463 claimed to allow future extension  
of that nature, but OTOH it did not establish any IANA Registry to keep  
track of them. Does anybody know whether there have been any such  
extensions to date?

2.5.  The Suggestion of the Value of the ALT-ADDRESS parameter

    Some may prefer transforming the non-ASCII address to the ASCII
    Compatible Encoding(ACE) address as the value of the ALT-ADDRESS. ...
    ... Some SMTP servers may depend on these specific
    data or instructions to do some operations while the local parts
    applied with ACE will lose or hide these data or instructions. ...
    ... In that case, the sender can specify that these email addresses
    are safe to be converted in the predefined way....

I thought we had agreed not to provide any ACE for local-parts. So what  
you you mean by "in the predefined way"?

2.6.  Body Parts and SMTP Extensions

    Assuming that the server advertises UTF8SMTP and 8BITMIME, and at
    least one non-ASCII address, with or without ALT-ADDRESS, the precise
    interpretation of these parameters on the MAIL command is:

    1.  Headers are in UTF-8, body parts are in ASCII.
    2.  Headers are in UTF-8, some or all body parts contain 8-bit line-
        oriented data.
    3.  Headers are in UTF-8, some or all body parts contain binary data
        without restriction as to line lengths or delimiters.

I do not understand how those three numbered items are supposed to relate  
to any parameters in a MAIL command.

2.7.2.  Message Retry

    When an MSA or MTA encounters a server that doesn't support UTF8SMTP
    while relaying a message that requires such support, it is
    RECOMMENDED that an alternate MX be tried,...

I am not sure that RFC 2119 word "RECOMMENDED" is justified here. Indeed,  
I am not convinced that such retrying is even a good idea in most cases,  
and it is really up to the implementor to do whatever he thinks best. So  
"MAY" would be quite strong enough.

2.7.3.  Trace Information

    uFor = "FOR" FWS 1*( uPath / uMailbox ) CFWS
            ; Replaces For in the section 4.4 of [RFC2821]
        ; uReverse-path is defined in Section 2.4

But "uReverse-path" is not used in that rule. Perhaps you meant "uMailbox"?

    ... When
    only the domain portion of a "for" clause address contains non-ASCII,
    this document suggests using the punycode form of the domain portion.
    For more detailed information, you may see it in [EAI-utf8header].

But I don't "see it in [EAI-utf8header]". All [EAI-utf8header] tells you  
to do is to look in Smtpext :-( .

5.  IANA Considerations

    IANA is requested to add "UTF8SMTP" to the SMTP extensions registry
    with the entry pointing to this specification for its definition.

I think you have to provide a rather specific template here in order to  
change an IANA Registry.

    The "Mail Transmission Types" registry is requested to be updated to
    include the following new entries:

   WITH protocol types  Description                             Reference
   -------------------  ----------------------------            ---------
   UTF8SMTP             UTF8SMTP with Service Extensions        [RFCxxxx]
   UTF8SMTPA            UTF8SMTP with SMTP AUTH                 [RFCxxxx]
   UTF8SMTPS            UTF8SMTP with STARTTLS                  [RFCxxxx]
   UTF8SMTPSA           UTF8SMTP with both STARTTLS and         [RFCxxxx]
                        SMTP AUTH

But I don't understand those at all What are "UTF8SMTPA", "UTF8SMTPS" and  
"UTF8SMTPSA"? I have never heard of them before, and your draft certainly  
does not define them.

-- 
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: "Yao Jiankang" <[email-masked]>
Date: Sun, 25 Mar 2007 22:28:05 +0800

Dear Charles,
     Thanks a lot for your detailed comments.
     some comments below.

----- Original Message ----- 
From: "Charles Lindsey" <[email-masked]>
To: "IMA" <[email-masked]>
Sent: Wednesday, March 21, 2007 10:20 PM
Subject: [EAI] Discussion of draft-ietf-eai-smtpext-04

> No, this specification does not describe any changes in the "header fields

will update it.

> cannot remember what we actually decided.

so what is your suggestions for this text?

>    the UTF8SMTP SMTP extension is not offered by the Server,From [email-masked] Sun Mar 25 10:29:07 2007
From: "Yao Jiankang" <[email-masked]>
To: "IMA" <[email-masked]>,
	"Charles Lindsey" <[email-masked]>
Subject: Re: [EAI] Discussion of draft-ietf-eai-smtpext-04
Date: Sun, 25 Mar 2007 22:28:05 +0800
Cc: 

Dear Charles,
     Thanks a lot for your detailed comments.
     some comments below.

----- Original Message ----- 
From: "Charles Lindsey" <[email-masked]>
To: "IMA" <[email-masked]>
Sent: Wednesday, March 21, 2007 10:20 PM
Subject: [EAI] Discussion of draft-ietf-eai-smtpext-04

> No, this specification does not describe any changes in the "header fields

will update it.

> cannot remember what we actually decided.

so what is your suggestions for this text?

> its MIME structure", since that is what [EAI-utf8header] implies.

you hope to change the sentence "MUST NOT transmit a mail message which 
contains internationalized mail headers
[EAI-utf8header]."  to "MUST NOT transmit a mail message which contains 
internationalized mail headers
[EAI-utf8header] at any level within its MIME structure." ??

> be consistent between our various drafts.

yes, that is good.

> message (which might not even have addresses within them).

ok, will refine it.

> mis-read it as requiring the full IDNA (punycode) form.

IDNA includes Nameprep. If sub-domain is qualified for IDNA, it should be ok
for Nameprep. but if it is qualified for Nameprep, it may not good as IDN.
IDN has two forms: UTF-8 form and Punycode form. I think that here IDNA 
instead of Nameprep is ok.

> to have consistent terminology.

will consider it again.

> using <utf8-atext> as defined in Utf8headers, and similarly elsewhere.

yes, will consider to keep consistent with utf8header document.

> "Nameprep" explicitly. And perhaps that SHOULD would be better as MUST.

Nameprep is just one step of  IDNA. if udomain is qualified with Nameprep,
it may not good for IDN. so IDNA may be better.

> You have not mentioned RFC 3463 in your References.

let me check it.

> track of them.  the SMTP

you hope to change the sentence "MUST NOT transmit a mail message which 
contains internationalized mail headers
[EAI-utf8header]."  to "MUST NOT transmit a mail message which contains 
internationalized mail headers
[EAI-utf8header] at any level within its MIME structure." ??

> be consistent between our various drafts.

yes, that is good.

> message (which might not even have addresses within them).

ok, will refine it.

> mis-read it as requiring the full IDNA (punycode) form.

IDNA includes Nameprep. If sub-domain is qualified for IDNA, it should be ok
for Nameprep. but if it is qualified for Nameprep, it may not good as IDN.
IDN has two forms: UTF-8 form and Punycode form. I think that here IDNA 
instead of Nameprep is ok.

> to have consistent terminology.

will consider it again.

> using <utf8-atext> as defined in Utf8headers, and similarly elsewhere.

yes, will consider to keep consistent with utf8header document.

> "Nameprep" explicitly. And perhaps that SHOULD would be better as MUST.

Nameprep is just one step of  IDNA. if udomain is qualified with Nameprep,
it may not good for IDN. so IDNA may be better.

> You have not mentioned RFC 3463 in your References.

let me check it.

> track of them. Does anybody know whether there have been any such

yes, this is a issue that we need a little discussion for.
Who else know this clearly?

> you you mean by "in the predefined way"?

I will refine this section.

> to any parameters in a MAIL command.

it is related for DATA commands when both UTF8SMTP and 8BITMIME are 
advertised. We put the text here for clarification reason
because some readers does not clearly know body parts are UTF-8 or binary 
data when headers are UTF-8.

> "MAY" would be quite strong enough.

change "recommended" to "suggested"??

> But "uReverse-path" is not used in that rule. Perhaps you meant

yes, we'll update it.

> to do is to look in Smtpext :-( .

will refine it. :)

>   WITH protocol types  Description                             Reference

Because there are alread some RFC for SMTPA and SMTPS SMTPSA
"
SMTPA            SMTDoes anybody know whether there have been any such
> extensions to date?

yes, this is a issue that we need a little discussion for.
Who else know this clearly?

> you you mean by "in the predefined way"?

I will refine this section.

> to any parameters in a MAIL command.

it is related for DATA commands when both UTF8SMTP and 8BITMIME are 
advertised. We put the text here for clarification reason
because some readers does not clearly know body parts are UTF-8 or binary 
data when headers are UTF-8.

> "MAY" would be quite strong enough.

change "recommended" to "suggested"??

> But "uReverse-path" is not used in that rule. Perhaps you meant

yes, we'll update it.

> to do is to look in Smtpext :-( .

will refine it. :)

>   WITH protocol types  Description                             Reference

Because there are alread some RFC for SMTPA and SMTPS SMTPSA
"
SMTPA            SMTP with SMTP AUTH                 [RFCxxxx]
 SMTPS           SMTP with STARTTLS                  [RFCxxxx]
 SMTPSA        SMTP with both STARTTLS and         [RFCxxxx]
                        SMTP AUTH
"
so in the future, we may also need upaded RFC for below
"UTF8SMTPA            UTF8SMTP with SMTP AUTH                 [RFCxxxx]
   UTF8SMTPS            UTF8SMTP with STARTTLS                  [RFCxxxx]
   UTF8SMTPSA           UTF8SMTP with both STARTTLS and         [RFCxxxx]
                        SMTP AUTH
"
Currently, the UTF8SMTPA  UTF8SMTPS UTF8SMTPSA RFC are not available.

Thanks a lot
YAO Jiankang

> Tel: +44 161 436 6131                       Web:
> http://www.cs.man.ac.uk/~chl

---

From: Kari Hurtta <[email-masked]>
Date: 25 Mar 2007 19:31:10 +0300

"Yao Jiankang" <[email-masked]> writes in gmane.ietf.ima:

> you hope to change the sentence "MUST NOT transmit a mail message
> which contains internationalized mail headers
> [EAI-utf8header]."  to "MUST NOT transmit a mail message which

+1 

I also suggest that change.

( And there needed also same requirement for any new
  message/* subtypes defined on EAI DSN draft. ).

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 03:17:23 +0200

Yao Jiankang wrote:

>> Please s/UTF8-non-ASCII/UTF8-xtra-char/ throughout, since that
>> is the name of the ABNF rule for exactly the same concept in
>> Utf8headers, and we want to have consistent terminology.
 
> will consider it again.

Let the other I-D change UTF8-xtra-char to UTF8-non-ASCII, then
it's also consistent with RFC 3977.  At some point in time the
NetNews folks could wish to adopt EAI, one common term is better,

> Who else know this clearly?

A draft for a registry was posted recently on the SMTP list, that's
"work in progress".  Do you need a registry to define new codes ?

> change "recommended" to "suggested"??

Maybe remove the complete paragraph until Randall explains how it's
supposed to work.  Or keep it as "was suggested", and decide this
in a later revision. 

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 04:03:31 +0200

-1  Keep the identification of message/utf8 in one place, not here.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 26 Mar 2007 16:07:36 +0100

> so what is your suggestions for this text?

I haven't any specific text. If someone can remind me what we agreed about  
using the term "punycode", then I could write something. All I rmemeber is  
that it was discussed.

> [EAI-utf8header] at any level within its MIME structure." ??

Yes.

> instead of Nameprep is ok.

Yes, but we are concerned here only with the UTF-8 form. OK, that form  
needs to pass the UseSTD3ASCIIRules test as well as the Nameprep test, but  
it does not have to pass any punycode test. So your paragraph needs to  
mention UseSTD3ASCIIRules as well as Nameprep, but it needs to be clear  
that there is NO requirement to perfrom the punycode step ot "ToASCII".
>> to have consistent terminology.

Or, equally well, persuade the author of Utf8headers to use  
"UTF8-non-ASCII" in place of "UTF8-xtra-char". It really does not matter,  
provided the two of you agree to use the same term.

> it may not good for IDN. so IDNA may be better.

Yes, but as I said above, you need to be explicit that the "punycode" step  
of ToASCII is not involved.

> because some readers does not clearly know body parts are UTF-8 or  
> binary data when headers are UTF-8.

Yes, but that seems to be nothing to do with the MAIL command or its  
parameters, so the wording needs to be clarified.
>> I am not sure that RFC 2119 word "RECOMMENDED" is justified here.

> change "recommended" to "suggested"??

OK

> Currently, the UTF8SMTPA  UTF8SMTPS UTF8SMTPSA RFC are not available.

In that case, your document needs to define them all properly. It is no  
use just springing it as a surprise with no explanation. In what RFCs are  
SMTPA etc defined?

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 18:46:07 +0200

Charles Lindsey wrote:

>>>    ... It MAY transmit the
>>>    domain part of that string in either punycode (derived from
>>>    the IDNA process) or UTF-8 form.

>>> I remember that we discussed whether to use the term "punycode"
>>> (as opposed to IDNA or something like it) in contexts such as
>>> this, but I cannot remember what we actually decided.

> I haven't any specific text. If someone can remind me what we agreed
> about using the term "punycode", then I could write something. All I
> rmemeber is that it was discussed.

Maybe we can say "ASCII Compatible Encoding (ACE) as specified in
[RFC 3490] or its successor", and later simply use ACE as acronym.

===

> parameters, so the wording needs to be clarified.

It's the BODY parameter of MAIL (1: 7BIT, 2: 8BITMIME, 3: BINARYMIME),
the values should be explicitly mentioned, I also stumbled over this
enumeration and wondered what it is about.   A hint in an article
posted by Kari helped me to match the 1-2-3 cases with parameters.)

===
> In what RFCs are SMTPA etc defined?

RFC 3848.  ESMTPA is ESMTP+"AUTH" (CRAM-MD5 or similar, see 2554bis),
ESMTPS is ESMTP + "S" (TLS), ESMTPSA is ESMPTS + "AUTH", similar for
LMTP it's LMPTA, LMTPS, and LMTPSA.  Following that pattern we get
for UTF8SMTP a set UTF8SMTPA, UTF8SMTPS, UTF8SMTPSA.  The RFC XXXX
in the draft is the RFC number of the draft when it's published, not
a separate document, we need no 3848bis for these IANA registrations.

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Mar 2007 23:25:18 +0200

> [RFC 3490] or its successor", and later simply use ACE as acronym.
We'll use Punycode.
If the "idna-issues" draft gets published before it's our turn, we may 
switch to 'A-label'.

But ACE is an ambiguous term, and we won't use it.

                   Harald

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 27 Mar 2007 00:00:30 +0200

Harald Alvestrand wrote:

> If the "idna-issues" draft gets published before it's our turn,
> we may switch to 'A-label'.

 [quoting idna-issues-01 3.1.1.1] 
| important.  An "A-label" is the ASCII-Compatible (ACE) form of an
| IDNA-valid string.  It must be valid as output of ToASCII, regardless
| of how it is actually produced.  This means, by definition, that
| every A-label will begin with the IDNA ACE prefix, "xn--", followed

ACE is quite popular.

> But ACE is an ambiguous term, and we won't use it.

Most three letter acronyms are ambiguous.  Punycode makes me nervous,
when I looked into the spec. I came to the conclusion that I better
don't try to implement it.

Frank

http://en.wikipedia.org/wiki/ACE

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Mar 2007 20:14:59 -0400

--On Monday, 26 March, 2007 23:25 +0200 Harald Alvestrand
<[email-masked]> wrote:

>> Maybe we can say "ASCII Compatible Encoding (ACE) as
>> specified in [RFC 3490] or its successor", and later simply
>> use ACE as acronym.
>>   
> We'll use Punycode.
> If the "idna-issues" draft gets published before it's our
> turn, we may switch to 'A-label'.

If we don't use "A-label", then we should say something like
"string produced by Punycode, prefixed by "xn--".   If you read
the spec, Punycode is best thought of as an algorithm, not the
result of that algorithm.

> But ACE is an ambiguous term, and we won't use it.

thanks.
   john