Last Call Review of draft-ietf-appsawg-malformed-mail-09
review-ietf-appsawg-malformed-mail-09-genart-lc-black-2013-11-04-00

Request Review of draft-ietf-appsawg-malformed-mail
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-11-19
Requested 2013-10-17
Other Reviews Genart Telechat review of -10 by David Black (diff)
Secdir Last Call review of -09 by Scott Kelly (diff)
Opsdir Telechat review of -10 by Lionel Morand (diff)
Review State Completed
Reviewer David Black
Review review-ietf-appsawg-malformed-mail-09-genart-lc-black-2013-11-04
Posted at http://www.ietf.org/mail-archive/web/gen-art/current/msg09221.html
Reviewed rev. 09 (document currently at 11)
Review result Ready with Nits
Draft last updated 2013-11-04
Review completed: 2013-11-04

Review
review-ietf-appsawg-malformed-mail-09-genart-lc-black-2013-11-04

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