See also: IRC log
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
<francois> Jo's points commented by Sean and me
<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