- From: Francois Daoust <fd@w3.org>
- Date: Tue, 08 Jul 2008 17:32:04 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
The minutes of today's call are available at:
http://www.w3.org/2008/07/08-bpwg-minutes.html
... and copied as text below.
No resolutions taken. No actions created. A good ol' discussion on the
remaining issue.
Re. Allow/Disallow lists, all the arguments and possible choices are on
the table, I guess. Let's wait for the updated draft to take a final
decision.
Re. Persistent expression of user preference, well, same thing.
Both are linked in the sense that "persistent" is at the heart of the
problem. We may end up not really needing to mention these points in
particular if we keep guidelines that are "self-healing".
Francois.
08 Jul 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0003.html
See also: [3]IRC log
[3] http://www.w3.org/2008/07/08-bpwg-irc
Attendees
Present
hgerlach, rob, jo, Francois, SeanP
Regrets
Pontus, AndrewS, Bryan
Chair
francois
Scribe
jo
Contents
* [4]Topics
1. [5]Allow and Disallow Lists
2. [6]Persistent Expression of User Preferences
* [7]Summary of Action Items
_________________________________________________________
Allow and Disallow Lists
francois: I summarized the choices as I see them in the agenda, and
I was wondering if this is a good picture
... we should wait for the new draft before deciding unless we can
come up with a clear consensus now
... we have three choices (as discussed in the agenda)
... my personal preference would be for b), but are there any other
points of view to take into account?
<francois> jo: I think we can step around this one actually, either
with "unspecified means", either by saying "prior interaction with
the server"
<francois> ... and then we can then leave that open
<francois> ... The important thing is IMO that the so-called
algorithm is self-healing, and if we keep it this way, we don't
really need to go in the like/don't like allow/disallow lists
discussion
jo: I think we can avoid referring to specific internal mechansims
by referring tot he notion of p"previous experience" and "a priori"
knowledege, providing that the algorithm makes it plain that no
matter what the proxy thinks it knows, but whatever means it thinks
it knows it, it must act on the evidence that is presented by the
server first and foremost
... we can gain consensus hopefully by focussing on mitigating the
undesirable effects without prohibiting the use of them
heiko: two issues here ...
... role of allow and disallow list is one question, the other
question is setting up an allow list for setting up a different user
agent string
... the first issue is allow or disallow transformation the second
is allow or disallow bogus user agent headers
francois: but not mentioning them surely avoids the issue
heiko: if you are allowed to bypass this is a different issue to
no-transform
... we need to think about what we are allowing or disallowing
francois: allow lists to discuss the possibility of sending altered
headers
... and the second to allow overriding cache control, two different
uses of the list
seanp: one issue with b) is that it deals only with the response
whereas one would need to look at such lists on the request
... there may be a disconnect as to what people are using such lists
for now
... so if we mention at all we should make this clear
francois: actually I think b) only deals with the HTTP request to
know if you have to send another one
<hgerlach> sorry I got a 2nd call will be back soon
seanp: if you have allow list you can send altered headers straight
away
... you are saying that is the prior knowledge
francois: the point jo emphasised it that it makes sense to send
altered headers straight way but it needs refreshing from time to
time
... it really depends
... ithink we should postpone the decision till we see the new
document
<Zakim> jo, you wanted to say that as a point of principle one
should avoid mentioning internal mechanisms that are proprietary to
the proxy
<francois> jo: Allow/Disallow are not really externally visible, so
we should not step into the behavior of the Proxy, and not mention
them. You can infer that there are such lists. we deal with the
interactions between the server and the proxy
francois: suggest we leave it and move on
Persistent Expression of User Preferences
<francois> [8]Jo's points commented by Sean and me
[8]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0002.html
<Zakim> jo, you wanted to say that the algorithm referred to above
should help with this too
<francois> jo: Thinks that it is linked to the algorithm. If we're
clever, I guess we'll say that the proxy should prompt the user
again when the response from the server differs from the previous
one.
<francois> ... a bit woolly but we cannot do any better, I think.
jo: I think that the key point is that when a user has a persistent
expression of preference we want to make sure that if a host changes
its operation the user gets the chance to re-express their
preferences
... and this requires the proxy maintain some kind of "prior
knowledge"
francois: seanp can you clarify something from your email ... the
origin server can tell that the request has passed through the CT
proxy, if it changes its operation it can tell the CT proxy this by
sending a 406 status with a vary header
seanp: basically the origin server can tell ... by looking at the
X-Headers
... so it can determine that the server now does not want the CT
proxy to do transformation any more
... so the CT proxy will know to not do transformation for that site
any more
... I thought tha was why we had the point under 4.3 in here
francois: {mumbles}
seanp: origin server can tell that it is going through a proxy so
what we need is for the origin server to show that is is now aware
... couple of cases one where is was aware and changes its mind, and
the other is that it wasn't aware and now doesn't want
transformation
francois: there we are using the response from the server as a
direct communication with the proxy rather than having end-to-end
significance
... the problem is that the 406 is not intended for the end-users
seanp: but surely that's what we do when it works the other way
round
francois: but in that case it really is saying "I can't handle your
device"
... in your illustration its the server telling the proxy to change
its ways
seanp: sure but the practical results are the same
jo: not sure that what Seanp proposed doesn't require the server to
know about tasting and prior requests, hope we can sweep this all
together in a new draft
... I have put a placeholder for illustrations of interactions
... so we can make sure we have tested this all out
francois: anything else we need to sweep up
... trciky part is about cps that offer users a choice of
representation
... and how to tell proxy that they are handling the choice
themselves
... don't know if there are any technical possibilities, not sure we
can decorate this any further
... anyone got a view on that?
jo: think that this is a problem and am hoping to find an answer!
<hgerlach> +1
francois: clarifying that it's best practice for the server to offer
such a choice
heiko: server can offer a menu offering choices
... but this will require an additional database
... e.g. how to determine that there is a .mobi page for something
that is not in the .mobi domain
francois: can advertise via the linkelement
heiko: how can can the proxy know that the pages exist
... how do they know where the mobile page is
francois: there are two things, the server can already tell the
proxy that such pages exist using the link element, but the
difficulty is telling the proxy that they also offer that choice in
a user visible way
... there are a number of problems, e.g. that this may offer this at
a site level, could be POWDER, but that is scope for future work
heiko: no there can be a database for that purpose even if the site
owner has not set this information?
francois: what kind of database?
heiko: well there is the .mobi database
francois: the ct proxy could consult such a database?
heiko: yes
francois: there is no fixed relationship between domain names
seanp: there is lots of way to map between mobile sites and desktop
sites and mobile sites and vice versa
... so this seems like a CT vendor issue
... if the page doesn't contain the issue then its a CT vendor issue
<Zakim> jo, you wanted to say that databases are out of scope
seanp: there are a million different ways of doing this, no algoritm
as such
<francois> jo: out of scope, since we're talking about using HTTP.
We should not refer specifically to any specific implementation
mechanisms
jo: we shouldn't refer specifically to particular implementation
mechanisms
francois: final issue ... CT proxies providing links to alternative
representations ... I did include a Proposed Resolution, in the
agenda but let's leave that one too
... for the time being
jo: hope to have new draft by tomorrow or by thursday
<hgerlach> -1 bye
Summary of Action Items
[End of minutes]
Received on Tuesday, 8 July 2008 15:32:38 UTC