- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Wed, 21 Nov 2007 10:28:55 -0000
- To: <public-bpwg-ct@w3.org>
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