Document: draft-ietf-eai-smtpext-11.txt Reviewer: Miguel Garcia Review Date: 2008-03-23 IETF LC End Date: 2008-03-24 ch Summary: The document is almost ready for publication as an Experimental RFC, however, I have a couple of questions and issues that should be considered. Comments: - I am missing an Overview of Operation section. I think this section should be Section 2 (and the current Section 2 and following will get a higher number). This Overview of Operation section should describe in non-normative text what this extension does. For example: This document provides an extension to SMTP that allows the usage of internationalized e-mail address, which are encoded with UTF-8 characters. UTF-8 characters can appear in any place where a mailbox can appear in RFC 2821. This extension addresses downgrading by adding a new ALT-ADDRESS parameter to the MAIL and RCPT commands of SMTP that can contain alternative ASCII-only mailboxes. The extension is identified with the token "UTF8SMTP"... etc. - The ABNF in Section 2.3 includes: ucharacter = atext / UTF8-non-ascii ; Replace character in RFC 2821, section 4.1.2 ; atext is defined in RFC 2822 However, I didn't find the 'character' ABNF in RFC 2821. Am I missing something or is there an oversight here? - Section 2.7.4.2, second paragraph, the text reads: The "UTF8REPLY" parameter does not use a value. If the reply to a VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP client does not use the "UTF8REPLY" parameter, then either reply code 252 or reply code 550 is used. I would like your opinion on the following comment. I suspect the sentence "... is used" should be promoted to normative, perhaps something like "then the server MUST use either the reply ocde 252 or 550". Do you agree? - IANA Considerations Section. I think this section requires quite a bit of improvement. For those registries that already exist, the document has to clearly identify the registry and subregistry by name and the value that IANA has to add, such as a descriptive text. For example, I suggest as a replacement of the first paragraph: This document instructs IANA to add a new value "UTF8SMTP" to the SMTP Service Extension subregistry of the Mail Parameters registry, according to the following data: Keywords Description Reference ------------------- ---------------------------------- --------- UTF8SMTP Internationalized e-mail address [RFCXXXX] The second paragraph of the IANA considerations section is more complicated, because it adds a value to a registry that is in the process of being created. Hmmm.... Now that I have checked [SMTP-Codes], your draft does not even follow the template for registration of new codes. You need to re-write this paragraph. Perhaps you can write something like this: This document adds new values to the SMTP Enhanced Status Code subregistry of the Mail Parameters registry. The registration data is as follows: Code: 5.6.x Sample Text: The ALT-ADDRESS is required but not specified Associated basic status code: 553, 550 Description: This indicates the reception of a MAIL or RCPT commands that required an ALT-ADDRESS parameter but such parameter was not present. Defined: RFC XXXX. (Experimental track) Submitter: [Your name] Change controller: IESG. And so on with the other 3 enhanced status codes. Last, third paragraph deals with the Mail Transmission Types registry (which is actually a subregistry), but it fails to mention the name of the main registry, which is Mail Parameters registry. Minor issues: - The front page says that this document updates RFC 4952, but fails to say that it also updates RFC 2821 and RFC 2822. - Section 1, s/extended e-mail transport protocol [RFC2821]/simple mail transfer protocol [RFC2821] - Section 1, at the end... when the text mentions UTF-8, add a reference to RFC 3629. - Section 1.3. The first paragraph is incorrect. The correct text is: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. - Section 1.3, 3rd paragraph. Expand ABNF - Section 2.2, 2dn paragraph. Expand ACE, and perhaps give a short description of ACE labels. - Section 2.3, above the ABNF: RFC 4234 has been replaced by 5234. - Last paragraph in Section 2.3, s/udomain/uDomain (two occurrences)