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

[minutes] CT Teleconference Tuesday 1 April 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 01 Apr 2008 17:36:19 +0200
Message-ID: <47F25673.7090008@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

The minutes for today's call are available at:
http://www.w3.org/2008/04/01-bpwg-minutes.html
... and copied as text below.

Next steps:
1. an editors meeting between Jo and fd tomorrow
2. remaining resolutions on Thursday's BPWG call
3. leaving a week for reviewing
4. publication as FPWD
Is that being too optimistic? Well, probably ;)

As a summary, things we resolved during today's call:
- for 3.1.4, "the proxy must add a X-Device-[original HTTP header name]" 
and put an editorial note about the fact we'd love to recommend 
something else but don't see how and a note about the choice of "device"
- 3.4 list of heuristics - leave it as it is for the time being
- accept Martin's text for ACTION-717
- with the users explicit prior consent, when dangerous content is 
detected, and when using a browser, instead of forwarding the dangerous 
content MAY warn the user and send a page with links to both transformed 
and non-tranformed versions dangerous that may cause mal-operation of 
the users device
- let's try: editors' meeting tomorrow, resolutions on Thursday's call, 
reviewing and then publication

François.


01 Apr 2008

    [2]Agenda

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

    See also: [3]IRC log

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

Attendees

    Present
           Magnus, SeanP, andrews, francois, hgerlach, jo, rob

    Regrets
           Bryan, kemp, MartinJ

    Chair
           francois

    Scribe
           rob, jo

Contents

      * [4]Topics
          1. [5]Targeted schedule
          2. [6]ACTION-685: how to embed original headers (§3.1.4)
          3. [7]Proxy response to User Agent (§3.4)
          4. [8]Proxy Receipt and Forwarding of Response from Server
             (§3.3)
          5. [9]Publication as FPWD
      * [10]Summary of Action Items
      _________________________________________________________

Targeted schedule

    <jo> Agenda:
    [11]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0038.
    html

      [11] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0038.html

    francois: apart from a few issues probably settled today we're ready
    to publish a "First Working Draft"
    ... aim to resolve during today's call the outstanding issues and
    arrange an Editor's Meeting

ACTION-685: how to embed original headers (§3.1.4)

    francois: could publish First Working Draft in the week after next

    <francois> [12]3.1.4

      [12] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#d0e528

    <francois> [13]fd's action

      [13] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0030.html

    francois: couldn't find a way to echo original header values without
    breaking things

    <jo> +1 to sending X-headers and to adding an editorial note stating
    we'd prefer not to use this mechanisnm but can't think of any other
    way

    <Zakim> rob, you wanted to say we already have precedent for
    X-headers in live systems

    <Zakim> jo, you wanted to suggest that the app at the server would
    probably not have access to Warning headers ...

    rob: X-headers are deployed live by Novarra and Openwave and their
    presence is known to the developer community

    jo: It is a pity we couldn't find a better solution but suggest we
    accept it as undesirable but still worth recommending

    andrews: supports the X-headers for echoing changed headers

    <Zakim> jo, you wanted to say we should stop wringing our hands
    about this

    francois: so this means multiple X-headers if multiple headers have
    been changed?

    jo: you can't have new HTTP headers without an experimental period,
    so recommend proceed with X-headers

    hgerlach: need to understand what headers can change and what
    headers should never change

    francois: in practice it's only User-Agent and Accept

    <francois> PROPOSED RESOLUTION: for 3.1.4, "the proxy must add a
    X-Original-[original HTTP header name]" and put an editorial note
    about the fact we'd love to recommend something else but don't see
    how.

    <jo> +1

    <jo> scribe: jo

    <Magnus> +1

    PROPOSED RESOLUTION: for 3.1.4, "the proxy must add a
    X-Original-[original HTTP header name]" and put an editorial note
    about the fact we'd love to recommend something else but don't see
    how.

    andrew: should it be X-Device like Novarra has it?

    seanP: Either way seems reasonable to me

    rob: maybe developers will expect X-Device as it is already in use

    jo: i'd prefer something like X-received

    francois: we have a number to choose from
    ... I don't like device but don't really care
    ... would prefer original or received?

    <francois> x-device?

    <SeanP> +1

    [straw poll]

    rob and andrew also prefer x-device (fallen off IRC)

    andrew: take jo's point x-received might be truer

    <francois> PROPOSED RESOLUTION: for 3.1.4, "the proxy must add a
    X-Device-[original HTTP header name]" and put an editorial note
    about the fact we'd love to recommend something else but don't see
    how and a note about the choice of "device".

    francois: can you live with that Jo

    jo: really doesn't matter just lets add a ntoe saying it is a
    provisional choice

    <SeanP> +1

    <rob> +1

    <andrews> +1

    hgerlach: we asked that we did not define our own headers so we
    should make sure that these headers are unique like containing CT or
    some other label
    ... so they are not used by other applications for different
    purposes

    francois: take your point but they use could be more generally
    applicable

    jo: suggest taht we take resolution and move on as headers shouldn't
    be bounded by a presumed application

    fd: well these ones are already in use so why don't we just do this

    hg: we have lots of X- headers in the vodafone network
    ... not a major issue to change headers think the headers need only
    to be used for the single purpose

    seanp: didn't come across any collisions with the X-Device headers
    ... to the point about which other headers might be changed:
    Accept-Charset and Accept-Encoding for example

    <francois> RESOLUTION: for 3.1.4, "the proxy must add a
    X-Device-[original HTTP header name]" and put an editorial note
    about the fact we'd love to recommend something else but don't see
    how and a note about the choice of "device"

    fd: right let's make a note about the name and take the resolution

