Subject: [EAI] Comments on SMTP extension

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 7 Apr 2006 16:59:03 +0200

All,

these are my comments on draft-yao-ima-smtpext-02. I haven't been 
following the last discussions in the list. If some of these issues (or 
any of those in my following mails) have already been dealt with, then 
just give me a pointer.

* Section 1.1: RFC 1869 is obsolete, current is 2821
* Section 1.2: "Domain part of the email address may be internationalized 
through IDNA". It should rather be "..has been internationalized..".
* Section 1.2: "Since older SMTP servers and the mail-reading clients 
[...] may not be prepared to handle these extended addresses, an SMTP 
extension is specified". This could be nitpicking, but I don't think that 
we are protecting those mail-reading clients with this SMTP extension. I 
would cross them out of that sentence.
* Section 2.2: "DNS MUST be processed into punycode form as specified in 
IDNA". I don't think that punycode (concrete ACE encoding) is relevant at 
all here. Punycode is part of the internals of IDNA. I suggest modifying 
the sentence to "DNS MUST be processed as specified in IDNA by means of 
the ToASCII() operation".
* Section 2.2: "and then MUST be compared as specified in IDNA". My 
experience is that people overlook this comparison definition, thus it 
would be practical to make an exact reference: Section 3.1.4 of RFC 3490
* Section 2.2: s/either punycode/either ACE/
* Section 2.2: "the original SMTP client SHOULD first verify that the 
string is valid for a domain name according to IDNA rules". Why and for 
which fields? And what if that fails? Reaction should probably depend on 
the exact field of failure appearance. That must be defined.
* Section 2.2: s/it MUST not attempt to parse/it MUST NOT attempt to 
parse/
* Section 2.2: s/Client MUST not transmit/client MUST NOT transmit/
* Section 2.3: "Change the definition of 'Atom' to permit either the 
definition above or a UTF-8 string". This complete liberalization of the 
local part makes me feel very uneasy, not all characters are appropriate 
to become part of an identifier (cf the Unicode Standard Annex 31, 
Identifier and Pattern Syntax).
* Section 2.3: RFC2234 is obsolete, current is 4234
* Section 2.3: Nitpicking "sub-domain = Let-dig [Ldh-str] / <any 
internationalized domain label specified by IDNA>" The former are a subset 
of the latter, thus "sub-domain = <any internationalized domain label 
specified by IDNA>" is enough for that informal purpose.
* Section 2.4: s/may set by sender/may be set by the sender/
* Section 2.4: "are data or instructions embedded in the address that the 
ACE process would hide". That should be ellaborated a bit more.
* Section 2.4: s/ATMOIC/ATOMIC/g
* Section 2.4: "the sender SMTP server can apply some algorithmic 
transformation such as punycode". "Can"? "Should"? "SHOULD"? "MUST"? I am 
for the latter in this point. In anycase the sentence would better be 
"..apply some ASCII compatible encoding transformation".
* Section 2.4: "IDNA may also be applied to the domain part". "may"? or 
"MUST"?
* Section 2.4: I couldn't find an explanation in the algorithm for the 
case in which neither ALT-ADDRESS nor ATOMIC are present. I guess 
rejection is the correct thing, but then, why is ATOMIC optional at all?
* Section 2.5: "the name should be in punycode form if its raw form is 
non-ASCII". "should" or "MUST"? Cf "may" two bullets ago. In any case, and 
since ToASCII(ascii)=ascii, the sentence should read "...always in ASCII 
encoded form".
* Section 2.5: "8BITMIME should be advertised". If 8BITMIME is a 
requirement for IMA, as I think it is, then it should be "8BITMIME must be 
advertised".
* Section 2.5.1: s/punycode form/ACE form/
* Section 2.5.2: "Internationalized domain names in Received fields should 
be transmitted in punycode form". "should"? "SHOULD"? Wouldn't it be 
better "MUST"?
* Section 2.5.4: It is moot since the inclusion of the "i18n-mail" header

Best regards,
Marcos

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