- From: Francois Daoust <fd@w3.org>
- Date: Tue, 19 Feb 2008 17:45:04 +0100
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
The minutes from our last call are available at:
http://www.w3.org/2008/02/19-bpwg-minutes.html
... and copied as text below.
Resolutions taken:
RESOLUTION: CT-proxy is an intermediary, transforming the content with a
view to making it more suitable for mobile presentation.
RESOLUTION: recommendation will be grounded (with as few exceptions as
possible) on existing technologies, and will specifically not employ
cache-control extensions
New action:
ACTION: Jo to redraft CT Guidelines based on conversation on this call
[recorded in http://www.w3.org/2008/02/19-bpwg-minutes.html#action01]
Time for sweet dreams (a bit early perhaps...)
Francois.
19 Feb 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Feb/0048.html
See also: [3]IRC log
[3] http://www.w3.org/2008/02/19-bpwg-irc
Attendees
Present
rob, francois, Bryan_Sullivan, DKA, SeanP, jo, AndrewS,
hgerlach
Regrets
Chair
francois
Scribe
Dan
Contents
* [4]Topics
1. [5]Intro
2. [6]Grounding CT on reality
* [7]Summary of Action Items
_________________________________________________________
Intro
Francois: want to emphasize where we should be going. Our goal is to
present a draft to the working group if possible before the next f2f
and then hopefully come to fpwd.
... most important thing to do right now is to ground our guidelines
on reality.
Fran�ois: We never go into details [in the document]
Grounding on reality
Francois: The main discussion we should have is the one we're having
on the mailing list.
... Grounding on reality:
... If we look at CT proxies from a long term perspective, it's
beyond the scope of our guidelines. In the future we'll have to use
new technologies that are not available today for CT proxies.
Possibly related to DIAl, possibly related to OMA work...
... In our BP working group we are not chartered to create those new
technologies.
... I see two ways we can go. The first way is to see the CT proxy
as a proxy - as an intermediary between the server and the end user.
If we do that, the CT proxy will have to comply with our guidelines.
In practice, many of the CT proxies actually rely on practices
imposed by the carrier and would not accept to obey these guidelines
[e.g. complying with no-transform]. Fear is that they would not be
followed therefore useless.
... Second way would be to say that the CT proxy is the carrier's
beast - and it's more like a user browser's extension and in that
sense it gives us more flexibility.
Bryan: I think the goal of the taskforce is useful. There are a
number of things we should consider. At the core, we have to think -
are we trying to define a service or improve an existing service - I
think it's the latter. So if that's true are we trying to improve
the oepratings of that service or improve the user experience of
such services. Again I think it's the latter.
... if we concentrate on user experience for CT experiences then we
can do a lot of good without defining new technologies.
Jo: It seems to be that this is about helping content providers who
have taken the trouble to comply with the BPs. They've created an
experience for the user that the user then perceives. If their
efforts are thwarted by intermediaries then BPs are called into
question because they are thwarted by proxies that say "we know
better."
... Conten provider neeeds to know that the proxy is there and the
proxy needs to know if the content provider says "do not transform."
... I agree that trying to define gradations of transformation won't
wash.
... what we should focus on now is not percisely whether CT proxies
transform but we can say what the vocabulary is and how the proxies
should behave given use of these vocabularies.
... We should provide a vocabulary between content providers and
transformation engines which they can use if they choose to.
+1 to jo
<andrews> +1 too
Francois: I think we're going in a good direction. I'm asking you
guys - would that be realistic, to descrive our CT proxy as the
intermediary and stick to that? We will have to worry about
implementation at some point [in the document lifecycle]. Can we
take the resolution that the CT proxy is an intermediary and its
only aim is to help content not designed for mobile browsing be
converted for mobile devices...
Bryan: I am fine with the scope.
Francois: I am worried that our scope is too small and therefore
won't be respected.
<andrews> +q
Heiko: We shouldn't tell vendors how to do the transformation (from
a user experience POV) but outline the bounderies - such as
no-transform and vary headers.
Jo: I don't think we've set out to say how to do this - I agree with
Heiko.
... If we want to be more pedantic, we can say : "what the
transformation proxy vendor perceives as enhanced user experience."
... In response to Francois, if we produce something and it is
ignored then it's a shame. The alternative, however, is to do
nothing and that is not acceptable. The best we can do is try and
encourage people to see the sense of what we're trying to do.
<andrews> +1 to Jo
Bryan: I don't think we are going to produce something that will be
ignored.
... The question of whether this becomes subsumed into a proxy layer
- we don't have to concern ourselves with that.
... Where there is an important interaction between the
requirements, it's useful to call it out. In this case, we can talk
about the improvement of the user experience. How can we use
existing technology to make the CT proxy aware of what it should do.
Sean: There do seem to be cases where operators want to adapt
non-mobile pages even if a mobile page exists...
Francois: I wanted to make sure that when the content provider says
"no transform" that this should be accepted and implemented in
practice. We give the content providers some power.
<Zakim> jo, you wanted to say that we don't advise CPs how to break
stuff into small pages so we are probably not in a position to
advise that to CT providers and to add that the CT
Jo: In answer to Bryan: I think it's a laudable goal to say how to
break things up but I don't think we can do it.
... I would prefer if we stay clear of that right now.
... I think at least for now we should [just leave the process of
content transformation up to the vendors].
<SeanP> +1 to Jo's point about breaking up pages
Jo: I believe that if a cotnent provider has followed best practice
to provide a mobile experience and taken into account what we say
about users choosing what experience they want then a content
transforming proxy should not subvert that. The main purpose of
these guidelines should be to help in building a mobile "aware" web.
Bryan: I didn't mean we should detail how a CT proxy should break up
pages - what I meant is that there are aspects of that we can say -
like "if you're going to transform a page into smaller pages then
you should give the user the choice of seeing the original."
Jo: I'm hearing we have substantial agreement : we stop worrying
about what we can't do in HTTP even if we think they're desirable
and start talking about what we can do something about in HTTP plus
some service aspects that may be desirable in a transforming. We can
also talk about how user agents are presented.
<francois> PROPOSED RESOLUTION: CT-proxy is an intermediary,
transforming the content with a view to making it more suitable for
mobile presentation.
<jo> +1
<andrews> +1
<SeanP> +1
<rob> +1
+1
<francois> RESOLUTION: CT-proxy is an intermediary, transforming the
content with a view to making it more suitable for mobile
presentation.
<Bryan> +1
<francois> PROPOSED RESOLUTION: grounded on existing technologies,
let's not try to tweak HTTP to meet our specific needs, even though
we would like to do it.
<Bryan> +1
<Zakim> jo, you wanted to mention extensions to UA for example
Jo: I wouldn't want to rule out doing what some CT proxies do at the
moment by adding something onto the UA header.
Francois: I think there will be an exception to the rule wrt user
agents string manipulation.
... Apart from that, I don't think we should create new headers or
use cache control extensions.
Sean: I want to understand what the definition of "tweak" is.
... Other question - would not tweaking mean not including extension
headers?
Francois: I think extensions to headers is "tweaking" but for other
headers there needs to be an "exception."
<jo> PROPOSED RESOLUTION: recommendation will be grounded on
existing technologies with as few exceptions as possible
Sean: I think we should include that exception in the resolution.
<Zakim> andrews, you wanted to check use of custom headers e.g.
x-...
Andrew: in the last conf call we discussed the use of custom headers
(x-). I see there is a use for them - they are used exensively in
our WAP environment today and we've used them in the transformation
engine. Does that still fit within your constraint.
Francois: Yes, that is the exception I'm talking about. But we
should have only one - combining all the information into one and
only one header. If we can stick to that it would be good. My POV.
Bryan: The usefulness of the recommendations will be limited if we
can't define recommendations around the user experience (rather than
just solving the problem of non-transparency).
Francois: if we want to address the user experience, we would have
to say that the CT proxy is more on the user side and it "knows
better" than the content provider.
Bryan: If we're just trying to say that the proxy should get out of
the way in certain circumstances then the document's going to be
very short but possibly this will be OK.
Francois: the resolution we just took means they won't be much in
the guidelines.
<Zakim> jo, you wanted to say that X- headers can only be proposed
on the basis that they are on some kind of rfc trac process
Jo: We should only propose use of an X- header if we can also say we
are proposing it through the rfc process.
... [worried about use of the word "tweak"]
<Zakim> DKA, you wanted to suggest the document could still make
recommendations of UE.
<jo> PROPOSED RESOLUTION: recommendation will be grounded on
existing technologies with as few exceptions as possible but
specifically not cache-control extensions
<andrews> +1 for proposal
<francois> +1
DKA: Suggest UE issues could be recommendations (non normative)
... Suggesting that x- headers should be used if rfc is proposed
through BPWG
Jo: Would need to be through UWA group.
<andrews> the latter
Bryan: [on scope] is the scope purely on non-transparency or is it
to improve operation of transforming proxies?
... the likelyhood that you'll get both content providers and
servers to cooperate on the http header level is slim but with using
existing headers becomes more reasonable.
... if we want to set lamp-posts down the road and recommend that to
the industry but by the time we get there it may be beside the point
because UAs will be more full featured.
<jo> PROPOSED RESOLUTION: recommendation will be grounded (with as
few exeptions as possible) on existing technologies, and will
specifically not employ cache-control extensions
Bryan: as I understood the scope the resolution is we should fix the
problem but not build new services around ct proxy behaviors.
Francois: yes.
+1
<andrews> +1
<francois> +1
<SeanP> +1
<rob> +1
<Bryan> 1+
<jo> RESOLUTION: recommendation will be grounded (with as few
exeptions as possible) on existing technologies, and will
specifically not employ cache-control extensions
Francois: I've been having nightmares about these guidelines.
<hgerlach> sorry for that guys here are 2 other telcos running
Francois: The right direction is to do something simple. Content
adaptation is bigger than http options and is already being
addressed by other groups.
... I think we're now going in the same direction. I propose that we
now take a look at the draft as homework and that given the approach
we try to propose some new wording. Mostly we need to remove things
fromt he existing draft.
Jo: I will produce a new draft with editorial comments reflecting
decision points that need to be made but stripping some interactions
out.
<jo> ACTION: Jo to redraft CT Guidleines based on conversation on
this call [recorded in
[8]http://www.w3.org/2008/02/19-bpwg-minutes.html#action01]
<trackbot-ng> Created ACTION-661 - Redraft CT Guidleines based on
conversation on this call [on Jo Rabin - due 2008-02-26].
Jo: I will try to get that out in a couple of days.
Francois: we could review it in BP call next week [28th]
... [let's quit while we're ahead]
<hgerlach> thanks, bye!
Summary of Action Items
[NEW] ACTION: Jo to redraft CT Guidleines based on conversation on
this call [recorded in
[9]http://www.w3.org/2008/02/19-bpwg-minutes.html#action01]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [10]scribe.perl version 1.133
([11]CVS log)
$Date: 2008/02/19 16:39:25 $
[10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[11] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 19 February 2008 16:45:13 UTC