[minutes] CT Teleconference Tuesday 25 March 2008

Hi,

Minutes of today's call are available at:
http://www.w3.org/2008/03/25-bpwg-minutes.html
... and copied as text below.


Thanks for scribing, Sean.
François.


25 Mar 2008

    [2]Agenda

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

    See also: [3]IRC log

       [3] http://www.w3.org/2008/03/25-bpwg-irc

Attendees

    Present
           MartinJ, SeanP, francois, jo, rob

    Regrets
           kemp, Magnus, Bryan, andrews

    Chair
           francois

    Scribe
           SeanP

Contents

      * [4]Topics
          1. [5]ACTION-682: Write a proposal on the HEAD request
             handling (§3.1.2)
          2. [6]ACTION-683: Inference on URIs (§3.1.2)
          3. [7]ACTION-684: Bad practice to strip comments in VIA header
             (§3.1.4)
          4. [8]ACTION-685: how to embed original headers (§3.1.4)
          5. [9]ACTION-706: Reword §2.5.1
          6. [10]ACTION-707: Include examples in §2.5.1 bullet 3
          7. [11]ACTION-708: Update 2.5.2
          8. [12]ACTION-709: Write some examples for 2.5.3
          9. [13]ACTION-718: re Ajax/XHR requests and CT
      * [14]Summary of Action Items
      _________________________________________________________



    <trackbot-ng> Date: 25 March 2008

    Zakim aadd is me

    <francois> Scribe: SeanP

    <francois> ScribeNick: SeanP

    Francois: Today we should go through our actions.

ACTION-682: Write a proposal on the HEAD request handling (§3.1.2)

    Francois: Based on Martin's text

    <francois> [15]Martin's proposal

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

    Francois: I simplified one of the sentences.

    <francois> "Clients can issue HTTP HEAD requests in order to
    determine if a

    <francois> resource is of a type and/or size that they are capable
    of handling. A

    <francois> proxy may convert a HEAD request into a GET request if it
    requires the

    <francois> response body to determine the characteristics of the
    transformed

    <francois> response that it would return if the client issues a GET
    request. Where

    <francois> this occurs, the proxy should (subject to HTTP cache
    directives) cache

    <francois> the response that it receives so that if the client
    immediately follows

    <francois> the HEAD request with a GET request for the same URI, the
    proxy is not

    Francois: Any problems with the proposed text?

    <francois> required to send a second GET request to the server."

    <francois> PROPOSED RESOLUTION: use above text to resolve ACTION-682

    <jo> subject to HTTP cache directives => providing in accordance
    with normal HTTP caching rules

    <francois> PROPOSED RESOLUTION: leave above text to resolve
    ACTION-682 in the hands of the editor

    <jo> +1

    <MartinJ> +1

    <rob> +1

    <francois> RESOLUTION: leave above text to resolve ACTION-682 in the
    hands of the editor

    <francois> Close ACTION-682

    <trackbot-ng> ACTION-682 Write a proposal on the HEAD request
    handling. closed

ACTION-683: Inference on URIs (§3.1.2)

    <francois> [16]rob's contribution

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

    Francois: Rob, you suggested we no change anything

    Rob: I think the statement that is already there is all we can say.

    Francois: I think that is fine. We'll leave it up to CT proxy
    vendors.
    ... Jo are you OK with that?

    Jo: This is another "remaining silent" thing.
    ... It is worth mentioning that the server could give you some
    clues.
    ... If we are going to go with POWDER we should mention it in this
    section

    Francois: Unsure about what we should say about POWDER.

    Jo: Should say that these resources do this, those do that, etc.
    ... I think we have time. We've have time to find out how we should
    do the POWDER

    Francois: Not sure how to put it in the document given that POWDER
    does not exist.

    Jo: I think we are pretty close to resolving everything we want to
    put in the document except for the POWDER stuff.
    ... I think it is time to go to a FPWD and leave as editorial notes
    about the richer vocabulary.

    <francois> PROPOSED RESOLUTION: for ACTION-683, no change in bullet
    3 of 3.1.2

    <francois> PROPOSED RESOLUTION: for ACTION-683, no change in bullet
    3 of 3.1.2 save POWDER editorial's note

    <rob> +1

    <MartinJ> +1

    <jo> +1

    <francois> RESOLUTION: for ACTION-683, no change in bullet 3 of
    3.1.2 save POWDER editorial's

    <francois> Close ACTION-683

    <trackbot-ng> ACTION-683 Raise an issue on inferencing from the
    structure of the URI what assumptions to make about another from the
    point of view of the CT Proxy closed

