Subject: [Gen-art] Gen-ART review of draft-ietf-eai-smtpext-11.txt

From: Miguel Garcia <[email-masked]>
Date: Mon, 24 Mar 2008 00:21:06 +0200

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-masked]>
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-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 24 Mar 2008 09:01:53 +0800

thanks a lot!

we will do it soon.

YAO Jiankang