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

From: Xiaodong Lee <[email-masked]>
Date: Fri, 02 Jun 2006 08:47:00 +0800

Good suggestion, Terminology issues should be considered, and I will 
update the meeting homepage to add this into agenda.

-- 
-- Xiaodong LEE [The best answer is doing]
   +86-10-58813020 
   mailto:[email-masked]
   http://www.lixiaodong.cn

John C Klensin wrote:
>
> Several comments below.  Let's make an agenda item for Beijing on 
> terminology to be used.  The decisions are more or less arbitrary, but 
> we need to be consistent.  And I, at least, have achieved confusion.
>
>
> --On Thursday, June 01, 2006 11:36 AM +0800 YAO Jiankang 
> <[email-masked]> wrote:
>
>>
>> ----- 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
>> ...
>>>     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.
>
> I don't understand this response, but I'm not sure I understand 
> Charles's comment, partially because there is no client practice yet.  
> My assumption is that clients or servers supporting EAI MUST be 
> fully-conformant with 8BITMIME.  I assume that makes the answer to 
> Charles's question not "supposed to" but "MUST".  As far as the 
> transport is concerned, the 2821 headers are just message content so, 
> if they are extended and transmitted in UTF-8 then 8BITMIME must be 
> present.   We could, in principle, define these extensions as 
> subsuming 8BITMIME, but it seems to me that would be error-prone and 
> of no particular advantage. Others may disagree; if so, we need to 
> discuss.
>
>>> 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.
>
> The downgrade document is the place to do it.  This runs into the "no 
> multiple encapsulations" rule and requires very careful 
> consideration.  My guess is that the UTF-8 headers doc needs to note 
> that it updates 2045 and that the downgrade one needs to note that it 
> updates 1652... but the differences in how headers are handled might 
> make a case for defining these extensions on their own, rather than by 
> reference to 8BITMIME, despite what I've said above.
>
>> ...
>>>     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.
>
> Harmless, but I think unnecessary.  The thing that is necessary is a 
> requirement that the keyword MUST NOT be sent unless the extension is 
> advertised, and we have that.
>
>> ...
>>     ....  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".
>
> Still not quite right, because either "message" or "mail body" also 
> contains content.  E.g., we have
>
>    Envelope
>    Headers
>
>    Body
>
> the restriction above applies properly to the first two, but it would 
> be a bad idea to accidentally try to specify how addresses are 
> represented in the message body itself.   For example, while the 
> address would not be usable, nothing prohibits
>    ....
>    Header-stuff...
>    Content-type: text/plain; charset=UTF-8
>
>    Hi there, my preferred email address is 
> [email-masked]
>    .
>
> today, with unextended SMTP (although a CTE would presumably be required)
>
>>> 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.
>
> The more of this sort of thing we can shift into the downgrading 
> document, the better off we will be.   It has to cover the material, 
> covering it here as well is just an invitation to inconsistency.   See 
> if it is possible to define the syntax and semantics of the parameters 
> but indicate that the information is not needed unless downgrading is 
> necessary; if downgrading is necessary, the downgrade document 
> specifies how they are used. Does that make sense?
>
>>> 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.
>
> Probably not, since the addresses in the RCPT commands need not appear 
> at all in the headers.   The usual general guideline probably applies 
> here -- to the extent possible, MTAs pay attention to the  envelope 
> only.  That makes any ALT-ADDRESS in the headers mostly useful for 
> forming replies at the receiving MUA.
>
>> ...
>>> 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).
>
> WYSIWYG is more or less equivalent to the fax constraint Charles 
> suggested earlier.  Because it is in the eye of the beholder, it is 
> basically impossible with Unicode.
>>
>> Yes, we should have our own Stringprep for the email local
>> part.
>
> We need to be careful here.  First, stringprep, as usually used, 
> specifies treatment of strings, potentially unnormalized ones, so they 
> can be compared.  I think we are going to get into bad shape if we 
> permit unnormalized/ uncanonicalized strings at all. See the 
> discussion in draft-klensin-net-utf8, but note that the conventions 
> recommended there are probably not appropriate for these addresses.  
> My guess is that we should stick fairly closely to NFKC, but others 
> probably want to comment on that. And, of course, doing anything with 
> NFKC or NFC gets us into the Unicode versioning mess.
>
> I thought we had agreed to prohibit control characters in non-ASCII 
> local parts -- in the past, they have been more trouble than they are 
> worth.   If we haven't, we need to discuss it quickly.  If we have, 
> then this document must be explicit about it.
>>> 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).
>
> That is correct and was intentional.
>> ...
>>>     ... 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?
>
> Please don't try to invent more terminology unless absolutely 
> necessary.  I would read "email user" as the human being who interacts 
> with the message-creating MUA, and that is certainly not what is 
> intended in all of the uses in that paragraph.  2821 uses "SMTP 
> client" and "SMTP server" where feasible and reverts to the 821 
> terminology of "SMTP sender" and "SMTP receiver" when needed for 
> clarity.  "sender SMTP server" is pretty close to a contradiction.   
> See above about getting as much of this into the downgrade document as 
> possible.
>
>> ...
>
>     john
>
>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ima
>

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