[ACTION 897] Establish best current practice regarding withrawal of use of X- form

1.	FEEDBACK.

Five persons responded privately and in two different mailing lists. Here is the
list of public message exchanges, ordered chronologically.

www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00097.html
www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00096.html
lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0066.html
lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0044.html
lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0034.html
lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0029.html
lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0026.html
lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0022.html
lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0019.html


2.	HEADER FIELD MANAGEMENT.

Information about the registration and retirement of HTTP header fields is 
summarized as follows:

a) There is no complete process for managing the life-cycle of HTTP header 
fields. The only formalized aspect is the registration of fields on the IANA 
registries, which is specified in RFC3864 (also known as BCP90). The IETF 
considers things pragmatically on a case by case basis before fixing a policy.  

b) There are two IANA registries: a provisional and a permanent one. The 
provisional header field registry is intended to help developers and others 
find useful information about header fields and avoid naming conflicts, even
for fields whose usefulness is unclear; it is specifically not a declaration 
of standardization -- contrarily to the permanent registry. The registries are
found at www.iana.org/assignments/message-headers/message-header-index.html.

c) As such, it is possible to register a X-prefixed field in the provisional
registry. This has been the case for X-Archived-At, marked as "deprecated", 
and a corresponding non-prefixed field Archived-At, permanently registered and 
marked "standard". However, X-prefixed header fields are generally not 
registered at all.

d) Section 4.5 of RFC3864 indicates that a procedure similar to registration 
serves to retract a field or change its status. From the document, retracting a
registered field requires the standard where the field is defined to specifiy a
status change or a phasing-out procedure as well (e.g. marking a field as 
"deprecated", then "historic" in revisions of the standard, before deleting it 
from the registry).


3.	RECOMMENDATIONS.

>From the received feedback, it was suggested to proceed as follows if the 
non-X-prefixed header fields prove to be indeed useful:

a) Formally document the non-X-prefixed form in a standard with whatever status
is appropriate (possibly as a proposal for an IETF standards track).

b) Prepare a registration template for the non-X-prefixed field, with 
information about the standard and its current status.

c) Include a second template for the X-prefixed field to be lodged in the 
provisional registry, marking its status as "deprecated", and indicating the 
name of the preferred replacement field name (i.e. the non-X-prefixed one).

d) Submit header fields for registration as appropriate. If the fields are
already in use, or likely to be deployed soon in a significant number of
software systems, both submissions may take place sooner than later for 
inclusion in the provisional IANA registry.

e) Later, when sufficient consensus is demonstrated for the new proposals, an 
application may be made for making the new header field permanent (inclusion in
a W3C REC-track specification would generally be considered indicative of 
sufficient consensus).

f) Stop using the X-prefixed fields in implementations as soon as possible.


4.	X-DEVICE SCHEME.

Out of five correspondents, two were completely neutral with respect to the 
(X-)Device-* scheme; one did not see the point of it and why we would need these
header fields; two were clearly hostile, considering the scheme as inherently
flawed. 

The fundamental criticism is that a proxy must fill the standard fields with 
that information that allow the servers to produce optimal content. It should 
ask the server for the most appropriate representation for the device, and 
transform the response only if it is not ideal. If substitute values are 
unsuitable to generate mobile-optimized content, this means that the original
HTTP header fields must not be modified. 

Quoting:

"A content transformation proxy does not want the "server of mobile web 
applications" to return content that is adjusted specifically for that terminal.
If they did, they wouldn't need to change all of the request fields in the first
place to pretend not to be that terminal. They would just forward the original
request without change, or adjust the parameters in the modified request such
that device-specific media types are preferred over standard media types.

A content server DOES NOT want to know about some request parameters other than
what it is already designed to vary the representation. What you suggest would
require those servers to also Vary the content by these X-Device header fields
and specifically not comply with the standard fields for content negotiation.
In short, you are asking that servers fail to correctly handle the request as
specified and make caching far less effective at the same time, in addition to
doubling the latency on request parsing due to these useless header fields
being sent to servers that have no interest in reading them."

These criticisms correspond pretty much to the issue the community of mobile 
developers has been raising regarding that specific aspect of CT-proxies; they
thus indicate that the W3C would presumably have a hard time registering the 
X-prefixed or non-X-prefixed capability backup fields at IANA.


5.	OTHER ISSUES.

One of the correspondents mentioned that earlier work at IETF on mobile
applications may be relevant for the W3C BPWG: www.imc.org/ietf-medfree.

Quoting:

"In particular, the thrust of the work was to guide content adaptation through 
the description of fine-grained "media features" rather than identification of 
devices [...].
Some of the ideas were carried through into W3C work on CC/PP, though the RDF 
format is, of course, very different.  In particular, I always felt that the 
media features registry could be embedded in URI space (for use with CC/PP and 
other RDF formats) through proposals like www.rfc-editor.org/rfc/rfc3553.txt 
and www.ninebynine.org/IETF/URNs/draft-klyne-urn-ietf-conneg-01.txt (the latter
fizzled out for lack of support).
I note that the model underpinning the content negotiation framework we created
has some similarities with a (simplified) form of OWL (DL), and the mechanisms
for content negotiation and selection described there might alternatively be
provided by an OWL or description logic reasoner."

This may result in an action for somebody to investigate in the context of 
future work.



E.Casais

Received on Monday, 2 February 2009 09:30:38 UTC