Re: [agenda] CT Teleconference Tuesday 18 February 2008

Hi Jo,

Thanks for the pointer, I wasn't there at the time (although I suddenly 
recall I saw that list in Boston's F2F), it's extremely useful!


Not trying to bury you in yet other things, let me just try to
rephrase what I'm willing to say with that 2. "Grounding In Reality" and 
the whole gateway thing:

1. grounding on existing technologies
-------------------------------------
That links to the thread you mention.

With existing technologies, I don't see how we can meet all the 
requirements we may want to cover: "negociation" between our 3 actors 
will be somewhat limited.

My feeling is that content negociation and adaptation in the future 
would need more elaborate tools. That's beyond our scope here, and may 
be better addressed by other on-going works: UWA-DIAL?, OMA-DPE?
(I'm not saying we're not smart enough to do that, I'm rather saying 
we're not chartered to do that within the BPWG...)

I'm personally fine with sticking to existing technologies (with an 
exception to the rule re the User-Agent header), although one may wonder 
whether our guidelines would be worth the time we spend on them...


2. grounding on existing CT-proxies
-----------------------------------
I have the feeling that if we come with guidelines that address a 
CT-proxy that doesn't exist for real, we would be missing our point. Am 
I the only one?

In practice, CT-proxies, as introduced by carriers (that's what 
triggered the creation of the TF I think, but then I wasn't there...), 
do more than "just CT": they also "control" what the user may access and 
impose some transformations based on the carrier's rules. We're not to 
say anything about whether this is good or bad, that just happens. My 
point is that if we don't take that into account, the guidelines would 
address a small part of existing CT-proxies where they could be 
respected, but from an external point of view the guidelines wouldn't be.

That's why:
- I would consider the existing CT-proxy to be a gateway (I don't want 
to change the wording in the guidelines, I'm talking about the scope of 
what a CT-proxy is for the guidelines)
- I would fancy a view where we say that the user is controlling the 
CT-proxy, except that he should take a glimpse at the Terms&Conditions 
he accepted because he might have agreed to leave that control to his 
carrier. This view doesn't give much power to the CP, except to say that 
he doesn't want "real" CT to take place, and to refuse to serve a 
request when it discovers there's a CT-proxy on the line.


Feel free to be rude if polite takes longer, I should survive (well, I 
hope ;))

François.



Jo Rabin wrote:
> Hi Francois
> 
> In respect of 2. "Grounding In Reality" there is a thread starting at [1] on possible bits and pieces of HTTP that might be pressed into service for CT. I remain intrigued by the 300 response.
> 
> I have much to say in respect of your earlier extremely comprehensive work on ACTION-603 but have been buried in other things, so haven't, for which I can only apologise. I will try to write a polite rebuttal of the "gateway" argument tomorrow morning. 
> 
> Jo
> 
> [1] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0023.html
> 
> 
> 
> 
>> -----Original Message-----
>> From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org]
>> On Behalf Of Francois Daoust
>> Sent: 18 February 2008 14:28
>> To: public-bpwg-ct
>> Subject: [agenda] CT Teleconference Tuesday 18 February 2008
>>
>>
>> Hi,
>>
>> This is the proposed agenda for tomorrow's teleconf.
>> It includes some of my suggestions, but note they are nothing more than
>> "stupid suggestions" to trigger ideas:
>>
>>
>> Chair: François
>> Staff Contact: François
>> Known regrets: none
>>
>> Date: 2008-02-18T1500Z for 60mn
>> Phone: +1.617.761.6200, +33.4.89.06.34.99, +44.117.370.6152
>> Conference code: 2283 ("BCTF") followed by # key
>> IRC channel: #bpwg on irc.w3.org, port 6665.
>>
>> Current draft:
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
>> drafts/Guidelines/080124
>>
>>
>> Agenda:
>>
>> 1. Introduction
>> ---------------
>> - we should present our draft to the WG before Seoul's F2F, for
>> validation/comments and hopefully publication as First Public Working
>> Draft.
>> - goal is to ground our guidelines on reality.
>>
>>
>> 2. Grounding on reality
>> -----------------------
>> - "available" technologies:
>>      HTTP Accept, Cache-Control, Vary, Via headers
>>      Extensions to Cache-Control (I tend to think that's already "new"
>> technology...)
>> - ... and what else?
>> - we may reference "new" technologies as possible ways to improve the
>> situation in the future: OMA-DPE for instance?
>> - in practice, CT-proxies do more than just CT of content "with a view
>> to making it more suitable for mobile presentation". Terms and
>> conditions exist. Headers/Footers may be "compulsory", ... That's
>> probably beyond the scope of the document, but that means
>> "Cache-Control: no-transform" will never be totally respected.
>>
>>
>> 3. Client Origination of request (§3.1)
>> ---------------------------------------
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
>> drafts/Guidelines/080124#d0e306
>> - let go of all the HTTP CT-proxy control mechanisms in the request,
>> save, possibly the Cache-Control: no-transform directive?
>> - replace HTTP control mechanisms with an options-oriented approach,
>> leaving the practical implementation of the approach as CT-dependent?
>> (for legacy browsers, that's a WEB interface, in the future... using
>> OMA-DPE?)
>>
>>
>> 4. Proxy Receipt, Forwarding or Response to a Request (§3.2)
>> ------------------------------------------------------------
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
>> drafts/Guidelines/080124#d0e339
>> - remove all mentions to Cache-Control extensions?
>> - remove indications of "I will transform"?
>> - use a generic "X-Modified-Headers" (or any other name) HTTP header to
>> reference the original headers modified by the CT-proxy and in
>> particular the original User-Agent?
>>
>>
>> 5. Server Response to Proxy (§3.3)
>> ----------------------------------
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
>> drafts/Guidelines/080124#d0e501
>> - stick to Cache-Control: no-transform?
>> - recommend the use of the HTTP Vary header
>>
>>
>> 6. Proxy Receipt and Forwarding of Response from Server (§3.4)
>> --------------------------------------------------------------
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
>> drafts/Guidelines/080124#d0e581
>> - anything else to say?
>>
>>
>> 7. Proxy Response to Client (§3.5)
>> ----------------------------------
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
>> drafts/Guidelines/080124#d0e594
>> - mention of "mandatory" transformations that may be done by a CT-proxy
>> as agreed by terms & conditions and/or as imposed by carriers?
>>
>>
>> François.
>>
>>
>>
> 
>

Received on Tuesday, 19 February 2008 08:29:33 UTC