The -10 version of this draft responds to all of the nits/editorial comments noted in the Gen-ART review of the -09 version. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, November 01, 2013 9:32 PM > To: Murray S. Kucherawy (superuser@xxxxxxxxx); gshapiro@xxxxxxxxxxxxxx; > ned.freed@xxxxxxxxxxx; General Area Review Team (gen-art@xxxxxxxx) > Cc: Black, David; Barry Leiba (barryleiba@xxxxxxxxxxxx); apps- > discuss@xxxxxxxx; ietf@xxxxxxxx > Subject: Gen-ART review of draft-ietf-appsawg-malformed-mail-09 > > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-appsawg-malformed-mail-09 > Reviewer: David L. Black > Review Date: November 1, 2013 > IETF LC End Date: October 29, 2013 > IESG Telechat date: November 21, 2013 > > Summary: This draft is basically ready for publication, but has nits that > should be fixed before publication. > > This draft discusses common errors in mail message syntax and provides > useful guidance on handling them. The draft is well written and likely > to be of significant value to implementers. > > Most of my comments relate to clarity, but none of them seem important > enough to be characterized as issues that really have to be fixed, > although the sloppy terminology usage in Sections 7.1.* comes close. > > I apologize for this review appearing slightly after the end of IETF > Last Call - there is too much going on in the weeks immediately before > this IETF meeting. > > Nits/editorial comments: > > The word "naked" is used a few times to refer to something that occurs in > isolation, without enclosure in another construct, e.g., a naked CR. This > idiomatic use of "naked" should be explained before it is used. > > In Section 1.1, I have always heard Postel's law as: > - Be conservative in what you send, and > - Be liberal in what you accept. > The change from "do" in this draft to "send" (above) seems useful, as > it should help focus the discussion in the second paragraph of Section > 1.1 - Postel's law, as I have understood it, has never blessed anything > remotely resembling there being "no limits to the liberties that a > sender might take." > > Section 5's section title "Mail Submission Agents" doesn't seem to be > connected to its MHS and MTA content. It would be useful to add a > sentence to remind readers, including this one ;-), of what Mail > Submission Agents are. > > Sections 7.1.* offers degrees of advice qualified by "safely", "usually", > "reasonably" and "should". There appear to be only two concepts: > - "safely": Do this all the time. > - "usually", "reasonably", "should": This is the recommended course > of action, but there may be exceptions. > While RFC 2119 is not intended for Informational documents, this is an > example of the sort of sloppiness that RFC 2119 is intended to clean up. > At the very least, the use of three words for essentially the same concept > is poor form, and RFC 2119 can be used in an Informational document when > appropriate caveats are provided in the terminology section that references > it. > > In Section 7.1.4, "Likewise" is not a good way to associate the second > example with the first, because it handles the missing parenthesis in a > rather different fashion (adds quotes instead of inserting the missing > parenthesis character). > > In Section 7.7, the first use of "8bit" occurs in "8bit material" but some of > the subsequent occurrences omit the word "material" - that word should be > used with all occurrences. > > idnits 2.13.00 generated a couple of warnings about obsolete references: > > -- Obsolete informational reference (is this intentional?): RFC 1113 (ref. > 'PEM') (Obsoleted by RFC 1421) > > -- Obsolete informational reference (is this intentional?): RFC 733 > (Obsoleted by RFC 822) > > In both cases, the reference appears to be intentional, and the warning > should be ignored. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@xxxxxxx Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >