thanks a lot!
we will do it soon. YAO Jiankang ----- Original Message ----- From: "Miguel Garcia" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Chris Newman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: "General Area Review Team" <[email protected]> Sent: Monday, March 24, 2008 6:21 AM Subject: Gen-ART review of draft-ietf-eai-smtpext-11.txt >I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > > Document: draft-ietf-eai-smtpext-11.txt > Reviewer: Miguel Garcia <[EMAIL PROTECTED]> > 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) > > > > /Miguel > > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Siemens Networks Espoo, Finland > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
