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

["Charles Lindsey" <chl at clerew.man.ac.uk>]

------- Forwarded message -------
From: "Charles Lindsey" <chl at clerew.man.ac.uk>
To: ima at ietf.org
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: 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

_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima