Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components
draft-lilly-field-specification-04

[Ballot comment]
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
  text.

  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.

[Ballot comment]
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
cleanup:

  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.

[Ballot discuss]
I could not parse this:

  A message header has 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.

This worried me in an Informational document:

4.1.2.2. Naming Conventions

  Some prefixes have developed as conventions.  Although not formally
  specified as reserved prefixes, these conventions are or have been in
  use in multiple fields with common semantics for each prefix.

The document then goes on to use RFC 2119 style shoulds for things
that are conventions.  This one, in particular, worries me:

4.1.2.2.1. Accept- prefix

  This prefix SHOULD be used for all extension fields intended for use
  in content negotiation [I1.RFC2295] and SHOULD NOT be used for fields
  which are not intended for such use.

2295 is an Experimental, and most of its Accept headers trace back
to HTTP, which seems like a better reference.  More importantly, HTTP
has cases like Accept-Ranges which are not exactly content negotiation.
While HTTP is MIME-like rather than MIME, it is probably good
for a document describing conventions to acknowledge its impact.

This document's stress on ABNF does not acknowledge that other
formal syntaxes may be used.  Given our recent statement, we may
wish to request that this be amended to include the possibility of
others being used.

I'm also pretty uncomfortable with the text in 4.4.5.  There are good
reasons why a header field might contain a URI, even though the
URI has an underlying dependency on the DNS.  Consumers of archived
messages can be well aware of these dependencies breaking over
time and may be designing for that result.  A SHOULD Consider (Given
that it is a considerations section) seems a lot closer to reality than
a SHOULD NOT.

Last call comments from Keith Moore:

I recommend publication of this document as an Informational RFC with the
following changes recommended:

- section 4.1.2 omits the List- prefix

- section 4.2.1

  [N1.STD11] is vague about where whitespace is permitted or required
  in header field syntax.  [N2.RFC2822] addresses that issue by
  defining grammar productions such as FWS and CFWS.  Extension field
  ABNF SHOULD clearly specify where comments, line folding, and
  whitespace are prohibited and permitted, and SHOULD use the RFC 2822
  grammar productions in ABNF for that purpose.

I disagree with this recommendation.  RFC822 is not vague about where
whitespace is permitted or required.  RFC2822 explicitly defines where it
(and comments) is permitted but the result was to make handling of white
space and comments non-uniform from one field to another, and this was
not necessarily a good idea.  Uniform handling in structured fields
(more in the style of RFC822) is better than having each field
arbitrarily decide where to allow comments or white space.


- something that isn't explicitly stated, and should be, is that header
  fields are part of the UA-to-UA protocol.  it is not appropriate
  to define new header fields to affect the behavior of mail transport.
  it may, however, be appropriate to define new header fields to
  affect MTA-level entities that operate at the UA level (with authorization
  from the originator or recipient), e.g.: format-conversion mechansisms
  or content filters.