ISSUE-227 recap and continuation [was RE: FW (from Bryan): ISSUE-227 (When is new technology "new technology"?): How Useful will the CT Guidelines Doc be, without extensions to HTTP? [Content Transformation Guidelines]]

By way of response to Sean Owen, Sean Patterson and Bryan (below), here
are some further thoughts, followed by some suggestions for actions and
some routes forward:

On Sean Patterson's note [1] - I'm not actually clear that the F2F
expressed a consensus on any aspect of this, and re-reading the minutes
it seems some contradictory assertions were made and discussed. E.g.
diverging views were expressed as to whether or not User Agent
Modification was a recommended or a deprecated practices, and whether as
a result, X-Original-xxx fields should be used where the Proxy has
modified the User Agent's Headers. 

Looking at it this way, something has become clearer to me, which is
that the original user agent headers, all of them (modulo those that get
modified by proxies in the normal course of HTTP/1.1 operation), should
be made available to the server.

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)

In any case as Bryan notes clearly, there needs to be an additional
notification in the request that the CT Proxy is there and intends to
transform. This is not part of the exiting HTTP lexicon, so it seems to
me, a priori that in order for a server to know that a Transforming
Proxy is present, so degree of neologism in HTTP is needed.

On Sean Owen's note [2] - Well, as usual, "I don't disagee" (TM) however
I think we'd be letting the community down if we didn't at least come
away with a way of

a) a server knowing definitively that a transforming proxy is in the
path of the request (Bryan's 1 below)

b) a server having a wider vocabulary than "no-transform" - this latter
is really problematical, as if you don't use it a transforming proxy may
rearrange your content and you may not want it to, and on the other hand
if you do use it the proxy is not allowed even to gzip your content, and
worse still if your content is WML this seems actually to prohibit
transformation to WMLC. (Think this is Bryan's 2 below)

c) a server having a definite way of getting at original request headers
and knowing they are the original request headers. (per discussion
above)

Additional "nice to have" includes user selection of handheld vs desktop
presentation.

All of which, in my view, require some specification beyond what is the
literal word of RFC 2616

I'm afraid that up till now we haven't discussed Bryan's contribution
(which he points to below) which was intended to be for the F2F but
which didn't get discussed there.

My view is that this text is suitable for being included verbatim into
the document for discussion, so I'll do that modulo any immediate
feedback on it as called for below.

So the call to arms is as follows:

a) read and feedback on Bryan's note on the requirements [3]

b) commentary on what is the minimum level this document should achieve
- and that will inform in turn to what degree we need to bend exsiting
mechanisms (cf the suggestion above, and Bryan's alternative)

c) ref a note Phil Archer inserted into IRC at the F2F which is to point
out that the new HTTP work includes, I think, clarification and new
values for headers, but not new headers - we should make a formal liason
with that activity, I think.

d) Read and understand (sic) RFC 2295 and consider what mechanims might
be borrowed from it [knowing it is partly implelented in Apache but
probably not elsewhere]

e) read and comment on the current draft text [4]

Jo

[1] Sean Patterson's Comment
http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Nov/0010.html

[2] Sean Owen's Comment
http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Nov/0009.html

[3] Bryan's Requirements Note
http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Nov/att-0000/AT_T
_input_to_Content_Transformation_task_force.htm

[4] Currently proposed initial text for the Guidelines
http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Nov/0003.html


> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Jo Rabin
> Sent: 21 November 2007 09:01
> To: public-bpwg-ct@w3.org
> Subject: FW (from Bryan): ISSUE-227 (When is new technology "new
> technology"?): How Useful will the CT Guidelines Doc be, without
> extensions to HTTP? [Content Transformation Guidelines]
> 
> 
> Copying to ct list
> 
> -----Original Message-----
> From: member-bpwg-request@w3.org [mailto:member-bpwg-request@w3.org]
On
> Behalf Of Sullivan, Bryan
> Sent: 20 November 2007 19:03
> To: Mobile Web Best Practices Working Group WG
> Subject: RE: ISSUE-227 (When is new technology "new technology"?): How
> Useful will the CT Guidelines Doc be, without extensions to HTTP?
> [Content Transformation Guidelines]
> 
> 
> Jo,
> This is a good representation of the problem at hand and the key
> options. Like I said in Boston, any choice will damn us, including
> inaction. Especially functional changes (being new or semantically
> different/reused) to headers or values causes a variety of issues,
e.g.
> to interoperability (e.g. cache control as one of the more problematic
> areas of variance in browser behavior). But progress demands crossing
> that boundary when we have to. The question is can the CTTF make any
> substantial progress on CT without such functional changes?
> 
> The core requirements that I offered in
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Nov/0000.html
> point to the need of several things that cannot be provided, imo,
> without functional changes, e.g.
> - awareness of CT support in delivery context entities
> - entity selection of CT "features" to enable/disable
> - semantic disclosure of alternative representations (RFC 2295 may
help,
> but from an implementation perspective would still be largely new)
> 
> Other than these functional changes, all we can do is describe what
the
> CT proxy should offer/do based upon current headers or other
out-of-band
> information (e.g. from administration or at the presentation layer,
> without specifying how it was determined). That would be valuable at
> least though to identify where the real functional gaps are, and focus
> the followup work (which may require a charter change).
> 
> Best regards,
> Bryan Sullivan | AT&T | Service Standards
> bryan.sullivan@att.com
> -----Original Message-----
> From: member-bpwg-request@w3.org [mailto:member-bpwg-request@w3.org]
On
> Behalf Of Mobile Web Best Practices Working Group Issue Tracker
> Sent: Tuesday, November 20, 2007 9:42 AM
> To: member-bpwg@w3.org
> Subject: ISSUE-227 (When is new technology "new technology"?): How
> Useful will the CT Guidelines Doc be, without extensions to HTTP?
> [Content Transformation Guidelines]
> 
> 
> 
> ISSUE-227 (When is new technology "new technology"?): How Useful will
> the CT Guidelines Doc be, without extensions to HTTP? [Content
> Transformation Guidelines]
> 
> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/
> 
> Raised by: Jo Rabin
> On product: Content Transformation Guidelines
> 
> I took an action (ACTION-602) at today's CT Task Force Meeting to
raise
> this as a formal issue.
> 
> The options seem to me to be:
> 
> a) Cut back the proposed text to discussion of how to use no-transform
> and the Vary header, together with various heuristics relating to the
> nature of content (e.g. XHTML-MP, link headers and the like)
> b) Introduce new values for Cache-Control, which appears to be
condoned
> by HTTP/1.1 in the section on Cache-Control
> c) Try to use some headers that are introduced in RFC 2295 and have
been
> registered
> d) Invent entirely new headers
> 
> If we stuck to just a) we would achieve very little beyond what has
> already been promulgated, e.g. by dotMobi. On the other hand, going
> beyond that could be considered only borderline within our charter
> remit. Especially option d) which I don't favour.
> 
> Jo
> 
> 
> 
> 
>

Received on Wednesday, 21 November 2007 10:29:26 UTC