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

[minutes] CT Call Tuesday 1 July 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 01 Jul 2008 17:54:51 +0200
Message-ID: <486A534B.4040204@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/01-bpwg-minutes.html

... and copied as text below.


Resolutions taken during the call on remaining issue:
- goal is to integrate as much of current section 3.2 as is practical to 
current section 4, where ever they apply, for clarification purpose.
- Move first bullet list in section 3.2.1 "Transformation proxies SHOULD 
provide to their users" to section 4.4.
- drop section 3.2.2, since it's already explicitly explained in section 4

I'll send an update later this week of the discussion we had.
Feel free to continue the discussion on the mailing-list as well!

Francois.


01 Jul 2008

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0000.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/07/01-bpwg-irc

Attendees

    Present
           Francois, Bryan_Sullivan, andrews, hgerlach, SeanP

    Regrets
           Jo

    Chair
           francois

    Scribe
           andrews

Contents

      * [4]Topics
          1. [5]Re-chartering process
          2. [6]Issue 242
      * [7]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 01 July 2008

    <hgerlach> Hey isn't it Vodafone?????

    scribe andrews

Re-chartering process

    francois: Switch from informative to normative status of guidelines

    <francois> [8]rechartering questionnaire

       [8] http://www.w3.org/2002/09/wbs/33280/MWBP-CT-rechartering/

    francois: Please remind AC reps of questionnaire. Ends 28 July.

Issue 242

    francois: Remaining issue. Views sent last Friday

    <francois> [9]fd's email

       [9] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0042.html

    <francois> [10]Sean's reply

      [10] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0044.html

    francois: Overview of issue 242: About section 3.2. About control of
    proxy behaviour.
    ... Document is not clear whether there are controls for this part
    of guidelines.
    ... Need to move section 3.2 into section 4.
    ... Jo says we should not put policies into guidelines.
    ... Jo has pointed out that guidelines suggest that content servers
    should allow user selection of mobile or desktop versions but CT
    proxy would not know this choice is available.
    ... We should not try to reslove now but wait fo the updated draft.
    ... I propose that we remove section 3.2 and state controls in
    section 4.

    <francois> PROPOSED RESOLUTION: goal is to integrate bits of current
    section 3.2 explicitly into current section 4, where ever they
    apply, for clarification purpose.

    +1

    Bryan: Previously made some proposals. [clarifying proposal]

    francois: Risk is that guidelines could be too loose and anyone
    could claim compliance.
    ... Don't want to be too normative, too strict.

    Bryan: People have different perspectives. Practice sometimes
    demands secondary mechanisms.

    francois: We need to leave room for impementations to allow vendors
    room to deploy practically.

    Bryan: CT is one component in proxy layer. In practice roles cannot
    be easily separated.

    francois: Difficult to move all 3.2 into section 4.
    ... may result in a more obscure document.

    But we should move as much as we can and be explicit when we can.

    Bryan: We should use "should" whenever possible rather than "shall".

    francois: In fact there are not many "must"s in the document so we
    don't force behaviour too much.

    <francois> PROPOSED RESOLUTION: goal is to integrate as much of
    current section 3.2 as is practical to current section 4, where ever
    they apply, for clarification purpose.

    +1

    <Bryan> +1

    <SeanP> +1

    <francois> +1

    RESOLUTION: goal is to integrate as much of current section 3.2 as
    is practical to current section 4, where ever they apply, for
    clarification purpose.

    <francois> PROPOSED RESOLUTION: Move first bullet list in section
    3.2.1 "Transformation proxies SHOULD provide to their users" to
    section 4.4.

    <SeanP> +1

    <francois> +1

    RESOLUTION: Move first bullet list in section 3.2.1 "Transformation
    proxies SHOULD provide to their users" to section 4.4.

    <francois> PROPOSED RESOLUTION: drop section 3.2.2, since it's
    already explicitly explained in section 4

    +1

    <SeanP> +1

    <francois> +1

    RESOLUTION: drop section 3.2.2, since it's already explicitly
    explained in section 4

    francois: Now for the tricky part...
    ... Drop terms and conditions of service. These are out of scope of
    the document.

    Sean: We should leave mention in document. Part of specifying user's
    choices is a practical matter.

    francois: Allow list. This could be put into section 4 as an
    algortihm

    hgerlach: Recommend an allow list for different user agent
    ... maybe the problem is the name "allow list". Maybe it should be
    called a "taylor list".

    francois: Don't think the name is too important. Allow list is to
    enable sites to register on such a list but content providers would
    have to register on many lists and this would not be practical.
    ... We should allow an "allow list" but indicate that the list is
    refreshed from time to time so that the list evolves. This would
    allow evolving sites to be accommodated.

    Bryan: Current wording is OK. Danger in softening wording and making
    it too general.
    ... Some content providers may not have the ability or means to put
    correct semantics into site so a list is a practical approach.
    ... 1st part of section is clear. Last sentence is probably too
    strict.

    francois: If both parties agree how to handle content the guidelines
    do not need to be applied. This was agreed in the face-to-face
    meeting.
    ... In generic case, where there is no dialogue between CT provider
    and content provider, it would be difficult to have to apply to join
    lists for each operator.
    ... Better to have use of lists in scope and state when they apply.

    SeanP: Agree with Bryan - language is a little too strong. Just need
    to state that in general lists can be impractical.

    hgerlach: Different lists... bypass list is used today, likely to be
    small in future. But need an allow list to allow different
    user-agents for specific pages or URL or site.

    Bryan: If we move the statements into the normative part of the
    document, it makes sense.
    ... Global allow list with specific exceptions should enable easy
    deployment.

    hgerlach: No issue in updating bypass list, not sure that they will
    be changed regularly.

    Bryan: 3.2.3 statements OK but not clear how these can be included
    in section 4

    francois: There are problems for content providers when they do not
    know that they are on a list.
    ... Move lists to section 4?

    Bryan: Does 3.2.3 add anything?

    <francois> Request resource with original headers

    <francois> - If the response is a 406 response, re-request with
    altered headers (unless the 406 response contains no-transform).

    <francois> - If the response is a 200 response,

    <francois> -- if the response contains vary: User-Agent, an
    appropriate link element or header, or no-transform, forward it

    <francois> -- otherwise assess (by unspecified means) whether the
    200 response is a bogus one

    <francois> --- if it is not, forward it

    <francois> --- if it is, re-request with altered headers

    francois: Intention is to rewrite so that there is room for
    interpretation. In this case an allow list could be used.
    ... Give content transformation vendors freedom to implement

    Bryan: Would change reference to bogus 200 response - this is not
    clear.

    francois: Will summarise discussion in mailing list.

Summary of Action Items

    [End of minutes]
Received on Tuesday, 1 July 2008 15:55:25 UTC

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