Subject: Re: [EAI] Comments on draft-ietf-eai-00.txt

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 1 Jun 2006 11:36:56 +0800

----- Original Message ----- 
From: "Charles Lindsey" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 30, 2006 2:46 AM
Subject: [EAI] Comments on draft-ietf-eai-00.txt

> The draft refers, in many places, to "IMA" (whose definition can only be  
> found in the Abstract). I suspect all these need changing, probably to  
> "EAI", with the term defined somewhere in 1.3. Or maybe to "IEmail", which  
> is to be the EHLO keyword.

we will consider to use  "IEmail" or  "EAI"

> 
> 2.1.  Framework for the Internationalization Extension
> 
>     3.  No parameter values are defined for this EHLO keyword value.  In
>         order to permit future (although unanticipated) extensions, the
>         EHLO response MUST NOT contain any parameters for that keyword.
>         If a parameter appears, the SMTP client that is conformant to
>         this version of this specification MUST treat the ESMTP response
>         as if the IMA keyword did not appear.
> 
> s/IMA/IEmail/

will use IEmail.

> 
>     6.  Servers offering this extension MUST provide support for, and
>         announce, the 8BITMIME extension [RFC1652].
> 
> Hmmm! I see that this means you are supposed to include a BODY=8BITMIME  
> parameter in your MAIL FROM command if the body uses TCE 8bit (highly  
> probable in an EAI message). Do agents currently do that in practice?

can I suggest that where in the fields there use MIME now , still use MIME in the email message or content.
we only update the fields containing the UET-8 email address to UTF8. 

> 
> However, there is another possible 8BITMIME problem. Suppose your message  
> is a multipart, and suppose one of the headers of one of the multiparts  
> contains some UTF-8, e.g.
>      Content-Disposition: ... filename="some utf-8 stuff"
> (which surely we want to allow, though it is actually an extension to RFC  
> 2045 which needs to be mentioned in the utf8headers document). Now this  
> message encounters a server which supports neither IEmail nor 8BITMIME.  
> RFC 1652 tells you to downgrade to 7bit or else to bounce, so in this case  
> the "some utf-8 stuff" needs to be downgraded accordig to RFC 2231, and  
> this needs to be mentioned somewhere in our drafts. Maybe the downgrade  
> document is the place to do it, but I mention it here to make sure it does  
> not get forgotten.
> 

pls see above.

> 
> 2.2.  The Address Internationalization Service Extension
> 
>     Any domain names that are to be looked up in the DNS MUST be
>     processed into the form as specified in IDNA [RFC3490] by means of
>     the ToASCII() operation unless they are already in that form.  Any
>     domain names that are to be compared to local strings SHOULD be
> 
> s/DNS MUST be processed/DNS MUST first be processed/

  ok, will update it.

> 
>     An SMTP Client that receives the IMA extension keyword MAY transmit a
>     mailbox name as an internationalized string in UTF-8 form and MAY
> 
> s/receives the IMA extension keyword MAY/receives the IMA extension  
> keyword in response to EHLO MAY/

ok, will update it.

> 
>     ....  If the IMA SMTP extension is not offered by
>     the Server, the SMTP Client MUST NOT transmit an internationalized
>     address and MUST NOT transmit a mail body which contains
>     internationalized mail headers [IMA-utf8header].  Instead, it MUST
>     either return the message to the user as undeliverable or replace it
>     with the alternate ASCII address.  .....
> 
> Are you trying to cover addresses in both SMTP commands and in email  
> headers here? If so, then the words "a mail body" are wrong (the body of a  
> message does not include its headers, apart from in multiparts as I  
> mentioned earlier). So I think you need
> 
> s/a mail body/a message/

yes, will use "a message".

> 
> but in either case, "it" is too vague, so
> 
> s/it/all addresses (both in the envelope and in the message's header  
> fields)/

will consider it carefully.

> 
>     ... If it is replaced, the replacement
>     MUST be either the ASCII-only address specified with the ALT-ADDRESS
>     parameter or with an address obtained from some algorithmic
>     conversions of the primary address that conforms to the syntax rules
>     of RFC 2821, which is defined in [IMA-downgrading].
> 
> That wording is fine if the client is an earlier IEmail-compliant server,  
> but if the the client is the originating MUA it doesn't have an  
> ALT-ADDRESS to hand. It has to invent one by whatever means (maybe it  
> found one in the To: header, maybe it had a table of mappings).

yes.

> 
> There is a further complication. Suppose a message arrives at some  
> intermediate server with one ALT-ADDRESS in its RCPT TO: command, and a  
> different one in its To: header. I think the only sensible thing to do is  
> to use the one in the RCPT TO: command in the ongoing (downgraded) RCPT  
> TO:, and the one from the To: header in the ongoing (downgraded) To:  
> header. Note that this anomaly is perfectly possible if, for example, this  
> is a message being propagated by some mailing list expander.

can we do some specification (address synchronize) in the utf-8-headers document to avoid such anomaly in the "RCPT To" and "To: header"? for example, if ALT-ADDRESS is used in "RCPT To", "To: header" will also use ALT-ADDRESS. 

