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

["Murray S. Kucherawy" <[e-mail]>]

Hi Frank,

> -----Original Message-----
> From: Frank Ellermann [mailto:[e-mail]]
> Sent: Thursday, September 01, 2011 12:45 PM
> To: Barry Leiba
> Cc: Murray S. Kucherawy; [e-mail]
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt
> 
> Editorial nit section 2: s/BCP 14/RFC 2119/, a new BCP 14
> could be different, and RFC 2119 suggests to write RFC 2119.

The RFC Editor will update the references if they change between now and when this actually gets published. This is pretty standard boilerplate.

> 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" ;-)

There are two, actually.  I changed one to "needs to" and left the other.

> 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.

I'm not really sure we need to say more than what's already there.  This text looks fine with or without EAI being applied.  Does anyone else with good EAI fu have a comment here?

> 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.

The RFC Editor typically makes that change during the run-up to AUTH48.  I've used both the [RFCXXXX] and [this memo] notation before, so I'll change it to the latter.

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

I think it's correct as-is (and unchanged since RFC3462).

> 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.

This text is copied verbatim from RFC3462 and there's been no complaint that this is unclear and no errata posted.  What do others think?

> 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.

I disagree. You don't need to read and understand DSN-FORMAT and DSN-SMTP to implement this specification.  Thus, they're not normative here.

> 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,

Such sections are typically deleted before publication anyway.

The current Introduction section spells out the differences.  Really, there's only one.

> 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 :-)

Such warnings typically go in the PROTO writeup, not in the document itself, as I understand it.

-MSK