ACTION-684: Bad practice to strip comments in VIA header (§3.1.4)

    Francois: Jo, you mentioned in 3.1.4 that this reverses HTTP
    ... HTTP says the proxy may strip comments.

    Jo: It is probably worth finding out why HTTP says this.
    ... It seems kind of odd that HTTP says this.

    Francois: Good point. I'll ask an HTTP expert.

    Jo: Should say that if you are complying with transformation
    guidelines, you should not strip the comment.

    <francois> ACTION: daoust to check why HTTP RFC states comments MAY
    be removed from a VIA header. [recorded in
    [17]http://www.w3.org/2008/03/25-bpwg-minutes.html#action01]

    <trackbot-ng> Created ACTION-722 - Check why HTTP RFC states
    comments MAY be removed from a VIA header. [on François Daoust - due
    2008-04-01].

    Francois: Jo, do you think you will come up with a note.

    Jo: The answer about having the editorial note is yes.

    <jo> PROPOSED RESOLUTION: Yes we should add a note, pending FD's
    ACTION-722

    <jo> PROPOSED RESOLUTION: Yes we should add a note on it being bad
    practice to strip comments from Via HEader (ACTION-684), pending
    FD's ACTION-722

    +1

    <MartinJ> +1

    <jo> PROPOSED RESOLUTION: Yes we should add a note on it being bad
    practice to strip comments from Via Header (ACTION-684) and that
    this is not consistent with HTTP, pending FD's ACTION-722

    <francois> +1

    <jo> RESOLUTION: Yes we should add a note on it being bad practice
    to strip comments from Via Header (ACTION-684) and that this is not
    consistent with HTTP, pending FD's ACTION-722

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

    Francois: I sent an email on Friday about this.

    <inserted> I do not see any possibility to embed original headers in
    the generic case without requiring changes on the content providers
    side

    Francois: Maybe we could address this next week since everyone was
    on vacation at the end of the week.
    ... HTTP doesn't say anything about bodies in GET requests.

    Jo: I think it does.
    ... We could do some tests with real web servers.
    ... We can test whether if we put an extra thing in a request,
    existing servers fail.

    Francois: We may have to make a test.

    Jo: Agreed.

ACTION-706: Reword §2.5.1

    Jo: We'll need to read your email about this and have a discussion
    next week.

    Francois: We had a discussion about control by the user.

    <francois> [18]2.5.1

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

    Francois: Jo, you added an editorial note. Do we need to resolve on
    this?

    Jo: The text of 2.5.1 as it stands was proposed by Bryan.
    ... I'm wonding if what is in 2.5.1 is strong enough.

    Rob: My comment is that some of the CT servers are on particular web
    sites. They wouldn't bother to set up a session.
    ... It is probably best to leave it is "MAY".

    Francois: I may agree.
    ... We agree that static settings are out of scope.
    ... What we are really talking about is session settings.
    ... We'll leave it as a MAY?

    <francois> PROPOSED RESOLUTION: stick to "may" in 2.5.1, and change
    "persistent" to something less strong

    Jo: I think we need to think about what a "session" is.
    ... not sure what we mean by session right now.
    ... I think 2.5.1 needs to be taken on the list.

    <francois> ACTION: daoust to raise discussion on session settings vs
    persistent settings for 2.5.1 and 2.5.3 [recorded in
    [19]http://www.w3.org/2008/03/25-bpwg-minutes.html#action02]

    <trackbot-ng> Created ACTION-723 - Raise discussion on session
    settings vs persistent settings for 2.5.1 and 2.5.3 [on François
    Daoust - due 2008-04-01].

ACTION-707: Include examples in §2.5.1 bullet 3

    Francois: Examples look fine to me.

    <francois> Close ACTION-707

    <trackbot-ng> ACTION-707 Include examples in 2.5.1 bullet 3 per the
    dicussion above closed

ACTION-708: Update 2.5.2

    <jo> ACTION-708?

    <trackbot-ng> ACTION-708 -- Jo Rabin to update 2.5.2 in accordance
    with discussion and Seoul resolution on preferences -- due
    2008-03-18 -- OPEN

    <trackbot-ng>
    [20]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/708

      [20] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/708

    Francois: Not sure I remember what this action was about.
    ... Was to rewrite section 2.5.2 given what happened a the Seoul F2F
    ... It was about if the user preferences contradict the server
    preferences.
    ... We do have a resolution on this.

    Jo: Discussed this in the context of that this is the way CSS works.
    ... we need a better way to say this.

    <jo> ACTION: Jo to raise discussion on list as to clarification of
    2.5.2 "In cases where user preferences contradict server
    preferences, server preferences prevail, except where the user
    specifically requires their preferences to over-rule those of the
    server." [recorded in
    [21]http://www.w3.org/2008/03/25-bpwg-minutes.html#action03]

    <trackbot-ng> Created ACTION-724 - Raise discussion on list as to
    clarification of 2.5.2 \"In cases where user preferences contradict
    server preferences, server preferences prevail, except where the
    user specifically requires their preferences to over-rule those of
    the server.\" [on Jo Rabin - due 2008-04-01].

    <francois> Close ACTION-708

    <trackbot-ng> ACTION-708 Update 2.5.2 in accordance with discussion
    and Seoul resolution on preferences closed

ACTION-709: Write some examples for 2.5.3

    <francois> [22]fd's proposal

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

    <francois> "The preferences of users and of servers MAY be
    ascertained by means

    <francois> outside the scope of this document. These means include
    but are not

    <francois> limited to:

    <francois> - the use by transforming proxies of a disallow-list of
    Web sites for

    <francois> which content transformation is known to be useless
    and/or to break

    <francois> delivered content.

    <francois> - the use by the transforming proxies of an allow-list of
    Web sites for

    <francois> which content transformation is known to be necessary.

    <francois> - user static preferences, e.g. provisioned by their CT
    service provider

    <francois> or directly by the user through self-care web sites.

    <francois> - terms and conditions of service, as agreed upon between
    the user and

    <francois> the CT service provider."

    Francois: This is where I had a chat with Bryan about static and
    persistent settings as opposed to session settings.
    ... The third point needs to be re-examined in light of the earlier
    discussion on this call.

    <francois> PROPOSED RESOLUTION: remove user static preferences in
    above text for the time being, and use the resulting text for 2.5.3
    under ACTION-709

    Jo: These look pretty complete.

    <jo> +1

    <francois> RESOLUTION: remove user static preferences in above text
    for the time being, and use the resulting text for 2.5.3 under
    ACTION-709

ACTION-718: re Ajax/XHR requests and CT

    <francois> [23]fd's thoughts on this

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

    Francois: I raised this problem.
    ... I tried to rephrase the discussion about this problem.
    ... the XHR request will use the same headers as a normal request,
    so there is no way to tell if it is XHR request.
    ... for simple calls in a web page; it it transformed the page, the
    CT proxy should know how to handle the request.
    ... the problem is for untransformed pages, it doesn't know that an
    XHR request should not be transformed as well.
    ... Martin said that requests and responses should only be
    transformed when the CT proxy knows that they originated from a
    transformed request.
    ... Bryan said that as a best practice, XHR request should change
    the UA.
    ... Good idea, will be hard to ask all developers to do this.
    ... Could recommend that developers add no-transform to XHR request.

    Jo: no-transform is consistent with other things we have said in the
    document.

    Francois: We've already said that elsewhere in the document.

    Jo: We said we weren't going to discuss clients and users and we are
    drifting back to that.
    ... In this case it may we worth saying something.

    Francois: I don't see how we can make it work.
    ... How can the proxy determine that calls originate from a page if
    it did not transform the page.
    ... Suppose you have a web page that contains too much JavaScript to
    transform. In the page there are some XHR calls.
    ... The CT proxy must be consistent.. It must not transform these
    XHR calls. There is no real way to detect that it is an XHR call.
    ... It will work in the future. We need to worry about legacy stuff.

    Jo: Is this much of an issue. What are the chances that what comes
    back is in the form that needs to be transformed?

    Francois: We may be creating an issue out of nothing.
    ... Let me come up with some smarter text on that.
    ... I'll come up with something along the lines of a warning about
    XHR.

    Jo: I don't see anywhere in this document about what content types
    the CT proxy will intervene in.
    ... We should put something in about that.

    Francois: We mention content types in the list of heuristics for
    determining whether a page is mobile.

    Jo: It would be interesting to learn what is left alone.

    <francois> ACTION: SeanP to send a list of content-types for which
    content transformation applies [recorded in
    [24]http://www.w3.org/2008/03/25-bpwg-minutes.html#action04]

    <trackbot-ng> Sorry, couldn't find user - SeanP

    <francois> ACTION: Patterson to send a list of content-types for
    which content transformation applies [recorded in
    [25]http://www.w3.org/2008/03/25-bpwg-minutes.html#action05]

    <trackbot-ng> Created ACTION-725 - Send a list of content-types for
    which content transformation applies [on Sean Patterson - due
    2008-04-01].

    <jo> action- 4

Summary of Action Items

    [NEW] ACTION: daoust to check why HTTP RFC states comments MAY be
    removed from a VIA header. [recorded in
    [26]http://www.w3.org/2008/03/25-bpwg-minutes.html#action01]
    [NEW] ACTION: daoust to raise discussion on session settings vs
    persistent settings for 2.5.1 and 2.5.3 [recorded in
    [27]http://www.w3.org/2008/03/25-bpwg-minutes.html#action02]
    [NEW] ACTION: Jo to raise discussion on list as to clarification of
    2.5.2 "In cases where user preferences contradict server
    preferences, server preferences prevail, except where the user
    specifically requires their preferences to over-rule those of the
    server." [recorded in
    [28]http://www.w3.org/2008/03/25-bpwg-minutes.html#action03]
    [NEW] ACTION: Patterson to send a list of content-types for which
    content transformation applies [recorded in
    [29]http://www.w3.org/2008/03/25-bpwg-minutes.html#action05]

    [End of minutes]

Received on Tuesday, 25 March 2008 16:40:26 UTC