Proxy response to User Agent (§3.4)

    <francois> [14]3.4

      [14] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#sec-Proxy-Response

    fd: suggest we leave this list alone for now and come back to it in
    a later step

    <francois> PROPOSED RESOLUTION: 3.4 list of heuristics - leave it as
    it is for the time being

    +1

    <rob> +1

    <hgerlach> +1

    <SeanP> +1

    <andrews> +1

    <francois> RESOLUTION: 3.4 list of heuristics - leave it as it is
    for the time being

    <francois> [15]Martin's text for ACTION-717

      [15] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0033.html

    fd: Martin sent some text under ACTION-717

    <andrews> +1

    fd: clarifying that it is not allowed to break the end to end
    security

    <francois> PROPOSED RESOLUTION: accept Martin's text for ACTION-717

    <andrews> +1

    +1

    <SeanP> +1

    <francois> RESOLUTION: accept Martin's text for ACTION-717

    <francois> Close ACTION-717

    <trackbot-ng> ACTION-717 Propose some alternate text for HTTPs
    rewrite and "must provide the option to avoid transformation" closed

    <scribe> scribe: rob

    <francois> ScribeNick: rob

    francois: remaining topic on dangerous content is a bit outdated

    <francois> PROPOSED RESOLUTION: for dangerous content, something
    along the lines of:

    <francois> "[when dangerous] the proxy MAY warn the user, and give
    the user the choice to see a transformed version of the resource"?

    francois: suggest if there is a Cache-Control: no-transform but
    CT-proxy determines content won't work on the handset that the
    CT-proxy should ask the user?

    <jo> ... instead of forwarding the dangerous content MAY send a page
    with links to both transformed and non-tranformed versions ...

    hgerlach: what is dangerous content?

    francois: eg a page that is too big and will cause out-of-memory in
    the phone browser

    <jo> [ref HGerlach's comments, virus scanning is surely not in
    scope?]

    hgerlach: does a virus-scanner do this?

    francois: I think it's out of scope unless there is a clear
    incompatibility

    <Zakim> rob, you wanted to say sending a "do you or don't you?"
    interstitial is definitely *not* a no-transform

    rob: sending a "do you or don't you?" interstitial is definitely
    *not* a no-transform and this could break an application if the
    content is saved to memory

    <jo> +1 to "no transform" means "no-transform"

    francois: yes, the CT-proxy needs to be cautious about this

    seanp: if it is dangerous content then something must be done to fix
    it, obviously the CT-proxy needs to be cautious about altering it

    <francois> PROPOSED RESOLUTION: for dangerous content, something
    along the lines of:

    <francois> "[when dangerous] the proxy MAY warn the user, and give
    the user the choice to see a transformed version of the resource",
    with emphasis on the MAY to say that it may be "dangerous"

    <Zakim> jo, you wanted to say if one could tell what was dangerous
    content then I'd agree with SeanP, the problems seems to be that one
    can't tell well enough in general

    jo: should be absolutely only if the user wants the CT-proxy to
    correct dnagerous content
    ... and as usual the users' preferences can be persistent
    ... even the interstitial wil break an application if there is no
    user to see the page
    ... so the user's decision needs to be "prior consent"

    <jo> "with the users explicit prior consent [when dangerous] instead
    of forwarding the dangerous content MAY warn the user and send a
    page with links to both transformed and non-tranformed versions"

    <jo> PROPOSED RESOLUTION: with the users explicit prior consent,
    when dangerous content is detected, and when using a browser,
    instead of forwarding the dangerous content MAY warn the user and
    send a page with links to both transformed and non-tranformed
    versions

    hgerlach: should we use the word "dangerous"?

    <SeanP> I'm OK with the term "dangerous"

    <francois> +1

    francois: the term is defined clearly

    <andrews> +1

    <hgerlach> +1

    <SeanP> +1

    <Magnus> +1

    <jo> +1

    <francois> RESOLUTION: with the users explicit prior consent, when
    dangerous content is detected, and when using a browser, instead of
    forwarding the dangerous content MAY warn the user and send a page
    with links to both transformed and non-tranformed versions dangerous
    that may cause mal-operation of the users device

Proxy Receipt and Forwarding of Response from Server (§3.3)

    francois: 3.1.4 says if the headers are altered the CT-proxy must be
    prepared to vary the headers

    jo: this isn't clear
    ... if you don't get a Vary in the response you don't know to
    reissue the request differently
    ... the point of sending a Vary is to avoid caching in situations
    where it is inappropriate to cache

Publication as FPWD

    <francois> PROPOSED RESOLUTION: editors' meeting tomorrow,
    resolutions on Thursday's call, reviewing and then publication

    <francois> RESOLUTION: let's try: editors' meeting tomorrow,
    resolutions on Thursday's call, reviewing and then publication

    <hgerlach> bye:-)

Summary of Action Items

    [End of minutes]
Received on Tuesday, 1 April 2008 15:36:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 1 April 2008 15:36:50 GMT