Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt

[Frank Ellermann <[e-mail]>]

On 30 August 2011 20:52, Barry Leiba wrote:

> For convenience, a link to the document is here:
>   http://tools.ietf.org/html/draft-ietf-appsawg-rfc3462bis

Thanks.  IMO the announce bot should be updated to offer this
popular link in addition to the official link.  What would it
take to arrange this?

> Let's see if we can make that date by getting reviews in now.

Editorial nit section 2: s/BCP 14/RFC 2119/, a new BCP 14
could be different, and RFC 2119 suggests to write RFC 2119.

I like the original "content-type" better than the perfectly
correct "media type", because it indicates the Content-Type
header field.

The draft follows the philosophy that any "may" (etc.) MUST
be either upgraded to MAY or replaced by "might" (or similar).
While I consider this line of thinking as patent nonsense, in
this draft the outcome is fine.  Because I don't believe in
this odd philosophy I won't tell you where I saw a surviving
lower case "should" ;-)

Maybe s/return path/return-path/ in the last paragraph of
section 3.  This could also go to a new "i18n considerations"
with a pointer to the EAI work:  The assumption that at least
the header is 7-bit clean is not more strictly true.  EAI is
out of scope, but nevertheless the 7-bit header assumption is
now far less clear than in 2003.

Section 4: s/this memo/rfcxxxx/  I forgot the xml2rfc magic
word for "this RFC", but if "this memo" ends up literally in
an IANA registry it makes no sense.  I do not trust that the
RFC editor or the IANA get such subtle details right.  Ditto
in section 3.

Section 4 encoding:  Do you really want "mail headers" here,
or should this be "mail header fields"?

Please replace "the header contains all header fields" by
"the header consists of header fields", and add a reference
to [MAIL] (RFC 5322) section 3.5.  Notably "the first blank
line" does not always terminate the header, if readers think
that "blank" includes WSP* CRLF.  It's a terminology question,
maybe s/blank/empty/ would be clearer.

References:  Nothing in [OLD-REPORT] is normative, because the
draft will replace and obsolete it.  In [OLD-REPORT] [DSN] and
[DRPT] were normative, I fail to see why these references are
demoted:  Please move both [DSN-FORMAT] and [DSN-SMTP] back to
normative.

Please add a section explaining the differences from RFC 3462
intended to be kept in the full Internet Standard.  I guess
that the existing document history is not intended to be kept,

Please add the required "downref" warning for all references
on standards track, same idea as for YAM 4409bis.  And please
inform the document shepherd that a publication as Internet
Standard is hereby "requested", or something :-)

-Frank