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

[minutes] CT call Tuesday 29 April 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 29 Apr 2008 17:55:05 +0200
Message-ID: <481744D9.8090206@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

Hi guys,

The minutes of today's call are available at:
http://www.w3.org/2008/04/29-bpwg-minutes.html

... and copied as text below.

Thanks,
François.


29 Apr 2008

    [2]Agenda

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

    See also: [3]IRC log

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

Attendees

    Present
           Heiko, Jo, Francois, MartinJ, SeanP, Rob

    Regrets
           Magnus, AndrewS, Bryan

    Chair
           francois

    Scribe
           Jo

Contents

      * [4]Topics
          1. [5]Ajax, XHR and Content Transformation
          2. [6]format of via header comment
          3. [7]Discussion on Session vs Persistent sessions (yada yada)
          4. [8]Sending two requests requests 4.1.2
      * [9]Summary of Action Items
      _________________________________________________________

Ajax, XHR and Content Transformation

    <francois> [10]discussion re Ajax/XHR calls

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

    fd: conclusion is that a proxy should examine the content of the
    page it receives and have a lot of scripts

    <francois> PROPOSED RESOLUTION 1.1: in §4.4, add a bullet point to
    the list of heuristics that says "examination of the content reveals
    that the page contains client-side scripts that may break if the
    page gets adapted"

    <francois> +1

    jo: wonders if adding the heuristic adds value, though it is
    obviously true, it doesn't say how to formulate a conclusion

    fd: that's also true of the other heuristics we enumerate in the
    same section

    <Zakim> rob, you wanted to say that if a page contains script then
    usually it does need transforming!

    jo: I am thinking that we should not be doing product design and we
    need to have a greater degree of feedback from real vendors

    rob: usually we do the scripting on behalf of the phone but where
    the phone is script capable we do let it through

    heiko: there was an open ajax workshop, were there any results

    fd: I don' think there was anything related to CT

    seanp: there are a couple of possibilities - e.g. a proxy runs the
    scripts or passes them through, there may also be some
    transformation
    ... e.g. if link rewriting is done and some of the links in the
    Javascript might need to be rewritten, it might be smart enough to
    rewrite those too

    <Zakim> jo, you wanted to suggest we resolve to put it in as it does
    no harm

    seanP: that was just by way of clarification not a proposed text

    jo: let's just put it in

    fd: I think what actually happens is out of scope

    rob: mention is fine

    <SeanP> +1 for mentioning as a heuristic

    rob: the bit that said if there is script don't transform would be
    wrong

    +1

    <rob> +1

    RESOLUTION: in §4.4, add a bullet point to the list of heuristics
    that says "examination of the content reveals that the page contains
    client-side scripts that may mis-operate if the page gets adapted"

    [note that the word "break" has been transformed]

    <francois> PROPOSED RESOLUTION 2.3: in §???, "Asynchronous HTTP
    requests sent from within a Web page (e.g. XHR calls) SHOULD include
    a no-transform directive"

    fd: another resolution related to that is to do with adding a
    no-transform directive to requests, not sure where to put it
    ... initially I wanted to say something about content types etc.
    ... but Jo convinced me that this was not right

    <francois> PROPOSED RESOLUTION 2.3: in 4.1.1, "Asynchronous HTTP
    requests sent from within a Web page (e.g. XHR calls) SHOULD include
    a no-transform directive" as a typical example

    jo: lets stick it in 4.1.1 as an example of when you might do that

    <Zakim> jo, you wanted to say that MAY is better

    rob: we mean a mobile friendly Web page

    <SeanP> +1 for MAY

    <hgerlach> +1

    jo: I think this would be text along the lines of ... MAY ... if it
    does not wish the request or the response to be altered by a CT
    proxy

    fd: <tap /> <tap />

    <francois> PROPOSED RESOLUTION 2.3: in 4.1.1, "As an example of
    this, a web page sending asynchronous HTTP requests (e.g. XHR calls)
    may include a no-transform directive if it doesn't want the message
    to be transformed"

    +1

    <rob> +1

    <francois> +1

    <hgerlach> +1

    <SeanP> +1

    RESOLUTION: In 4.1.1, "As an example of this, a web page sending
    asynchronous HTTP requests (e.g. XHR calls) may include a
    no-transform directive if it doesn't want the message to be
    transformed"

    fd: let's not discuss the content types for transformation
    (ACTION-725) we can do that later
    ... I also had another one one which no longer makes sense so let's
    drop it
    ... as things stand there is no way for the server or a proxy to
    know whether the request comes from the browser or from XHR and it
    might be worth pointing out to them as a LCC the need to distinguish
    XHR calls (Jo already mentioned this to Chaals)
    ... I am not sure the distinction needs to be made ...
    ... should we do this?

    PROPOSED RESOLUTION: FD to draft a note to the WG and alert them to
    this discussion

    rob: I'm not sure there is anything to say about it
    ... not sure there is any need to distinguish
    ... as long as there is something that identifies that this is part
    of the session and all responses come with their own content types
    which is what is important to us

    jo: don't see why not, it's not a big deal, they can ignore it if
    they want

    <francois> 0

    <scribe> ACTION: daoust to write to the XHR folks and point out a
    possible need to identify that a requst comes from script [recorded
    in [11]http://www.w3.org/2008/04/29-bpwg-minutes.html#action01]

    <trackbot-ng> Created ACTION-749 - Write to the XHR folks and point
    out a possible need to identify that a requst comes from script [on
    François Daoust - due 2008-05-06].

    <hgerlach> +1 proposed -1others

    <SeanP> +1 to writing to XHR folks

    close ACTION-718

    <trackbot-ng> ACTION-718 Summarize and continue discussion re
    Ajax/XHR requests and CT closed

    close ACTION-739

    <trackbot-ng> ACTION-739 Summarize (again) discussion on Ajax/XHR
    and propose some resolutions closed

    heiko: what about the content type part of ACTION-739

    fd: we will discuss this under ACTION-725 on Sean

format of via header comment

    <francois> [12]fd's proposal

      [12] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0040.html

    fd: we wanted to distinguish CT proxy from proxy - when were
    discussing this in the context of POWDER we said it would point to a
    resource describing what it would do
    ... bryan pointed out in Seoul that just a flag would be useful
    ... this could link to a powder resource when we get to that

    <francois> PROPOSED RESOLUTION: format of the VIA header comments:
    [a URI to a POWDER resource that describes the CT-proxy's
    capabilities using the vocabulary-to-be when we're ready to switch
    to POWDER or] the CT

    <francois> namespace's URI "[13]http://www.w3.org/2008/04/ct#".
    Intention to transform must be indicated using the "active"
    property: "[14]http://www.w3.org/2008/04/ct#active".

      [13] http://www.w3.org/2008/04/ct
      [14] http://www.w3.org/2008/04/ct#active

    fd: or a namespace id which just means "I am a transformation proxy"

    <Zakim> jo, you wanted to ask how to distinguish old style comments
    from new style comments when this is not a namespace any more

    jo: worried about forward compatibility and how you will know to
    distinguish a flag from a link to some powder resource

    fd: it will be different URI

    jo: I guess we should say so

    fd: yes, <tap /> <tap />

    jo: maybe we should have a query string so we could have name /
    value pairs - just using a fragment ID may not be vvery
    extensible/flexible

    fd: perhaps we need more investigation if we don't know whether this
    is good practice or not

    <francois> PROPOSED RESOLUTION: format of the VIA header comments:
    either the URI "[15]http://www.w3.org/2008/04/ct", a URI derived
    from this one (that defines properties such as "active"), or a URI
    to a POWDER resource that describes the capabilities of the proxy

      [15] http://www.w3.org/2008/04/ct

    +1

    <francois> +1

    <SeanP> +1

    fd: I will investigate how to be able to define multiple properties
    in the same URI

    <scribe> ACTION: daoust to investigate how to add multiple
    property/values to the URI [recorded in
    [16]http://www.w3.org/2008/04/29-bpwg-minutes.html#action02]

    <trackbot-ng> Created ACTION-750 - Investigate how to add multiple
    property/values to the URI [on François Daoust - due 2008-05-06].

    RESOLUTION: format of the VIA header comments: either the URI
    "[17]http://www.w3.org/2008/04/ct", a URI derived from this one
    (that defines properties such as "active"), or a URI to a POWDER
    resource that describes the capabilities of the proxy

      [17] http://www.w3.org/2008/04/ct

    close ACTION-741

    <trackbot-ng> ACTION-741 Write a concrete proposal on use of via
    header closed

    close ACTION-742

    <trackbot-ng> ACTION-742 Write some concrete proposal on the format
    of the HTTP Via comment to advertise the CT-proxy's presence (and
    possibly intention to transform) closed

Discussion on Session vs Persistent sessions (yada yada)

    <francois> [18]fd's proposal

      [18] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0036.html

    fd: this all started as a discussion of what is in or out of scope
    ... and went into a discussion of "other arrangements"
    ... I don't understand what the distinction is between session
    settings and persistent settings so my proposal is to rewrite 3.2.1

    <francois> PROPOSED RESOLUTION: Rewrite §3.2.1 roughly based on what
    it was before: "They MAY also provide the ability for their users to
    make a persistent expression of preferences."

    fd: "persistent or semi-persistent expression of preferences"
    ... to what it was before, I don't think we need to make a
    distinction

    <SeanP> I'm fine with that.

    <francois> +1

    <hgerlach> +1

    <SeanP> +1

    <rob> +1

    0

    RESOLUTION: Rewrite §3.2.1 roughly based on what it was before:
    "They MAY also provide the ability for their users to make a
    persistent expression of preferences."

    jo: notes that we are avoiding having a discussion on something that
    might reveal important things but for now, let's do it your way fd

Sending two requests requests 4.1.2

    fd: in theory GET is idempotent so it should not matter
    ... if you send more than one request. In practice I listed a number
    of cases where this is not true

    <francois> [19]discussion

      [19] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0043.html

    fd: for POSTs this is of course a problem, so I don't think we need
    to emphasize this point

    <francois> PROPOSED RESOLUTION 1.1: at the end of §4.1.2, add "The
    proxy MUST NOT issue a POST/PUT request with altered headers when
    the response to the

    <francois> unaltered POST/PUT request contains an HTTP status code
    200"

    <francois> (in other words, it may only send the altered request for
    a POST/PUT request when the unaltered one was refused with a clear
    406)

    fd: in most cases the proxy will already know how to interact with
    the server by the time it gets to sending a POST

    heiko: what about one time URLs?

    fd: yeah, we are just talking about POSTs for now
    ... but yes we should make the point that the proxy should strive
    always to send only one GET request

    +1

    <hgerlach> +1

    <MartinJ> +1

    <francois> 0

    <rob> +1

    RESOLUTION: at the end of §4.1.2, add "The proxy MUST NOT issue a
    POST/PUT request with altered headers when the response to the
    unaltered POST/PUT request contains an HTTP status code 200" (in
    other words, it may only send the altered request for a POST/PUT
    request when the unaltered one was refused with a clear 406)

    <francois> PROPOSED RESOLUTION 1.2.a: at the end of §4.1.2, add a
    "The theoretical idempotency of GET requests is unfortunately not
    always respected in practice. Not to break existing content, the
    proxy SHOULD strive to send only one request whenever possible."

    fd: let's see if we can resolve on the next one, which speaks to
    Heiko's last point

    PROPOSED RESOLUTION 1.2.a: at the end of §4.1.2, add a "The
    theoretical idempotency of GET requests is unfortunately not always
    respected in practice. Not to break existing content, the proxy
    SHOULD send only one request."

    +1

    <francois> +1

    RESOLUTION: at the end of §4.1.2, add a "The theoretical idempotency
    of GET requests is unfortunately not always respected in practice.
    Not to break existing content, the proxy SHOULD send only one
    request."

    <scribe> ACTION: daoust to make sure that we are clear about
    idempotency and side-effect freedome etc. per Dom's original
    illuminating point about this section [recorded in
    [20]http://www.w3.org/2008/04/29-bpwg-minutes.html#action03]

    <trackbot-ng> Created ACTION-751 - Make sure that we are clear about
    idempotency and side-effect freedome etc. per Dom's original
    illuminating point about this section [on François Daoust - due
    2008-05-06].

    fd: next time we will discuss Sean's contribution and we also need
    to do the remainder of the points on the agenda so please study
    these points

Summary of Action Items

    [NEW] ACTION: daoust to investigate how to add multiple
    property/values to the URI [recorded in
    [21]http://www.w3.org/2008/04/29-bpwg-minutes.html#action02]
    [NEW] ACTION: daoust to make sure that we are clear about
    idempotency and side-effect freedome etc. per Dom's original
    illuminating point about this section [recorded in
    [22]http://www.w3.org/2008/04/29-bpwg-minutes.html#action03]
    [NEW] ACTION: daoust to write to the XHR folks and point out a
    possible need to identify that a requst comes from script [recorded
    in [23]http://www.w3.org/2008/04/29-bpwg-minutes.html#action01]

    [End of minutes]
Received on Tuesday, 29 April 2008 15:55:49 GMT

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