Re: #231: Considerations for new headers

On 2011-07-01 07:05, Mark Nottingham wrote:
> Revised proposal:
> ...

+1 - we may want to add more things or tune, but we should get this in.

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/231/231.diff>

The new text would read:

3.  Header Fields

    Header fields are key value pairs that can be used to communicate
    data abou the message, its payload, the target resource, or about the
    connection itself (i.e., control data).  See Section 3.2 of [Part1]
    for a general definition of their syntax.

3.1.  Considerations for Creating Header Fields

    New header fields are registered using the procedures described in
    [RFC3864].

    The requirements for header field names are defined in Section 4.1 of
    [RFC3864].  Authors of specifications defining new fields are advised
    to keep the name as short as practical, and not to prefix them with
    "X-" if they are to be registered (either immediately or in the
    future).

    New header field values typically have their syntax defined using
    ABNF ([RFC5234]), using the extensions defined in Section 1.2.1 of
    [Part1] as necessary, and are usually constrained to the range of
    ASCII characters.  Header fields needing a greater range of
    characters can use an encoding such as the one defined in [RFC5987].

    Because commas (",") are used as a generic delimiter between field-
    values, they need to be treated with care if they are allowed in the
    field-value's payload.  Typically, components that might contain a
    comma are protected with double-quotes using the quoted-string ABNF
    production (Section 3.2.3 of [Part1]).

    For example, a textual date and a URI (either of which might contain
    a comma) could be safely carried in field-values like these:

      Example-URI-Field: "http://example.com/a.html,foo",
                         "http://without-a-comma.example.com/"
      Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"

    Authors of specifications defining new header fields are advised to
    consider documenting:

    o  Whether the field is a single value, or whether it can be a list
       (delimited by commas; see Section 3.2 of [Part1]).

    o  Under what conditions the header field can be used; e.g., only i
       responses or requests, in all messages, only on responses to a
       particular request method.

    o  Whether it's appropriate to list the field-name in the Connection
       header (i.e., if the header is to be hop-by-hop, see Section 9.1
       of [Part1]).

    o  Under what conditions intermediaries are allowed to modify the
       header field's value, insert or delete it.

    o  How the header might interact with caching (see [Part6]).

    o  Whether the header field is useful or allowable in trailers (see
       Section 6.2.1 of [Part1]).

    o  Whether the header field should be preserved across redirects.


Feedback appreciated, Julian

Received on Friday, 26 August 2011 15:57:43 UTC