W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > July 2008

[minutes] CT Call Tuesday 8 July 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 08 Jul 2008 17:32:04 +0200
Message-ID: <48738874.4000704@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:29 UTC