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
