Content Transformation Guidelines 1b

Revision Description

Work needed on this draft:

1. Work Brian's suggestions into the text

I think the following require mention at least as heuristics, if not recommended practice as they do play a role:

a) a priori knowledge of device characteristics, as gleaned from a DDR;
				b) administrative arrangements, white lists etc.;
				c) heuristics, such as knowing which content types and DTDs are
				specifically mobile, looking for the presence of "handheld" in style
				sheets and @media attributes, looking for mobileOK labels;
				d) User interaction

In reference to one of Bryan's contributions, user interaction needs more thought and discussion - on the one hand we don't want to interrupt the user experience with excise tasks, yet on the other, in the end, the user must act to signal their intentions and this needs noting. E.g. there could be a note that the host should provide interactions that allow the user to have a choice of presentations and so should the proxy and the client, for that matter.

Another as yet unopened Pandora's box is that the discussion and proposed text below looks at the issues primarily from the point of view of "varying presentation from Thematically consistent URIs". What hasn't, as yet, been explored is how it all works if there is a common entry point to a site (Thematically consistent URI for a home page) which then dispatches via redirect to media specific versions. This is possibly rather more common than the previous case (e.g. redirect to example.com/mobile - or rather better, imo, example.mobi). Naturally, there will also be varying presentation even within a redirected solution. This whole area needs further thought.

Whatever we come up with does of course have to deal with conforming and non conforming and transforming and non-transforming proxies. There isn't, as yet, a use case analysis, it is a bit too soon for that, I think.

The philosophy here should be in line with existing HTTP practice, which is to fall back to safe behavior. Thus, when trying to distinguish reformatting behavior from recoding behavior, the objective is to fall back to "safe" known HTTP/1.1 practice for non conforming (unaware) and say things like:

Cache-Control: no-transform, allow-reencode

as this will result in a stricter interpretation by unaware participants. This behavior is discussed in detail in HTTP section 14.9.6 (reproduced below in this note for your convenience and see Sean's detailed list of references to points in the HTTP spec that need to be included also).

This, of course, immediately introduces the question as to whether we are over stepping the mark in introducing such extensions, and I think we need to be clear about that before going further. On the one hand HTTP makes it clear, in explaining how to introduce extensions that it expects such extensions to be introduced. On the other hand, we do typically take a conservative approach and say if it is not in the IANA registry then it's not an existing protocol and therefore beyond our scope. Introducing extensions to existing header values, to my mind falls short of introducing new headers. Though it's not clear that we can do what we need to if we don't do that, go through IANA registration and so on.

I think that we are going to need to do that and suggest we speak to this point tomorrow on our call, if necessary by joining forces with a group that is actually chartered to "invent new protocols". The alternative being a much more insipid document that only gets to a small subset of the problem.

I'd also like to bring the group's attention to the following RFCs:

RFC 2506 Media Feature Tag Registration Procedure
				RFC 2295 Transparent Content Negotiation
				RFC 2296 Remote Variant Selection Algorithm

RFC 2295 is experimental, but actually gets to some of the points we want to make, though doesn't exactly address what we are doing. It's rather a lengthy and detailed read, and has a lot of features that we don't need. It does, however, introduce a couple of headers and field values which have been IANA registered. Also, the main points of the negotiation are implemented in Apache in mod_negotiation (see [APACHE]).

[APACHE] http://httpd.apache.org/docs/2.2/content-negotiation.html

IANA registration is probably a bit of a nuisance, and may be something we don't need to do - e.g. it would seem that the q parameter for content type and much else is not registered. For those of you who fancy a bit of train spotting, I think you'll find registered things at [IANA], though I confess I find this all a bit impenetrable and difficult to navigate.

[IANA] http://www.iana.org/numbers.html

I have tried to take into account the contributions and discussions on the list, especially those threads starting at the following points. Some are quite lengthy threads and can be followed with the "Next in Thread" link:

Magnus's original proposal for 2.1 [1] elaborated in the text below

[1]
				http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Sep/att-0014/00-p
				art
				
				Sean Patterson's original proposal for 2.3 [2] points included in the
				text and included verbatim
				[2] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Sep/0029.html
				
				Aaron's contribution for section 2.3 [3] points included in the text and
				included verbatim
				[3] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Sep/0025.html
				
				Pointer to ISSUE-222 TAG Finding on Alternative Representations
				[4] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0011.html
				
				Pointer to ISSUE-223 (Jo's CT Shopping List): Various Items to Consider
				for the CT Guidelines
				[5] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0012.html
				
				Pointer to ACTION-575 Techniques for Guidelines Document
				[6] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0023.html
				
				Scope of CT Guidelines
				[7] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0041.html

3. Find a solution to how to communicate the orignal user agent headers: This can be done in at least the following ways: a) by including X-Original-xxx headers b) by including a request body that contains either the original headers or the headers the proxy would have sent if it had replaced the original headers c) by requesting twice, first with the original headers, then if permitted/desirable with the modified headers [understood the limitations wrt GET only, but that is true of any of these solutions, I think], then caching the inference as to whether to modify headers in future requests d) by decorating the modified headers to allow inference as to what their previous value was (e.g. as suggested in the draft sent as response to ACTION-581 adding a parameter where a content type has been inserted in the Accept header)