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

[Frank Ellermann <[e-mail]>]

On 1 September 2011 23:51, Murray S. Kucherawy wrote:

Hi,

 [2119bis]
>> 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 problem isn't a new 2119bis published before 3462bis, but
a new BCP 14 published after 3462bis with incompatible terms.

The standard boilerplate (as specified in 2119) says "2119",
and with a fresh existing 2119bis I-D all I can say is "there
be dragons".  If you like a fight with dragons it's okay, you
have been warned.

 [i18n/EAI]
> 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.

What's not more fine is its silent message header = US-ASCII
assumption, and switching this paragraph into an i18n section
with an informative EAI WG reference could help readers, who
are not yet aware of it.  I certainly don't insist on it, it's
just what I would try to warn readers, and besides I like the
BCP 18 (IETF charset policy) rule about "i18n considerations".

 [obs-FWS]
>> 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.

The "blank line" business is copied verbatim, and the <obs-FWS>
issue is addressed in RFC 5234 and RFC 5322 among many others.

Would "empty" be clearer than "blank"?  I don't trust that my
"DEnglish" means anything for others, but I'm sure about some
<obs-FWS> issues discovered long after RFC 3462 was published.

The "header contains all header fields" is not a verbatim copy,
and it sounds odd, because it contains nothing else, but that
could be again a bad case of "DEnglish" on my side.  Whatever
this paragraph tries to say, the real specification including
warts such as <CFWS> and <obs-FWS> is in RFC 5322 section 3.5
(and more), and it is *not* as simple as RFC 3462 puts it.

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

ACK, maybe RFC 3462 got this wrong when it replaced *all* old
RFC 1892 "references" by new RFC 3462 "normative references" -
the complete lack of "informative references" is suspicious.

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

ACK.  And very necessary, for starters it must be possible to
send an abusive multipart/report within a multipart/report.

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

NAK, there are two procedures, one old and horrible, and the new
and painless RFC 4897 procedure.  For an application of the new
procedure compare:
<http://tools.ietf.org/html/draft-ietf-yam-rfc4409bis-02#appendix-B>

Otherwise I'd say next stop WG LC followed by PubReq,

-Frank