On Properly defining the X-Device-* headers

This is ACTION-879: Ask [someone] about adding IETF headers.


Context
-----
I actioned myself a couple of weeks ago to investigate how we could 
properly have a specification that references a "new" HTTP header. The 
reason being that I feared it will not last long before someone knocks 
at the door and say we cannot just mention X-Device-* en passant in the 
guidelines.

We actually already received a last call comment that goes in this 
direction:
 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2040
  "4.1.5.5 defines a protocol.  This should be in an Internet Draft, not 
in a guidelines document."


Conclusion
-----
I discussed with several W3C team members, used to playing with this 
kind of needs.
In short, the discussions confirm my initial thoughts and we should 
probably register the new HTTP header fields, as explained below.


In more details
-----
We can comment on an existing practice about the X-Device-* headers. 
Mandating that CT-proxies add these headers in a recommendation-to-be is 
stronger than a mere comment, though, and normally requires that the 
headers be properly registered in the corresponding IANA registry. The 
fact that we're not chartered to create new technology and writing a 
guidelines document should not be such a blocking factor if we really 
think this is needed (and this is where we may ground our decision on 
the fact that it is an existing practice).

There is no way to register an "X-" HTTP header. By definition, the "X-" 
prefix is for experimental use. There is also no way to register a 
non-defined list of HTTP headers. This means that we should register 
real HTTP headers: "Device-*", "Original-*" or "Received-*", where "*" 
is to be replaced by the exhaustive list of possibilities (User-Agent, 
and the list of Accept headers).

There exist two registries, the permanent and the provisional one:
  http://www.iana.org/assignments/message-headers/message-header-index.html

In the end, the headers would have to be defined in the permanent 
registry, but until the specification is stable, we should simply target 
the provisional one.

Registering a header in the provisional registry is actually quite 
simple, and defined in RFC 3864, section 4. Registration procedure:
  http://www.rfc-editor.org/rfc/rfc3864.txt

It's a 3-step process:

1. Construct a header field specification
In the guidelines, this means we need to define the headers more 
precisely (precise list of headers and a defined syntax i.e. that of the 
original headers).

2. Prepare a registration template
The template is copied for reference at the end of this email

3. Submit the registration template
Meaning the completed template should be sent to 
ietf-message-headers@lists.ietf.org and after a few weeks of review, to 
iana@iana.org.


Side note: note there already exist 2 headers that start with 
"Received": "Received" and "Received-SPF". It may not be considered a 
good practice to register other HTTP headers that look like existing 
ones but that are for a different use.


Francois.



-----
For reference, here is the template to fill to register a provisional 
HTTP header field.

PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:

    Header field name:
       The name proposed for the new header field.  This SHOULD conform
       to the field name specification details noted in Section 4.1.

    Applicable protocol:
       Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
       "netnews" (RFC 1036), or cite any other standards-track RFC
       defining the protocol with which the header is intended to be
       used.

    Status:
       Specify: "provisional".  This will be updated if and when the
       header registration is subsequently moved to the permanent
       registry.

    Author/Change controller:
       The name, email address, and organization name of the submission
       author, who may authorize changes to or retraction of the
       repository entry.  A postal address, home page URI, telephone and
       fax numbers may also be included.
       If the proposal comes from a standards body working group, give
       the name and home page URI of the working group, and an email
       address for discussion of or comments on the specification.

    Specification document(s):
       Reference to document that specifies the header for use with the
       indicated protocol.  The document MUST be an RFC, a current
       Internet-draft or the URL of a publicly accessible document (so
       IANA can verify availability of the specification).  An indication
       of the relevant sections MAY also be included, but is not
       required.

          NOTE: if the specification is available in printed form only,
          then an Internet draft containing full reference to the paper
          document should be published and cited in the registration
          template.  The paper specification MAY be cited under related
          information.

    Related information:
       Optionally, citations to additional documents containing further
       relevant information.

Received on Friday, 14 November 2008 15:16:51 UTC