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

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 29 May 2006 19:46:01 +0100

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.

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/

    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?

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.

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/

    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/

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

but in either case, "it" is too vague, so

s/it/all addresses (both in the envelope and in the message's header  
fields)/

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

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.

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/

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

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.

    ... The final delivery SMTP server
    can revert the addresses even though they are as in all ASCII form.

s/revert/restore/
s/as/now/

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

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

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.

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

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

3.2.  POP and IMAP

I don't think this section really belongs in this document. There will be  
separate documents in due course.

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.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 31 May 2006 10:00:16 +0100

On Mon, 29 May 2006 19:46:01 +0100, Charles Lindsey <[email-masked]>
wrote:

> "EAI", with the term defined somewhere in 1.3. Or maybe to "IEmail",  
> which is to be the EHLO keyword.

Oops! My Subject did not make it clear I was referring to
draft-ietf-eai-smtpext-00, though it was not hard to guess. Please correct
the Subject header in any reply that you make.