Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components
RFC 4249

Note: This ballot was opened for revision 04 and is now closed.

(Scott Hollenbeck) Yes

(Brian Carpenter) No Objection

Comment (2005-05-11 for -)
No email
send info
Suggested edits from Michael Patton:

In section 4.1.1 I'd suggest splitting into two paragraphs.  I think
it would be clearer.  Here's my suggestion, with some additional minor

   Terms related to the Internet Message Format are defined in
   [N2.RFC2822].  Authors specifying extension header fields should
   use the same terms in the same manner in order to provide clarity
   and avoid confusion.  For example, a "header" is comprised of
   "header fields", each of which has a "field name" and usually has a
   "field body".  Each message may have more than one "header", viz. a
   message header and one or more MIME-part [N4.RFC2046] headers.

   For example, a message has a message header which contains a Date
   header field (i.e. a field with field name "Date").  However, there
   is no "Date header".  Use of such non-standard terms is likely to
   lead to confusion, possibly resulting in interoperability failures
   of implementations.

I would expand the simple sentence at the start of 4.1.2 to summarize
the difference between what you're using these two terms for.  I
understand it, I just think the document would read clearer with a
little more description to lead into this.

I think that the considerations of Appendix A will be moot in the RFC,
and thus it could also be removed as Appendix B is noted.

(Margaret Cullen) No Objection

(Russ Housley) No Objection

Comment (2005-05-06 for -)
No email
send info
  Please delete the second paragraph of the Abstract.

(Mark Townsley) No Objection

(Ted Hardie) (was Discuss) Abstain

Comment (2005-05-31)
No email
send info
Updated to abstain after seeing preview copy of -04; Scott will 
follow up when the official copy is released.

(Bert Wijnen) No Record

Comment (2005-05-13 for -)
No email
send info
As reported via email before yesterdays telechat, I noticed a pretty
strange (and in my view not-appropriate) disclaimer in this document:

Appendix A. Disclaimers

   This document has exactly one (1) author.

   In spite of the fact that the author's given name may also be the
   surname of other individuals, and the fact that the author's surname
   may also be a given name for some females, the author is, and has
   always been, male.

   The presence of "or she", "/SHE", "each", "their", and "authors"
   (plural) in the boilerplate sections of this document is irrelevant.
   The author of this document is not responsible for the boilerplate

   Comments regarding the silliness, lack of accuracy, and lack of
   precision of the boilerplate text should be directed to the IESG, not
   to the author.