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 at gmail.com); gshapiro at proofpoint.com;
> ned.freed at mrochek.com; General Area Review Team (gen-art at ietf.org)
> Cc: Black, David; Barry Leiba (barryleiba at computer.org); apps-
> discuss at ietf.org; ietf at ietf.org
> 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 at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>