> 
> 2.3.  Extended Mailbox Address Syntax
> 
>     Where "atext", "qcontent" and "DQUOTE" are defined in [RFC2822],
>     "Let-dig", "Ldh-str" and "address-literal" are defined in [RFC2821]
>     and UTF8-2, UTF8-3 and UTF8-4 are defined in [RFC3629].  The value of
>     "Local-part" should pass Stringprep [RFC3454]; The value of "domain"
>     should be verified with [RFC3490]; If failed, The value of "Local-
>     part" and "domain", the email address can not be regarded as the
>     valid email address.
> 
> s/should/SHOULD/

will use SHOULD

> 
> However, you cannot specify Stringprep without stating what 'profile' of  
> Stringprep you require. Maybe you can find an existing one that suits your  
> need (but not Nameprep, because that removes and upper/lowercase  
> distinctions). You could easily define your own profile by indicating  
> which of the various tables from RFC 3454 were to be applied. I agree that  
> local-parts should have _some_ suitable Stringprep applied to them. They  
> are essentially 'identifiers' in nature, and should at least adhere to  
> WYSIWYG (but note in passing that RFC 2822 local-parts already fail  
> Stringprep by permitting control characters).
> 

Yes, we should have our own Stringprep for the email local part.

> As an aside, I just noticed that John KLensin's utf8 draft cannot be  
> expressed as a profile of Stringprep (which is actually as it should be,  
> because it is not trying to restrict itself to 'identifier's).
> 
> 2.4.  The ALT-ADDRESS and ATOMIC parameter
> 
> I was expecting to see some syntax for these, and didn't. I think you have  
> to say that they take the form of <esmtp-param>s as defined in RFC 2821,  
> where the esmtp-keyword is "ALT-ADDRESS" ("ATOMIC") and the esmtp-value is  
> an address ("yes" or "no"). Also that everything (except in addresses) is  
> case-insensitive.

yes, we will use the form defined in rfc2821.

      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
      RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
      Mail-parameters = esmtp-param *(SP esmtp-param)
      Rcpt-parameters = esmtp-param *(SP esmtp-param)
      esmtp-param     = esmtp-keyword ["=" esmtp-value]
      esmtp-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
      esmtp-value     = 1*(%d33-60 / %d62-127)
            ; any CHAR excluding "=", SP, and control characters

 for example :
    mail from : <utf-8CharactersA@idna>    alt-address=[email-masked] atomic=y
    rcpt to:      <utf-8CharactersB@idna>    alt-address=[email-masked] atomic=y     

yes, I will emphasize that the deifiniton of MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF> and      RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
is from rfc2821.

> 
>     ... The final delivery SMTP server
>     can revert the addresses even though they are as in all ASCII form.
> 
> s/revert/restore/
> s/as/now/

will update it.

> 
>     ... If the
>     ALT-ADDRESS value is not set by the sender but the value of ATOMIC is
>     'y', the sender SMTP server should apply some algorithmic
>     transformation such as punycode to the entire local part of IMA; ...
> 
> No, from the POV of the server that might be going to downgrade the  
> address, the "sender" is actually an SMTP "client" (which might be another  
> server, or might be an MUA).

so we change the word "sender" to "email user", is it ok?

> 
> s/should/SHOULD/ (or is it MAY?)

according to our current design logic, we use SHOULD.

> 
> But you cannot say "such as punycode". You need to specify exactly what  
> transformation is to be used (or more likely point to the downgrade  
> document to specify it). But it certainly won't be punycode, because  
> punycode destroys all case distinctions AIUI, which is not good enough for  
> local parts.

it seems that now we still do not get consensus about this issue: which transformation method is used.
so I will point to the downgrade document to specify it.

> 
>     The suggested algorithmic transformation is punycode if the value of
>     ALT-ADDRESS is not set by sender and the value of ATOMIC is 'y' when
>     SMTP servers can not support IMA.  Since the prefix "xn--" had been
>     used for IDNA, it is better that other prefix such as "bq--" is used
>     for the local part of converted version of the primary address to
>     avoid the potential confusion.
> 
> No, it must be more than "suggested", as I said above (otherwise the  
> recipient will not be able to understand it). Better to omit this  
> paragraph entirely, and leave it to the downgrade document to worry about  
> prefixes such as "xn--".

I will point to the downgrade document to specify it.

> 
> 2.5.2.  Trace Fields
> 
>     Internationalized domain names in Received fields must be transmitted
>     in the punycode form.  Addresses in "for" clauses need further
>     examination ...
> 
> Again, leave all this to the downgrade document. I think we now have some  
> sort of consensus on how to downgrade these, based on Newman's proposal.  
> But the downgrade document is the place to describe this (just as it is  
> the place to describe downgrading of all the other headers). The only  
> respect in which Trace fields are special here is that servers will also  
> be generating them, and then maybe immediately downgraded what they have  
> invented (well, there is an obvious optimization there).

yes, will consider it.

> 
> 3.2.  POP and IMAP
> 
> I don't think this section really belongs in this document. There will be  
> separate documents in due course.

yes, will consider it.

> 
> 3.3.  Impact to RFC 2476 and many email related RFC
> 
> Yes, your draft also needs to define which of your extensions apply to
>     RFC 2476 submission agents
>     RFC 3461 delivery status notification (what is actually needed there?)
>     RFC ???? LMTP
> 
> Essentially, you are extending all these in addition to RFC 2821. There  
> may be others as well.

yes, will consider it.

thanks a lot.
Yao Jiankang
CNNIC

> 
> -- 
> Charles H. Lindsey ---------At Home, doing my own thing------------------------
> Tel: +44 161 436 6131 Fax: +44 161 436 6133 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
> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ima
> 

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