RE: [agenda] CT Teleconference Tuesday 18 February 2008

> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org]
> Sent: 19 February 2008 08:29
> To: Jo Rabin
> Cc: public-bpwg-ct
> Subject: 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.

Yes, I agree.

> 
> 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...)
> 
Yup we are on the same page. Though I am beginning to wonder if I am indeed smart enough to hold 17 mutually contradictory requirements in my head at the same time.


> 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...
> 
Yes, we have spent a long time, but we have learned along the way. We could have had a simpler rec out sooner. If you don't aim for the stars, you definitely won't reach them, but then again, aiming for them is no guarantee you will reach them.

Fwiw my original proposal was to produce a quick note and work on whether we could do something more sophisticated in the background. That wasn't the way it worked out so we (dotMobi) thought it would be useful to do something:

[1] http://dev.mobi/files/ContentTransformation_consultative.html
[2] http://dev.mobi/node/612

Which seems to be along the lines you suggest.

> 
> 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.
> 
Well, I suppose there are a couple of different things here. 

It's up to the providers of CT proxies to decide what they think their value add is. It's up to consumers, I suppose, to exercise their choice of types of data service plan, though that is altogether too naïve a way of painting the picture. We're certainly not here to provide a standardised framework for CT value added features - whatever they are. Though as you say, ignoring them altogether would be unrealistic.

It's the purpose of the BPWG, in my view, to encourage content providers to provide a closer engagement between their content and their customers. And where CT is getting in the way of that I don't think we should be shy in saying so and saying that it is "bad" - assuming we have created a reasonable set of techniques for CPs to be aware of CT and tell the CT to get out of the way. The starting point, it seems to me, that the best place to do the user experience is at source.

So it is up to us, I think, to provide a means of dealing with the presence of CT when the content provider thinks that they do a better job of looking after their customer's experience, and/or when they think that the presence of such devices subverts their business model (by removing their advertising for example).

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

Hope to remain unfailingly polite!

> 
> 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 11:11:05 UTC