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

[minutes] CT call Tuesday 22 April 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 22 Apr 2008 17:18:00 +0200
Message-ID: <480E01A8.8010404@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

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

... and copied as text below.

I'll summarize and propose some resolutions based on the discussions we 
had during the call so that we can decide and move on next week!

François.



22 Apr 2008

    [2]Agenda

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

    See also: [3]IRC log

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

Attendees

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

    Regrets
           kemp, bryan, rob

    Chair
           francois

    Scribe
           jo

Contents

      * [4]Topics
          1. [5]Comments on FPWD
          2. [6]Linearization/zoom/format support and CT
          3. [7]Discussion on Linearization and Zoom and All That Jazz
          4. [8]Ajax Calls and CT Proxies
          5. [9]Comments and Via Headers
          6. [10]The format of the Via Header
      * [11]Summary of Action Items
      _________________________________________________________

Comments on FPWD

    <francois> [12]comment received

      [12] 
http://lists.w3.org/Archives/Public/public-bpwg-comments/2008AprJun/0000.html

    fd: actually we only received one comment which is pretty good going

    <hgerlach> I just sent the document to our Vodafone OpCos. By when
    do you need their comments?

    fd: raises an interesting point but I am not sure how to take them
    into account
    ... basically it is about how a transforming proxy can make a valid
    page invalid
    ... not sure how we can put this in
    ... we could say that it should always generate a valid page?

    magnus: the comment is that the proxy added javascript and thus made
    the page invalid
    ... think it is pretty obvious that the proxy shouldn't make pages
    invalid
    ... proxy builders should show adequate humbleness, it's easy to get
    this wrong

    ack (ne

    <Magnus> s/humily/humbleness/

    fd: it's an obvious statement but how should we phrase it, who
    thinks we should not mention it?
    ... does anyone think it is too obvious?

    jo: think its non-obvious and is definitely an omission from present
    draft
    ... and that we should add something about generating valid markup
    (and images too, for that matter)
    ... happy to take an action to propose some text in next draft

    fd: probably should go in 4.4 ,,,,

    <scribe> ACTION: jo to create text about transforming proxies
    generating valid documents and propose it in next draft [recorded in
    [13]http://www.w3.org/2008/04/22-bpwg-minutes.html#action01]

    <trackbot-ng> Created ACTION-738 - Create text about transforming
    proxies generating valid documents and propose it in next draft [on
    Jo Rabin - due 2008-04-29].

Linearization/zoom/format support and CT

Discussion on Linearization and Zoom and All That Jazz

    fd: in 4.1.2 there is some text ... [quotes] ... there was some
    discussion on the mailing list

    <francois> [14]thread on the topic

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

    fd: first this applies to the response
    ... so we should remove it from where it is
    ... and move it to 4.4 Proxy response to user agent
    ... jo and sean have different perspectives on this

    jo: there needs to be something under 4.1.2 reference not changing
    headers

    fd: but we already say that headers should not be changed
    ... unless the response would be rejected
    ... so it doesn't add anything
    ... you suggest that we add this as an additional point?

    jo: I think it should go under "knowledge it has of user agent
    capabilities" as you suggest under Possiblity 1 c)

    fd: OK, yes as an example of UA capabilities

    seanp: even on advanced browsers you may want to do some kind of
    transformation
    ... depends on network, memory and so on, so you might want to do
    some segmentation

    fd: still worth mentioning under 4.1.2 but maybe change the wording
    under 4.4

    seanp: the way I would phrase it is that the capabilities of the
    browser should be taken into account but shouldn't be a restriction

    fd: perhaps it is just another example of the type of heuristic that
    the proxy should apply

    jo: perhaps it could go there but I am worried that we end up being
    too wishy washy. what we are trying to avoid is having the server
    doinf adaptation, and transforming proxies transforming and ditto
    the browsers - this turns into a real mess. And we should say that
    this is to be avoided etc.

    sean: yes, I agree but the case I was referring to was when the
    Server doesn't adapt then it may be worth the proxy doing things

    <francois> PROPOSED RESOLUTION: to replace paragraph on "adavanced
    browsers" and CT, add it as an example to "any knowledge it has of
    user agent capabilities" in 4.1.2 and add it as a bullet point in
    the list of heuristics in 4.4

    <SeanP> +1

    <francois> +1

    <andrews> +1

    <hgerlach> -1

    <Martin1> +1

    +1 to francois's auto-+1

    heiko: don't agree because of the arbitrary choices of my local
    marketing department

    <hgerlach> +1

    <Zakim> jo, you wanted to disagree strongly with heiko

    fd: if we add this to the list of heuristics then it is not as
    strong so matters less

    jo: I think that whether your equipment is conformant to these
    guidelines or not is their choice, we can't make arbitrary choices
    in the sections based on the bits they may or may not choose to
    ignore

    RESOLUTION: to replace paragraph on "advanced browsers" and CT, add
    it as an example to "any knowledge it has of user agent
    capabilities" in 4.1.2 and add it as a bullet point in the list of
    heuristics in 4.4

Ajax Calls and CT Proxies

    <francois> [15]discussion on Ajax/XHR calls

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

    fd: basically if you have an XHR in a page then there is no way for
    the CT proxy to know that this is an AJAX call
    ... rather than just a page request
    ... we did discuss this
    ... it's just about choosing the right response content type -
    text/xml or text/plain
    ... I wonder if we should write about it or forget about it
    ... there isn't really a problem in practice
    ... we could add this to a list of heuristics

    <hgerlach> +1

    fd: saying that if you see scripts then be prepared for this

    heiko: the application has to add no-cache so adding no-transform
    should not be a problem

    <Zakim> jo, you wanted to suggest that we put an example in the
    appendix

    jo: think that we should discuss this and say the no-transform
    should be added in both the request and the response

    fd: do you mean the request or just the response
    ... not sure there is need to add it in the request

    jo: think this is the classic use case for no-transform in the
    request

    heiko: normally the Ajax client and data are owned by the same
    operator so they can add this easily
    ... either way round

    seanp: martin said at the f2f if the page that contained the ajax
    request was transformed then you might want to transform the
    response

    heiko: transformed ajax pages won't work, in my expectation

    seanp: the point was that if the proxy knows enough to transform the
    page with the request then it will know enough to transform the
    request

    fd: if it knows enough then it is going to be smart enough to remove
    the no-transform it receives

    <hgerlach> sorry, I have to leave for the doc.- bye Heiko

    martin: I agree that if you transform an Ajax page then it's
    unlikely to work, but there could be some minor optimizations that
    are worth doing and should not be prohibited

    fd: wondering aloud, um, er,
    ... if it is smart enough it could remove the no-transform from the
    request so ...
    ... <scribe not following FD's drift here>

    heiko: got to go , just want to say there should be no-transform on
    the response to the AJAX request

    fd: agree that it should be present in both

    jo: I find it worrying that you suggest that a transforming proxy
    MAY transform requests with no-transform on them

    fd: hmmm, difficult to write it
    ... some where in the doc we should add the text saying that XHR
    requests should have no-transform on (and consequently according to
    the rules it will alos be on the response)

    jo: suggest that we put this in as one among other examples of how
    the whole thing is intended to be used
    ... in a non-normative appendix, for example

    seanp: I was thinking along the lines of the ??? itself hasn't been
    and there is no no-transform on the request or the response

    scribe is confused?

    seanp: if it is no-transform ab initio, then it shouldn't be
    transformed, but just because it is Ajax doesn't mean it should not
    be transformed

    <francois> ACTION: daoust to summarize (again) discussion on
    Ajax/XHR and propose some resolutions [recorded in
    [16]http://www.w3.org/2008/04/22-bpwg-minutes.html#action02]

    <trackbot-ng> Created ACTION-739 - Summarize (again) discussion on
    Ajax/XHR and propose some resolutions [on François Daoust - due
    2008-04-29].

Comments and Via Headers

    fd: we are in 4.1.3
    ... there is a statement that comments in Via headers may be removed
    ... it seems that this was motivated my memory constraints and they
    don't exist in practice
    ... doesn't mean that comments are always kept just means they are
    kept most of the time
    ... don't think we should change anything

    <SeanP> On the XHR issue, my comment was that if a page was
    transformed, then any XHR requests originating from that page may
    need to have their responses transformed, so these requests should
    probably not be marked no-transform.

    <francois> According to the HTTP RFC (§14.45), Via headers comments
    "MAY be

    <francois> removed by any recipient prior to forwarding the
    message". Noting that

    <francois> the justification for removing such comments is
    memory-based, that most

    <francois> modern proxies are able to handle that amount of
    information and that

    <francois> comments are useful for CT, the BPWG recommends that Via
    headers

    <francois> comments SHOULD NOT be removed.

    fd: and move the ednote to a note and point out that there is a
    slight difference to HTTP RFC 2616
    ... per the text I just pasted
    ... any objection or anything to add?

    <scribe> ACTION: Jo to find a way of crafting FD's text above and
    weaving it skillfully into the flow of the text [recorded in
    [17]http://www.w3.org/2008/04/22-bpwg-minutes.html#action03]

    <trackbot-ng> Created ACTION-740 - Find a way of crafting FD's text
    above and weaving it skillfully into the flow of the text [on Jo
    Rabin - due 2008-04-29].

    <francois> Close ACTION-722

    <trackbot-ng> ACTION-722 Check why HTTP RFC states comments MAY be
    removed from a VIA header. closed

    fd: close the action

    <francois> Close ACTION-684

    <trackbot-ng> ACTION-684 Include a note that we think it is bad
    practice to strip the comment from downstream via header fields
    closed

    fd: and also there was one on jo too, so we can close that as it's
    all included in the new action

The format of the Via Header

    fd: i'd prefer if we finished the guidelines without powder and
    sprinkle it on later
    ... wondering what we can use in the meantime
    ... could it be a namespace stating "I'm a CT Proxy?"

    <francois> [18]http://www.w3.org/2008/04/ct/

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

    jo: what will a server do knowing that it is a CT proxy but not
    knowing anything about its facilities

    fd: we could have one or two values
    ... including statement of intent to transform
    ... think it would be directly usable
    ... later then the usage could be expanded, we could use it as a
    flag and this would actually already add value

    <andrews> +q

    jo: so what is a server actually going to do differently

    fd: it could refuse to serve the page
    ... it's in the requirements, we wanted the server to know that
    there is a ct proxy

    [OK I think there is no downside to this and suggest we do as FD
    suggests]

    andrew: it's not just the server that would find this useful, it
    could be useful for diagnostics

    fd: could be used for debugging

    andrew: great strength of http is that it is human readable
    ... v useful to have this information in there.
    ... moot point as to when you consider yourself to be a
    transformation proxy

    fd: there is also the proxy intention to transform that we want to
    communicate to the server
    ... and I don't see any other way of doing this

    <scribe> ACTION: daoust to write a concrete proposal on use of via
    header [recorded in
    [19]http://www.w3.org/2008/04/22-bpwg-minutes.html#action04]

    <trackbot-ng> Created ACTION-741 - Write a concrete proposal on use
    of via header [on François Daoust - due 2008-04-29].

    <francois> ACTION: daoust to write some concrete proposal on the
    format of the HTTP Via comment to advertise the CT-proxy's presence
    (and possibly intention to transform) [recorded in
    [20]http://www.w3.org/2008/04/22-bpwg-minutes.html#action05]

    <trackbot-ng> Created 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) [on François Daoust -
    due 2008-04-29].

    fd: look at the other to do's at the end of the agenda
    ... we have to get this done and I will try to stimulate discussion
    on these topics

    [meeting ends]

Summary of Action Items

    [NEW] ACTION: daoust to summarize (again) discussion on Ajax/XHR and
    propose some resolutions [recorded in
    [21]http://www.w3.org/2008/04/22-bpwg-minutes.html#action02]
    [NEW] ACTION: daoust to write a concrete proposal on use of via
    header [recorded in
    [22]http://www.w3.org/2008/04/22-bpwg-minutes.html#action04]
    [NEW] ACTION: daoust to write some concrete proposal on the format
    of the HTTP Via comment to advertise the CT-proxy's presence (and
    possibly intention to transform) [recorded in
    [23]http://www.w3.org/2008/04/22-bpwg-minutes.html#action05]
    [NEW] ACTION: jo to create text about transforming proxies
    generating valid documents and propose it in next draft [recorded in
    [24]http://www.w3.org/2008/04/22-bpwg-minutes.html#action01]
    [NEW] ACTION: Jo to find a way of crafting FD's text above and
    weaving it skillfully into the flow of the text [recorded in
    [25]http://www.w3.org/2008/04/22-bpwg-minutes.html#action03]

    [End of minutes]
Received on Tuesday, 22 April 2008 15:18:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 April 2008 15:18:37 GMT