Subject: Re: [EAI] draft-ietf-eai-smtpext-11

From: "Yao Jiankang" <[email-masked]>
Date: Wed, 13 Feb 2008 12:13:15 +0800

thanks a lot for your detail comments for refining this document.

I will try to update it in the next version.

YAO Jiankang

>From: Alfred HÎnes <[email-masked]>
>Reply-To: 
>To: [email-masked], [email-masked]
>Subject: draft-ietf-eai-smtpext-11
>Date:Tue, 12 Feb 2008 10:56:48 +0100 (MEZ)
>
>Hello,
> after studying the Internet-Draft authored/edited by you,
>                 draft-ietf-eai-smtpext-11,
> I'd like to submit a few comments, mostly addressing textual
> flaws I found in that memo, and suggesting further improvements.
> 
> The items below are presented in textual order.
> To give more context, sometimes I quote larger blocks of text
> literally and show the replacement proposed using the shorthand
> notation:
> 
>    <original draft text>
> ---
>    <modified text>
> 
> I use change bars ('|' in column 1) and occasionally
> up/down pointing marker lines ('^^^'/'vvv') to emphasize
> the location of textual issues and/or proposed corrections.
> Modified text has been re-adjusted to match RFC formatting
> rules, where appropriate.  I also try to accomodate published
> RFC-Ed policy on style and punctuation etc. in my proposals.
> 
> 
> (1)  General
> 
> Please consider basing the document on the updated (work in progress)
> versions for RFC 2821 (and RFC 2822), to achieve a consistent
> document set and avoid referencing soon obsolete versions.
> 
> Most details won't need to be changed, but please check again.
> 
> 
> (2)  Section 2.6
> 
> The current draft text confusingly used three different spellings
> for the BODY parameter, within the span of a few lines:
>        BODY ,  'Body' , and  "Body" .
> I suggest to always use  BODY  (without quotes -- capitalization
> suffices as a kind of textual emphasis).
> Furthermore, some wording is a bit confusing.
> 
> Altogether, I recommend performing the following changes:
> 
> (2a)  2nd paragraph
>                                               [...].  The UTF8SMTP
>    extension MAY be used with the BODY=8BITMIME parameter if that is
> |  appropriate given the body content or, if the server advertises
> |  BINARYMIME [RFC3030] and the BODY=BINARYMIME is appropriate, with the
> |  BODY=BINARYMIME parameter.
> ---                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                                               [...].  The UTF8SMTP
>    extension MAY be used with the BODY=8BITMIME parameter if that is
> |  appropriate given the body content or, with the BODY=BINARYMIME
> |  parameter, if the server advertises BINARYMIME [RFC3030] and that is
> |  appropriate.
> 
> (2b)  3rd paragraph
> 
>    Assuming that the server advertises UTF8SMTP and 8BITMIME, and
>    receives at least one non-ASCII address, with or without ALT-ADDRESS,
>    the precise interpretation of "No 'Body' parameter", "BODY=8BITMIME",
>    and "BODY=BINARYMIME" in the MAIL command is:
> ---
>    Assuming that the server advertises UTF8SMTP and 8BITMIME, and
>    receives at least one non-ASCII address, with or without ALT-ADDRESS,
> |  the precise interpretation of 'No BODY parameter', "BODY=8BITMIME",
>    and "BODY=BINARYMIME" in the MAIL command is:
> 
> Note the use of single quotes to distinguish pure emphasis of a term
> from literal quotations (enclosed in double quotes).
> 
> (2c)  bullet #1
>                      vvvvvvvv
>    1.  If there is no "Body" parameter, the header contains UTF-8
>        characters but all the body parts are in ASCII (possibly as the
>        result of a Content-transfer-encoding).
> ---                  vvvvvv
> |  1.  If there is no BODY parameter, the header contains UTF-8
> |      characters, but all the body parts are in ASCII (possibly as the
>        result of a Content-transfer-encoding).
> 
> 
> (3)   Section 2.7
> 
> I suggest the following clarification:
> 
>    The information carried in the mail transport process involves
> |  addresses ("mailboxes") and domain names in contexts in addition to
>    the MAIL and RCPT commands and extended alternatives to them.  In
>    general, the rule is that, when RFC 2821 specifies a mailbox, this
>    specification expects UTF-8 to be used for the entire string; when
>    RFC 2821 specifies a domain name, the name SHOULD be in the form of
>    ACE labels if its raw form is non-ASCII.
> ---
>    The information carried in the mail transport process involves
> |  addresses ("mailboxes") and domain names in various contexts, in
>                                                ^^^^^^^^        ^
>    addition to the MAIL and RCPT commands and extended alternatives to
>    them.  In general, the rule is that, when RFC 2821 specifies a
>    mailbox, this specification expects UTF-8 to be used for the entire
>    string; when RFC 2821 specifies a domain name, the name SHOULD be in
>    the form of ACE labels if its raw form is non-ASCII.
> 
> 
> (4)   Section 2.7.2
> 
> I suggest the following clarification:
> 
>                 [...].  Otherwise, surprising downgrades can happen
>    during temporary failures, which is not a good thing.
> ---
>                 [...].  Otherwise, surprising downgrades can happen
> |  during temporary failures, which users might perceive as a serious
> |  reliability issue.
> 
> 
> (5)  Section 2.7.3 -- ABNF and anchor 11
> 
> This comes to big surprise.
> 
> For efficiency, SMTP supports "delayed branching", i.e. delivering
> to a mail exchanger a single copy of a message for multiple recipients;
> the MTA has to add its timestamp header field and then dispatch
> copies of the message to the next hop, unbundled (one per recipient)
> or bundled (multiple recipients with same next hop) as it fits to the
> implementation and the available resources of the MTA.
> 
> As clearly stated in RFC 2821, Section 4.4, third bullet (2nd one
> on page 50), the FOR clause should contain the <path> entries
> corresponding to all RCPT commands that have been given and are
> in effect for the data transfer.
> 
> If the FOR clause would be forced to only contain a single <path>
> entry, which one should be selected ???
> 
> The latest revision of the 2821bis draft I had reviewed,
> draft-klensin-rfc2821bis-06, stiil contains in Section 4.4:
> 
>    o  The FOR clause MAY contain a list of <path> entries when multiple
>       RCPT commands have been given.  This may raise some security
>       issues and is usually not desirable; see Section 7.2.
> 
> (Section 7.2 contains special considerations for "Bcc" recipients.)
> 
> The ABNF in that draft version does not match this text and is wrong,
> IMHO.
> 
> I therefore suggest to change back to allow a list of recipients
> in the FOR clause, in your draft.
> 
> 
> (6)  Section 2.7.3, last paragraph
> 
> I suggest the following improved text for clarification:
> 
> |  Except in the 'uFor' and 'uReverse-path' line where non-ASCII domain
> |  names may be used, internationalized domain names in Received fields
>    MUST be transmitted in the form of ACE labels.  [...]
> ---                     vvvvvvv    vvvv                vvvvv
> |  Except in the 'uFor' clause and the 'uReverse-path' value where non-
>    ASCII domain names may be used, internationalized domain names in
> |  trace fields MUST be transmitted in the form of ACE labels.  [...]
>    ^^^^^
> 
> (7)  Section 2.7.4.1, 1st line
> 
> s/the/a/
> 
> Rationale:
>   There may be multiple RCPT commands for a single mail transfer.
> 
> 
> (8)  Section 2.7.4.2, 1st paragraph below the ABNF fragments
> 
> Please change:
> 
>    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.  [...]
> ---
>    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 did not use the "UTF8REPLY" parameter, then either reply code
>           ^^^
>    252 or reply code 550 is used.  [...]
> 
> 
> (9)  Section 7.1
> 
> (9a)
> Please change the ref. tag "[EAI-framework]" to "[RFC4952]" and
> place the entry according to ascending RFC# order.
> 
> (9b)
> Please add the missing "STD 63, " tag to the [RFC3629] entry.
> 
> (9c)
> [RFC4234] now has been obsoleted by STD 68, RFC 5234.
> Please update the ref.
> 
> 
> (10)  Apendix A
> 
> (10a)  A.1, 1st bullet
> 
> To avoid ambiguity in the grammar, I suggest adding "which is" in:
> 
>    o  A conventional message is one that does not use any extension
>       defined in this document or in the UTF8header specification
> |     [EAI-utf8header], and which is strictly conformant to RFC 2822
>       [RFC2822].
>                             ^^^^^^^^^
> 
> (10b)  A.3, 2nd line
> 
> Add a space character to make the ref. parseable for the IEFT web tools:
>   s/(DSNs)[RFC3461]/(DSNs) [RFC3461]/
> 
> (10c)  A.5
> 
> RFC 974 has been obsoleted and incorporated into RFC 2821
> -- and you have not provided a ref. entry for it as well!
> 
> 
> Best regards,
>   Alfred HÎnes.
> 
> -- 
> 
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
> +------------------------+--------------------------------------------+
>

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