[HTTP header fields] replacement for X-Device-* / position

A current idea in the CT guidelines is to introduce a new set of HTTP header
fields to formalize the X-Device-* ones deployed by some transcoders.

I would like to exhort the BPWG to reconsider this idea carefully.


1.	MIGRATION PHASE.

There can be no "big bang" migration neither of CT-proxies, nor of application
servers from one set of header fields to the other. Hence, there will be a 
migration period where both forms of fields exist in parallel.

Application servers will be obliged to support both forms, because they must
deal with the different pace of migration of various deployed proxies.

Transformation proxies must support both forms, to cater for application servers
at different stages of migration, and to deal with possible chains of CT-proxies
at different stages of migration.

The phasing out can last quite some time. I would like to point out that the 
field X-Archived-At, marked as "deprecated", has been present in the provisional
IANA registry since 2007-02-15.



2.	HTTP HEADER.

Currently, mobile application servers must deal with at least the following 
variants of HTTP header fields:

User-Agent:	X-Mobile-UA (Microsoft), X-Operamini-Phone-UA (Opera), 
		X-Skyfire-Phone (Skyfire), X-Device-User-Agent (Novarra),
		X-Original-User-Agent (Mowser).
Accept:		X-Device-Accept (Novarra).
Accept-Charset:	X-Up-Devcap-Charset (Openwave), X-Device-Accept-Charset
		(Novarra).
Accept-Language:X-Up-Devcap-Accept-Language (Openwave).

The new fields would increase, not decrease (because of the migration period)
the number of alternate fields to search for. This is not just a programming
hassle: it would further degrade the performance of application servers -- which
would have to peek into the HTTP header for up to 7 possible locations for the
user agent id, or in 4 places for the charset information. 


3.	BANDWIDTH PERFORMANCE.

Including alternate HTTP fields increases request overhead -- and this is not
negligible, especially if proxies end up sending capability fields in triplicate
(the standard but modified ones, originals in X-prefixed ones for compatibility,
and also in the new fields). 

>From the perspective of performance and avoidance of Internet congestion, this
is not a good direction to go.


4.	NEW TECHNOLOGY.

The charter of the BPWG excludes defining new technology. While the group has
taken great care to avoid introducing new technology in the CT guidelines, the
definition of new HTTP fields, and their subsequent registration, are clearly
in contradiction with this restriction.


5.	EVOLUTION.

In so far as the guidelines are supposed to bring order into existing practices,
it may be acceptable to refer to existing X-Device-* fields -- but introducing
new ones appears superfluous, especially considering that the BPWG is of the
opinion that a proper approach to CT-proxies requires its own fresh 
standardization endeavour (possibly Powder, section G.1). Introducing new 
header fields is therefore at least premature.


6.	IETF REGISTRATION.

Preliminary feedback from the IETF indicates that one can expect quite some
opposition to the new fields (or to the X-Device-* fields for that matter).


7.	BENEFITS.

Neither vendors and operators of CT-proxies, nor application developers are 
asking for the new fields, which bring them no tangible benefits whatsoever.
In fact, the scheme of substituting standard fields and placing original values
into backup fields has been the target of quite some critical comments from 
mobile developers in the first place.

Furthermore, the UAProf standard shows that the reliance upon X-* fields is no
obstacle for successful production deployments in the Web.



In conclusion, I suggest doing without replacements for X-Device-* fields at
this stage, and leaving the decision to a proper standardization framework for
content transformation on the Web.


E.Casais

Received on Monday, 2 February 2009 09:31:42 UTC