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

[minutes] BPWG F2F day 1 - 2008-10-20

From: Francois Daoust <fd@w3.org>
Date: Wed, 22 Oct 2008 12:32:07 +0200
Message-ID: <48FF0127.6060202@w3.org>
To: MWI BPWG Public <public-bpwg@w3.org>

Hi guys,

The minutes of day 1 of our F2F are available at:
  http://www.w3.org/2008/10/20-bpwg-minutes.html

The agenda changed a bit. We decided to go through the list of Last Call 
comments received on Content Transformation, and spent the day on that.

Francois.


20 Oct 2008

    [2]Agenda

       [2] 
http://www.w3.org/2005/MWI/BPWG/Group/Meetings/Mandelieu/agenda.html

    See also: [3]IRC log - [4]Day 2 minutes

       [3] http://www.w3.org/2008/10/20-bpwg-irc
       [4] http://www.w3.org/2008/10/21-bpwg-minutes

Attendees

    Present
           Kai, Jeff, Francois, DKA, Dom, Jo, SeanP, Rob, Adam, Nacho,
           Abel, Jonathan, Seungyun, RigoWenning

    Observers
           Shadi_Abou-Zahra (W3C), Kangchan_Lee (ETRI), David_Thevenin
           (ExpWay), Ann_Bassetti (Boeing), Kai_Hendry (Aplix),
           Vagner_Diniz (nic.br), Manuel_Serrano (INRIA),
           Stephane_Boyera (W3C)

    Regrets
           Soonho, Bryan

    Chair
           DKA, Jo

    Scribe
           francois, Dom, Adam, Sean, jeffs, Jeff, Jo, Rob

Contents

    The whole day was spent addressing the [5]Last Call comments
    (member-only link) received on the [6]Content Transformation
    Guidelines document.
      * [7]Topics
          1. [8]Content Transformation Guidelines: where we are
          2. [9]LC-2066 - missing RFC 2616 section - 2.1 Types of Proxy
          3. [10]LC-2044 - 4.1.3 Treatment of Requesters that are not
             Web Browsers
          4. [11]LC-2070 - Proxies SHOULD follow standard HTTP
             procedures - 4.1.4 Serving Cached Responses
          5. [12]LC-2069 - 4.1.3 Treatment of Requesters that are not
             Web Browsers
          6. [13]LC-2003 - whitelists - 4.1 Proxy Forwarding of Requests
          7. [14]LC-1996 et al - 4.1.5 Alteration of HTTP Header Values
          8. [15]LC-2074 - profiling HTTP, idempotency of GET requests -
             4.1.5.1 Content Tasting
          9. [16]LC-2037 - POST retry - 4.1.5.2 Avoiding "Request
             Unacceptable" Responses
         10. [17]LC-2075 - Heuristics for 200 rejected responses -
             4.1.5.2 Avoiding "Request Unacceptable" Responses
         11. [18]LC-2076, LC-2039 - same headers for all resources -
             4.1.5.4 Sequence of Requests
         12. [19]LC-2079, LC-2041, LC-2080 - 4.2.1 Use of HTTP 406
             Status - 4.2.2 Server Origination of Cache-Control:
             no-transform
         13. [20]LC-2045 - Respect of RFC2616 - 4.2.2 Server Origination
             of Cache-Control: no-transform
         14. [21]LC-2081 - About not basing actions on knowledge -
             4.2.3.1 Use of Vary HTTP header
         15. [22]LC-2009, LC-2010, LC-2011 - Use of the link element -
             4.2.3.2 Indication of intended presentation media type of
             presentation
         16. [23]LC-2020 - Copyright - 4.3 Proxy forwarding of response
             to user agent
         17. [24]LC-2082, LC-2042 - Cascading proxies - 4.3.2 Receipt of
             Warning: 214 Transformation Applied
         18. [25]LC-2083 - Sniffing rejected responses - 4.3.3 Server
             Rejection of HTTP Request
         19. [26]LC-2084 - purpose of behavior - 4.3.4 Receipt of Vary
             HTTP Header
         20. [27]LC-1998 - No transformation for application/xhtml+xml -
             4.3.6 Proxy Decision to Transform
         21. [28]LC-1999 - No transformation for small pages - 4.3.6
             Proxy Decision to Transform
         22. [29]LC-2048, LC-2002, LC-2052, LC-2021 - Heuristics - 4.3.6
             Proxy Decision to Transform
         23. [30]LC-2022 - i-mode content - 4.3.6 Proxy Decision to
             Transform
         24. [31]LC-2090, LC-2000 - No extra content without the consent
             of the content owner - 4.3.6 Proxy Decision to Transform
         25. [32]LC-2013 - meta http-equiv - 4.3.6 Proxy Decision to
             Transform
         26. [33]LC-2051 - Open Mobile Alliance Standard Transcoding
             Interface work - Appendix A and D
         27. [34]LC-1995 - About "recent" HTTP "drafts" - Appendix D.2
         28. [35]LC-2047 - Cascading proxies - Appendix D.4 Inter Proxy
             Communication
         29. [36]W3C mobileOK Logo and policy
      * [37]Summary of Action Items
      _________________________________________________________

       [5] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/
       [6] http://www.w3.org/TR/2008/WD-ct-guidelines-20080801

    <dom> [38]Registrants for the F2F

      [38] http://www.w3.org/2002/09/wbs/35125/TPAC2008/registrants#mwbp

    DKA: Welcome to lovely Cannes-Mandelieu

Content Transformation Guidelines: where we are

    [39]detailed agenda for the review of last call comments

      [39] http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/0047.html

    Francois: our content transformation guidelines are in last call,
    and received quite a few comments
    ... we're at a stage where we're trying to agree on the resolutions
    to these comments
    ... we already took a couple of important resolutions in the task
    force
    ... first, we'll focus on content transformation proxies
    ... the current document gives guidance both to content providers
    and content transformation proxies vendors
    ... so we've decided to remove the normative statements for content
    providers, and we'll move them as informative only
    ... and keep the focus only on content transformation proxies
    ... the second resolution we've made was to soften the language used
    in HTTPs in the guidelines
    ... trying to make sure we do not endorse the rewriting of HTTPS
    links
    ... still trying to give guidance on how to do it correctly when you
    decide you want to do it

    Jo: We would like something even less acknowldeging as RFC2119-MAY
    ... as a presentational point, we're removing the MAY and will turn
    it into a conditional statement ("If you rewrite HTTPs links...")

    Francois: A certain number of comments we're received were based on
    a misinterpretation of our intent
    ... the rationales behind our normative statements were not always
    explicit, so we may need to add clarifications
    ... We won't discuss HTTPs today
    ... My goal today is to go through as many unresolved last call
    comments as possibly
    ... there are some comments that are re-raising tough issues on
    which we had difficulty finding consensus

    DKA: I think if there are no new elements brought on these issues, I
    think our default should be not to re-open the issue

    Jo: but we need to consider whether the comment introduce new
    information we hadn't seen before

    Francois: my message list comments roughly in the order of the
    document

    [40]Annotated view of the document with the lc comments

      [40] http://tinyurl.com/634lue

LC-2066 - missing RFC 2616 section - 2.1 Types of Proxy

    Francois: starting with LC-2066, missing reference - proposing we
    accept it

    [41]LC comments tracker on content transformation guidelines

      [41] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/

    [42]LC-2066

      [42] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2066

    PROPOSED RESOLUTION: Accept LC-2066 and add the reference

    <DKA> +1

    <francois> +1

    RESOLUTION: Accept LC-2066 and add the reference

    <jo> +1

    <SeanP> +1

    <rob> +1

LC-2044 - 4.1.3 Treatment of Requesters that are not Web Browsers

    Francois: next LC-2044 and 2069
    ... on section 4.1.3
    ... we want to restrict our guidelines to the "web browsing context"
    ... but we don't have a definition for that, and there is no way to
    technically distinguish those
    ... so putting normative statements on this is somewhat meaningless

    DKA: we could alter it to say "if you recognize it's not web
    browsing, you must not..."

    Rob: but how can you positively identify that?

    Francois: no existing proposed recommendation

    Jo: this text has been in for ages, proposed by Bryan
    ... maybe Bryan would have some additional input on that one?
    ... for 2044, I think we can clarify that our intent was to target
    the values of the existing http headers, rather than their existence

    <jo> PROPOSED RESOLUTION: Ref LC-2044 Resolve yes, and change the
    text to say "*values* of User Agent and Accept headers"

    <jo> PROPOSED RESOLUTION: Ref LC-2044 Resolve yes, and change the
    text to say "*values* of User Agent and Accecpt headers", and
    clarify that we do not propose guidance for new user agents' use of
    these headers, it is out of scop-e

    RESOLUTION: Ref LC-2044 Resolve yes, and change the text to say
    "*values* of User Agent and Accecpt headers", and clarify that we do
    not propose guidance for new user agents' use of these headers, it
    is out of scope

    <rob> +1

LC-2070 - Proxies SHOULD follow standard HTTP procedures - 4.1.4
Serving Cached Responses

    <dom> current text: "Proxies must act as though a no-transform
    directive is present (see 4.1.2 no-transform directive in Request)
    unless they are able positively to determine that the user agent is
    a Web browser. The mechanism by which a proxy recognizes the user
    agent as a Web browser should use evidence from the HTTP request, in
    particular the User-Agent and Accept headers."

    <Zakim> rob, you wanted to suggest "...if they identify the client
    is a web browser"

    Francois: LC-2070, mostly editorial issue.

    <jo> PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the
    replacement text: "Proxies should act as though a no-transform
    directive is present (see 4.1.2 no-transform directive in Request)
    if they have determined that the request has not been made for
    direct human presentation."

    francois: [ discussion on appropriate tweaking of first para in
    4.1.4 ]

    <jo> PROPOSED RESOLUTION: Ref LC-2070, change para 1 to say "Aside
    from the usual caching procedures defined in RFC 2616, in some
    circumstances ..."

    <jo> PROPOSED RESOLUTION: Ref LC-2070, resolve yes, and change para
    1 to say "Aside from the usual caching procedures defined in RFC
    2616, in some circumstances ..."

    <rob> +1

    <DKA> +1

    <francois> +1

    <SeanP> +1

    RESOLUTION: Ref LC-2070, resolve yes, and change para 1 to say
    "Aside from the usual caching procedures defined in RFC 2616, in
    some circumstances ..."

LC-2069 - 4.1.3 Treatment of Requesters that are not Web Browsers

    <jo> current text: "Proxies must act as though a no-transform
    directive is present (see 4.1.2 no-transform directive in Request)
    unless they are able positively to determine that the user agent is
    a Web browser. The mechanism by which a proxy recognizes the user
    agent as a Web browser should use evidence from the HTTP request, in
    particular the User-Agent and Accept headers."

    <jo> PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the
    replacement text: "Proxies should act as though a no-transform
    directive is present (see 4.1.2 no-transform directive in Request)
    if they have determined that the request has not been made for
    direct human presentation."

    SeanP: "Direct human presentation" -- is it really clearer?
    ... liked "web browser".

    <jo> PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the
    replacement text: Before altering aspects of an HTTP request a
    transforming proxy should take reasonable steps to determine that
    "*the request is intended for direct human representaion*"

    dka: should we get more specific ?

    <jo> PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the
    replacement text: Before altering aspects of an HTTP request a
    transforming proxy should take reasonable steps to determine that
    "*the request is intended for direct human representaion*" and
    remove the second sentence ref User Agent and accept headers.

    <dom> (this means we'll have to amend our response to LC-2044)

    jo: Hard to be normative on this without writing a product spec.

    dka: Not sure that this statement means much.

    SeanP: Original intent of this recommendation was to not transform
    application data, an XHR request from a (potentially) transcoded
    page is a poor example since it might need subsequent transcoding.

    dka: Should we go back to using the word "web-browser".

    jo: Okay, just define what you mean by the word Web...

    <jo> PROPOSED RESOLUTION: PROPOSED RESOLUTION: ref LC-2069. Resolved
    yes, with the replacement text: Before altering aspects of an HTTP
    request proxies should take account of the fact that HTTP is used as
    a transport mechanism for many other applications than "Traditional
    Browsing" and that alteration of HTTP requests for those
    applications can cause serious misoperation.

    <jo> PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the
    replacement text: Before altering aspects of an HTTP request proxies
    ought to take account of the fact that HTTP is used as a transport
    mechanism for many other applications than "Traditional Browsing"
    and that alteration of HTTP requests for those applications can
    cause serious misoperation.

    <francois> +1

    <dom> +1

    <DKA> +1

    <SeanP> +1

    <rob> +1

    adam: Not convinced that this really adds clarity.

    jo: Lets take this action and move on, on the understanding that
    this needs some wordsmithing.

    <jo> ACTION: Jo to word smith resolution on LC-2069 in line with its
    spirit and come up with something a bit cleaner andmore
    comprehensible [recorded in
    [43]http://www.w3.org/2008/10/20-bpwg-minutes.html#action01]

    <trackbot> Created ACTION-865 - Word smith resolution on LC-2069 in
    line with its spirit and come up with something a bit cleaner
    andmore comprehensible [on Jo Rabin - due 2008-10-27].

    <francois> PROPOSED RESOLUTION: re LC-2044, resolution on LC-2069
    removes the part that required clarification, resolve partial, we
    won't talk about "use of evidence"

    <jo> +1

    <DKA> +1

    <francois> +1

    <SeanP> +1

    RESOLUTION: ref LC-2069. Resolved yes, with the replacement text:
    Before altering aspects of an HTTP request proxies ought to take
    account of the fact that HTTP is used as a transport mechanism for
    many other applications than "Traditional Browsing" and that
    alteration of HTTP requests for those applications can cause serious
    misoperation.

    RESOLUTION: re LC-2044, resolution on LC-2069 removes the part that
    required clarification, resolve partial, we won't talk about "use of
    evidence"

LC-2003 - whitelists - 4.1 Proxy Forwarding of Requests

    francois: Do we want to have this conversation or postpone.

    jo: Couple of points: whitelist / blacklist aren't good words.
    ... Important that we don't make supositions on the internal working
    of transforming proxies...
    ... Make a note that we don't refer to whitelist / blacklist for the
    following reasons, etc.

    <jo> PROPOSED RESOLUTION: Make a note about the reasons for not
    referring to lists, of whatever hue, because the preumption about
    the internal operation of proxies is not in scope, as far as we are
    concenred these are "black boxes"

    <DKA> +1

    <SeanP> +1

    <francois> +1

    <rob> +1

    RESOLUTION: Make a note about the reasons for not referring to
    lists, of whatever hue, because the preumption about the internal
    operation of proxies is not in scope, as far as we are concenred
    these are "black boxes"

    <jo> ACTION: Jo to include text referencing resolution to LC-2003
    [recorded in
    [44]http://www.w3.org/2008/10/20-bpwg-minutes.html#action02]

    <trackbot> Created ACTION-866 - Include text referencing resolution
    to LC-2003 [on Jo Rabin - due 2008-10-27].

    <francois> Above resolution was for LC-2003, for which we resolve
    no.

LC-1996 et al - 4.1.5 Alteration of HTTP Header Values

    francois: Discussing which headers the proxy may reasonably change.
    We have a list of such headers, and have found no need to remove any
    headers (except possibly UAProf). We haven't found significant
    problems with changing the accept-headers since not generally used
    to identify device...
    ... Need to change User-Agent / UAProf because of long-tail of
    legacy Web pages... Should we send original headers in X-Device-*?
    Is there a need? And are we allowed to define new headers in our
    document?

    <Zakim> jo, you wanted to respond to francois's eloquent peroration

    jo: Whilst I almost agree with everything francois has said, two
    issues...
    ... Don't believe we are inventing new headers (X-Device-*) since
    they are already in use, just not written down.
    ... If a content provider was previously returning a 406 to mobile
    user-agents but changes to support them, it needs the original
    device headers so it can tell the proxy to stop transforming.

    francois: Vary header could answer this need.

    <Zakim> jo, you wanted to give another good reasonwhy they should be
    there

    dka: If we don't specify what the header is then we are not
    providing such a good service than if we define it.

    <dom> [at least one reason for having the X-Device-* headers is
    statistics gathering]

    francois: Sure, but all we need is a flag ("There was a
    transformation") that the content provider can respond to and
    request the original request.

    <dom> [jo's making my point; how smart of him]

    jo: If original device user-agent is not available then there will
    be no log data indicating a need for a mobile device.

    rob: Original headers may expedite engineers making quick fixes.

    francois: The statistics argument is pretty convincing.

    <DKA> PROPOSED RESOLUTION: WRT 4.1.5 Don't change anything and say
    "no" to all the LC comments on this point (Francois to determine
    wich).

    <dom> [hmm... but aren't they other headers that *need* to be
    modified?
    [45]http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 ]

      [45] http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3

    francois: Some LC comments say that the current version makes it too
    easy for CT-proxy providers to find an excuse change headers...
    Should we split headers into two groups? Changing accept-headers
    being less serious than UAProf, etc.

    <jo> PROPOSED RESOLUTION: WRT 4.1.5 Text remains substantially as is
    but is reinforced by saying the only acceptable headers to change
    are User Agent and Accept and not to delete headers

    <dom> [ e.g. "From"]

    francois: Fine with this, but don't think it addresses concerns.

    jo: What people are concerned with is that headers be removed that a
    content-provider was relying from... Suggest that whatever the proxy
    does, it should be possible to reconstruct the original request.

    SeanP: But what about the case where an operator / gateway adds a
    header that gets removed?

    <jo> PROPOSED RESOLUTION: WRT 4.1.5 Text remains substantially as is
    but is reinforced by saying the only acceptable headers to change
    are User Agent and Accept and not to delete headers the point being
    that by using X-Device plus headers that are present all headers the
    were sent by the UA and their values can be reconstructed by the
    server

    <francois> [46]LC-2046 on HTTP header deletion

      [46] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2046

    <jo> PROPOSED RESOLUTION: WRT 4.1.5 Text remains substantially as is
    but is reinforced by saying the only acceptable headers to change
    are User Agent and Accept(-*) and not to delete headers the point
    being that by using X-Device plus headers that are present all
    headers the were sent by the UA and their values can be
    reconstructed by the server

    <jo> PROPOSED RESOLUTION: WRT 4.1.5 Text remains substantially as is
    but is reinforced by saying that the CT proxy SHOULD NOT change
    headers and values other than User Agent and Accept(-*), MUST NOT
    delete headers and it MUST be psosible for the server to reconstruct
    the original UA originated headers by using X-Device etc.

    <rob> +1

    <francois> +1

    <SeanP> +1

    <DKA> +1

    +1

    <nacho> concur (+0)

    RESOLUTION: WRT 4.1.5 Text remains substantially as is but is
    reinforced by saying that the CT proxy SHOULD NOT change headers and
    values other than User Agent and Accept(-*), MUST NOT delete headers
    and it MUST be psosible for the server to reconstruct the original
    UA originated headers by using X-Device etc.

LC-2074 - profiling HTTP, idempotency of GET requests - 4.1.5.1 Content
Tasting

    francois: not everyone knows about this. I am fine with the text. It
    is a BP that we advise to do.

    dom: we are saying http is nice but people may not handle it
    correctly.

    francois: We want to downgrade the normative statement to a note

    jo: sometimes you have to issue a get request
    ... then there should be an intermediary page

    dom: it is nice advice to give, but it is something we want CT
    proxies to evaluate?

    jo: some are doing this routinely

    francois: why don't we switch it back to informative only..the whole
    document

    dka: I am going to shoot myself

    francois: it is not the core of the problem at stake

    jo: I think it is important based on the adverse reactions
    ... people are sensitive to this and we should acknowledge this

    francois: any objections to leaving it as is?

    dka: in essence that is what we should do

    <francois> PROPOSED RESOLUTION: re. LC-2074, resolve no, this is a
    best practice we recommend to CT-proxies.

    <francois> PROPOSED RESOLUTION: re. LC-2074, resolve no. Based on
    our experience and feedback from servers whose operators take strong
    exception to this practice, we think it's reasonable to advise
    CT-proxies operators of this situation

    <jo> +1

    <francois> +1

    <SeanP> +1

    <rob> +1

    RESOLUTION: re. LC-2074, resolve no. Based on our experience and
    feedback from servers whose operators take strong exception to this
    practice, we think it's reasonable to advise CT-proxies operators of
    this situation

LC-2037 - POST retry - 4.1.5.2 Avoiding "Request Unacceptable"
Responses

    francois: this is about what is identified as unacceptable responses
    ... a CT proxy cannot differentiate here
    ... i think we should keep the text and explain why we cannot
    specify the heuristics

    <jo> PROPOSED RESOLUTION: ref LC-2037 yes, we have removed PUT
    partly in response to your comment

    <francois> +1

    <rob> +1

    <DKA> +1

    <SeanP> +1

    RESOLUTION: ref LC-2037 yes, we have removed PUT partly in response
    to your comment

    [this was two part comment....thus the two resolutions]

    <jo> PROPOSED RESOLUTION: ref LC-2037 ref retrying POSTs, no, we
    agree that it shouldnot be necessary to point this out, but sadly it
    is

    <SeanP> +1

    <francois> +1

    <rob> +1

LC-2075 - Heuristics for 200 rejected responses - 4.1.5.2 Avoiding
"Request Unacceptable" Responses

    <jo> PROPOSED RESOLUTION: LC-2075 differences in behaviour: the
    internal operation of the proxy is not open to our specification, we
    need to point out to CT proxies that 406 responses are not the only
    way in which content proivders signal that they can't or won't
    handle a request

    <jo> PROPOSED RESOLUTION: LC-2075 differences in behaviour: the
    internal operation of the proxy is not open to our specification, we
    need to point out to CT proxies that in practice 406 responses are
    not the only way in which content proivders signal that they can't
    or won't handle a request, though we do say that this is the
    preferred way of them doing so

    <SeanP> +1

    <jo> +1

    <francois> +1

    +1

    <rob> +1

    <dom> +0.1

    RESOLUTION: LC-2075 differences in behaviour: the internal operation
    of the proxy is not open to our specification, we need to point out
    to CT proxies that in practice 406 responses are not the only way in
    which content proivders signal that they can't or won't handle a
    request, though we do say that this is the preferred way of them
    doing so

    <jo> PROPOSED RESOLUTION: ref LC-2075, we have changed the text to
    refer only to POST and we acknowledge that this should not need
    restatement from RFC 2616 but we are aware of this kind of
    misoperation "in the wild"

    <SeanP> +1

    <francois> +1

    <jo> +1

    RESOLUTION: ref LC-2075, we have changed the text to refer only to
    POST and we acknowledge that this should not need restatement from
    RFC 2616 but we are aware of this kind of misoperation "in the wild"

    break and discussing dinner arrangements

LC-2076, LC-2039 - same headers for all resources - 4.1.5.4 Sequence of
Requests

    francois: the purpose of the text is to say that CT proxies need to
    behave consistently and the text needs clarification
    ... you don't have to send the same headers if you are requesting an
    embedded resource

    <dom> [I think "form part of a representation" is what makes the
    usage of the word "representation" confusing]

    jo: i recall we received many comments on basic tests noting that
    the content negotiation depends on the headers

    <dom> [part of a representation is a sequence of bytes, not a
    stylesheet or an image]

    jo: you could specifiy specific headers for each resource
    ... in practice that not what browser do or servers implement

    dom: firefox actually does that

    jo: relying on this is unwise
    ... it is relatively common for adaptation solution to regard
    headers in the whole rather than in the part
    ... we are observing an in practice best practice

    dom: mark is saying that giving the advice on a per header basis
    than the partial header is better
    ... content adaptation solutions are likely to use that

    jo: we not allowing changes to the UAProf header

    francois: just the UA header

    <DKA> ack

    <Zakim> dom, you wanted to note ambiguity of "part of a
    representation"

    dom: use of the term representation is confusing, from Mark. we need
    to change that.
    ... is used to render the represenation

    francois: I think we removed that wording from the latest draft of
    Basic Tests

    Sean: could we say something like embedded resources?

    dom: we can reformulate this later

    jo: we use "vital to the rendering of that resource"
    ... i am happy we have not used represenation incorrectly

    <jo> use the term "included resources" per the definition mobileOK
    Basic Tests

    SeanP: if you don't change the headers of the top level document you
    should not change them for the images...is what we are saying

    <jo> PROPOSED RESOLUTION: Ref LC-2076 - yes, we will change the sue
    of the word representation and use something like "included
    resources"

    <jo> PROPOSED RESOLUTION: Ref LC-2076 - yes, we will change the use
    of the word representation and use something like "included
    resources"

    <SeanP> +1

    <francois> +1

    <DKA> +1

    <rob> +1

    RESOLUTION: Ref LC-2076 - yes, we will change the use of the word
    representation and use something like "included resources"

    <jo> PROPOSED RESOLUTION: ref LC-2039 and LC-2076: Yes, we will
    clarify that we are talking about keeping the User Agent Header
    consistent

    <SeanP> +1

    <francois> +1

    <dom> +1

    <rob> +1

    RESOLUTION: ref LC-2039 and LC-2076: Yes, we will clarify that we
    are talking about keeping the User Agent Header consistent

    <DKA> +1

LC-2079, LC-2041, LC-2080 - 4.2.1 Use of HTTP 406 Status - 4.2.2 Server
Origination of Cache-Control: no-transform

    francois: section 4.2 will be changed from normative to informative

    <jo> PROPOSED RESOLUTION: ref LC-2079, yes, we intend to move server
    behaviour into a non-normative section and point out that servers
    may wish to respond with no-transform as this respects the intention
    of the requester

    <jo> PROPOSED RESOLUTION: ref LC-2041, LC-2080 and LC-2079, yes, we
    intend to move server behaviour into a non-normative section and
    point out that servers may wish to respond with no-transform if they
    think that this respects the intention of the requester and that for
    the sake of clarity use of 406 is clearer than using a default
    representation using 200 and the text "your browser is not
    supported"

    <rob> +1

    dom: I don't think this responds to LC-2080 or LC-2041

    jo: I think it does

    dom: are we still mentioning cache control?

    francois: we are talking about cache control in the request not to
    transform

    <SeanP> +1

    jo: I can't see a way around this. It is reasonable for us to say if
    there is a request not to transform the server can ...?

    francois: we moving to non normative...

    <francois> +1

    <DKA> +1

    RESOLUTION: ref LC-2041, LC-2080 and LC-2079, yes, we intend to move
    server behaviour into a non-normative section and point out that
    servers may wish to respond with no-transform if they think that
    this respects the intention of the requester and that for the sake
    of clarity use of 406 is clearer than using a default representation
    using 200 and the text "your browser is not supported"

LC-2045 - Respect of RFC2616 - 4.2.2 Server Origination of
Cache-Control: no-transform

    francois: it is about restating RFC HTTP
    ... we should not. we could use a link

    jo: we repeat for emphasis
    ... in cases for violation happens

    francois: but why do we repeat here and not in other sections?

    SeanP: he asks if we really mean it

    jo: then this is in the wrong section. This is about server
    behavior.

    francois: into which section should it go?
    ... 4.1.2 or 4.3.1

    <dom> (I updated the comment to reflect that it really is about
    4.3.1)

    francois: we already have some text then....we may have to clarify
    this as we has some comment on it

    SeanP: we are saying it twice already..

    jo: we could insert a note for emphasis

    francois: or put down a link

    jo: to 13.5.2

    dka: why don't you want to put in text to emphasize?

    jo: it can't get much clearer than what we have

    dka: why is it wrong to repeat?

    jo: we don't want to restate http

    dka: you are making an assumption that somebody would read http spec

    <francois> PROPOSED RESOLUTION: re. LC-2045, resolve partial,
    comment actually applies to 4.3.1 where it is emphasized that
    proxies MUST behave "transparently" with a link to the definition
    that contains links to sections 13.5.2 and 14.9.5 of RFC2616

    jo: you would have to be

    <dom> (should we actually provide as an appendix with all the
    conformance requirements of http that would be relevant to a content
    transformation proxy?)

    <jo> [dom is welcome to make a contribution along those lines]

    <SeanP> +1

    <DKA> +1

    <francois> +1

    RESOLUTION: re. LC-2045, resolve partial, comment actually applies
    to 4.3.1 where it is emphasized that proxies MUST behave
    "transparently" with a link to the definition that contains links to
    sections 13.5.2 and 14.9.5 of RFC2616

    break for lunch reconvene 1:30

    <francois> ACTION: daoust to look into an appendix with relevant
    normative statements of RFC2616 and report back to the group.
    [recorded in
    [47]http://www.w3.org/2008/10/20-bpwg-minutes.html#action03]

    <trackbot> Created ACTION-867 - Look into an appendix with relevant
    normative statements of RFC2616 and report back to the group. [on
    François Daoust - due 2008-10-27].

    <jo> [break for lunch]

LC-2081 - About not basing actions on knowledge - 4.2.3.1 Use of Vary
HTTP header

    francois: text is not clear enough

    <DKA> Jo: "If your content isn't consistent with the header that
    you're sending then you shouldn't send it"

    seanP: it's only informative

    dom: we agreed to remove normative burdens on origin servers

    DKA: so do we need this at all?

    jeffs: but if I need to ask someone what this means then it's not
    useful

    dka: what's the other comment on this section?

    francois: LC-2008 is already resolved
    ... and that's not the problem here with LC-2081

    dka: as part of this informationizationing is the proposal to remove
    the second para of 4.2.3.1?

    jo: no
    ... say "don't misrepresent your content"

    <jo> PROPOSED RESOLUTION: Change second second para of 4.2.3.1 to
    say "don't misrepresent your content, even if you think that will
    avoid it being transformed"

    <jo> PROPOSED RESOLUTION: Change second second para of 4.2.3.1 to
    say "don't systematically misrepresent your content, even if you
    think that will avoid it being transformed"

    <SeanP> +1

    +1

    <jeffs> +1

    <francois> +1

    RESOLUTION: Change second second para of 4.2.3.1 to say "don't
    systematically misrepresent your content, even if you think that
    will avoid it being transformed"

    <dom> re TAG response to our request for comments,
    [48]http://www.w3.org/2001/tag/2008/10/09-minutes#item03 " Norm was
    to review this and see if it was something we needed to take a look
    at. [...] Dan moved it to be due next week, I'll endeavor to review
    it before then"

      [48] http://www.w3.org/2001/tag/2008/10/09-minutes#item03

LC-2009, LC-2010, LC-2011 - Use of the link element - 4.2.3.2
Indication of intended presentation media type of presentation

    francois: we should postpone this discussion until we get a response
    from TAG

    <dom> [this also was on the agenda for Oct 16, but haven't found the
    minutes of that meeting
    [49]http://lists.w3.org/Archives/Public/www-tag/2008Oct/0088.html ]

      [49] http://lists.w3.org/Archives/Public/www-tag/2008Oct/0088.html

    francois: what is clear is that the current text is based on an
    incorrect assertion

    <dom> [50]http://www.w3.org/2008/10/16-tagmem-minutes.html doesn't
    have any mention of CT guidelines afaict

      [50] http://www.w3.org/2008/10/16-tagmem-minutes.html

    <dom> [and no update on
    [51]http://www.w3.org/2001/tag/group/track/actions/173 , TAG's
    relation action item ]

      [51] http://www.w3.org/2001/tag/group/track/actions/173

    francois: and the text will need to change when we have TAG's advice

    dom: Personally I don't think we should wait for TAG's response - we
    can close the issue now

    jo: let's go back to the LC-2010 in question

    <DKA> PROPOSED RESOLUTION: LC-2010 is void and thereby will be
    ignored.

    <DKA> PROPOSED RESOLUTION: LC-2010 is a reasonable comment but is
    now overtaken by events.

    <DKA> PROPOSED RESOLUTION: LC-2010 is a reasonable comment but is
    now overtaken by events - namely that we don't propose to use
    fragment identifiers as a method to achieve this anymore. yada yada

    <francois> +1

    +1

    <SeanP> +1

    <jeffs> +1 (esp the yadayada part)

    RESOLUTION: LC-2010 is a reasonable comment but is now overtaken by
    events - namely that we don't propose to use fragment identifiers as
    a method to achieve this anymore.

    jo: this is saying "if you have a non-local reference you may or may
    not be referring to this instance"

    <dom> " When a URI reference refers to a URI that is, aside from its
    fragment component (if any), identical to the base URI (Section
    5.1), that reference is called a "same-document" reference. The most
    frequent

    <dom> examples of same-document references are relative references
    that are empty or include only the number sign ("#") separator
    followed by a fragment identifier"

    francois: the RFC explains how to construct a local reference

    <dom> section 4.4, rfc 3986

    <dom> (available e.g. [52]http://www.faqs.org/rfcs/rfc3986.html )

      [52] http://www.faqs.org/rfcs/rfc3986.html

    francois: even if you have an absolute URI to the same document you
    can determine that it is in fact a local URI

    <dom> The base URI of a reference can be established in one of four
    ways, discussed below in order of precedence: Base URI Embedded in
    Content, Base URI from the Encapsulating Entity, Base URI from the
    Retrieval URI, Default Base URI

    <dom> 5.1 in RFC 3986

    <jo> [53]http://tools.ietf.org/html/rfc3986#section-4.4

      [53] http://tools.ietf.org/html/rfc3986#section-4.4

    <dom> [54]http://tools.ietf.org/html/rfc3986#section-5.1.3

      [54] http://tools.ietf.org/html/rfc3986#section-5.1.3

    <jo> [55]http://tools.ietf.org/html/rfc3986#section-5.1

      [55] http://tools.ietf.org/html/rfc3986#section-5.1

    <dom> " If no base URI is embedded and the representation is not
    encapsulated

    <dom> within some other entity, then, if a URI was used to retrieve
    the

    <dom> representation, that URI shall be considered the base URI.
    Note that

    <dom> if the retrieval was the result of a redirected request, the
    last URI

    <dom> used (i.e., the URI that resulted in the actual retrieval of
    the

    <dom> representation) is the base URI.

    <dom> "

    <dom> " Normalization of the base and target URIs prior to their
    comparison,

    <dom> as described in Sections 6.2.2 and 6.2.3, is allowed but
    rarely

    <dom> performed in practice. Normalization may increase the set of
    same-

    <dom> document references, which may be of benefit to some caching

    <dom> applications."

    jo: we are trying to say "this doccument is formatted for a mobile"
    ... we are also saying that content is available for media screen at
    this URI as well
    ... and that's not possible to do with the <link rel="alternate">
    mechanism

    <jo> PROPOSED RESOLUTION: Ref LC-2011 in 4.2.3.2 (and elsewhere as
    suits clarity and editorial convenience) at para 3 and the following
    note. Make it clear that where more than one representation is
    available from the same URI this ought to be represented by using a
    Vary header and can't be represented using <link>. In other cases
    the link header should be used to reference alternative
    representations

    <jo> (i.e. where the Base URI, ref RFC 3986 secs 5.5 and 5.1 does
    not indicate a same document reference)

    <francois> +1

    <dom> +1

    <DKA> +1 to the sentiment but I don't like using the word "ought"

    <SeanP> +1 (although I think it is complicated enough that it will
    be rarely used)

    <jeffs> + and agree w DKA

    <jo> ought = Should (non normative, no relation to RFC 2119)

    <Kai> +1

    +1

    <dom> [latest link header in http draft, to make sure to derail the
    discussion
    [56]http://tools.ietf.org/id/draft-nottingham-http-link-header-02.tx
    t ]

      [56] http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt

    RESOLUTION: Ref LC-2011 in 4.2.3.2 (and elsewhere as suits clarity
    and editorial convenience) at para 3 and the following note. Make it
    clear that where more than one representation is available from the
    same URI this ought to be represented by using a Vary header and
    can't be represented using <link rel="alternate">. In other cases
    the link header should be used to reference alternative
    representations (i.e. where the Base URI, ref RFC 3986 secs 5.5 and
    5.1 does not indicate a same document reference)

    and 5.1 does not indicate a same document reference)

    <dom> [Jo notes that it doesn't feature the equivalent of the
    "media" attribute in html]

    <jo> [jo note that the draft-nottingham etc. do not provide a
    machanism to represent the equivant of media attribute]

    francois: and we won't mention fragment identifiers because it's not
    relevant

    <francois> PROPOSED RESOLUTION: re. LC-2009, resolve yes,
    acknowledge RFC3986 section 4.4 and remove the part on fragment
    identifiers

    <DKA> +1

    <francois> +1

    <SeanP> +1

    +1

    RESOLUTION: re. LC-2009, resolve yes, acknowledge RFC3986 section
    4.4 and remove the part on fragment identifiers

    <jeffs> +1

    <DKA> PROPOSED RESOLUTION: re. LC-2020, resolve no, we do not want
    to step

LC-2020 - Copyright - 4.3 Proxy forwarding of response to user agent

    <DKA> PROPOSED RESOLUTION: re. LC-2020, resolve no, we do not want
    to step into legal matters.

    Francois: If the meta Copyright tag, then the page must not be
    reformatted.

    DKA: Do we need to consider this since you are recommending that we
    resolve no.

    <rob> +1

    DOM: I think the comment is bogus.

    Jo: We need to say the copyright of the material is not affected by
    the copyright meta tag.
    ... Point is valid, however.

    DKA: This stuff is up to the lawyers do decide.

    <francois> PROPOSED RESOLUTION: re. LC-2020, resolve no, the
    presence or absence of a Copyright is not a clear indication of the
    rights associated with the page

    +1

    <DKA> +1

    RESOLUTION: re. LC-2020, resolve no, the presence or absence of a
    Copyright is not a clear indication of the rights associated with
    the page

    <jeffs> +1

LC-2082, LC-2042 - Cascading proxies - 4.3.2 Receipt of Warning: 214
Transformation Applied

    <DKA> PROPOSED RESOLUTION: re. LC-2082, LC-2042, resolve no,
    cascading proxies are not as easy as they seem, and the "MUST NOT"
    only applies to "CT" proxies, not proxies in general.

    Francois: What we say in 4.3.2, we say if there is a Warning header,
    then proxies should not perform transformation. We decided that
    having 2 cascading CT proxies was out of scope.

    Dom: But 4.3.2 doesn't say it is out of scope.

    Francois: Right.

    Jo: The point of this section is to say that if the content goes
    thru a CT proxy then goes through another one, it can be a problem.

    Dom: Doesn't that rule out server side transformation.

    Jo: No. Since server-side transformation is out of scope.

    Francois: But we are saying is that multiple CT proxies are out of
    scope, but we are addressing it.

    Jo: No we are saying server side transformation is out of scope, not
    multiple CT proxies.

    Francois: We say earlier in the document that we don't discuss
    multiple CT proxies in detail.
    ... These guide lines only apply to CT proxies, not all proxies.

    DKA: A real example from Vodafone. There was content that was
    transformed by Yahoo, then transformed again by Novarra. This caused
    a problem since they had no knowledge of each other.

    Kai: But aren't we just legislating that people shouldn't make
    mistakes.

    Dom: If a CT proxy transforms to mobile friendly state, why couldn't
    another proxy transform it again.

    DKA: We're trying to get CPs to add logic to make their content to
    work well on mobile devices.

    Kai: By saying this you are making it difficult to perform a two
    step process.

    Jo: Why not leave out the Warning header if you want to do that.

    Dom: We are adding a meaning to the Warning header that is not in
    the original specification.

    <DKA> PROPOSED RESOLUTION: WRT LC-2082, LC2042: resolve_yes and
    remove 4.3.2

    <jo> PROPOSED RESOLUTION: WRT LC-2082, LC2042: resolve_yes and
    remove 4.3.2 replace with a section noting that intermediate proxies
    should send no-transform if they want to inhibit further
    transformation

    <francois> +1

    <jeffs> +1

    +1

    <Kai> +1

    <DKA> +1

    <rob> +1

    RESOLUTION: WRT LC-2082, LC2042: resolve_yes and remove 4.3.2
    replace with a section noting that intermediate proxies should send
    no-transform if they want to inhibit further transformation

LC-2083 - Sniffing rejected responses - 4.3.3 Server Rejection of HTTP
Request

    <DKA> PROPOSED RESOLUTION: re. LC-2083, resolve partial, we are
    addressing legacy content, there is no way to be more precise.
    Remove the part on "servers that do not implement this
    Recommendation".

    Francois: We should resolve "No" since we can't be more precise
    because we are dealing with legacy content.

    DKA: We should make it clear that this kind thing is what
    differentiates CT proxies.

    <jo> PROPOSED RESOLUTION: ref LC-2083, no, it is an important part
    of the mechanism described in 4.1.5 so has to be here in some form.
    We don't mean to propose this as a fail safe mechanism, we merely
    mean to indicate that CT proxies may need to employ heuristics to
    provide an improved service for their users. Remove reference to
    conforming servers.

    <francois> +1

    <DKA> +1

    <jeffs> +1

    +1

    RESOLUTION: ref LC-2083, no, it is an important part of the
    mechanism described in 4.1.5 so has to be here in some form. We
    don't mean to propose this as a fail safe mechanism, we merely mean
    to indicate that CT proxies may need to employ heuristics to provide
    an improved service for their users. Remove reference to conforming
    servers.

LC-2084 - purpose of behavior - 4.3.4 Receipt of Vary HTTP Header

    <DKA> PROPOSED RESOLUTION: re. LC-2084, resolve partial, and add a
    link back to 4.1.5.2 that explains the use case.

    Francois: Use case is in 4.1.5.2 which is already there.

    <DKA> PROPOSED RESOLUTION: re. LC-2084, resolve no since ample
    reasoning is provided.

    <DKA> PROPOSED RESOLUTION: re. LC-2084, resolve no since ample
    reasoning is provided (link to 4.1.5.2 that explains the use case).

    +1

    Jo: This is a failsafe mechanism.

    Francois: What I had in mind is that the reference to 4.1.5.2 should
    be at the beginning of the sentence.

    <jo> PROPOSED RESOLUTION: re. LC-2084, resolve partial since this is
    part of the fail safe mechanism defined in 4.1.5.2 that explains the
    use case. Move reference to 4.1.5.2 earlier int he sentence and
    simplify wording

    <DKA> +1

    <DKA> -1

    <francois> +1

    <DKA> �1

    <jo> PROPOSED RESOLUTION: re. LC-2084, resolve partial since this is
    part of the fail safe mechanism defined in 4.1.5.2 that explains the
    use case. Move reference to 4.1.5.2 earlier int he sentence and
    simplify wording, add reference to example kindly to be re-provided
    by Francois

    <francois> +1

    <DKA> +1

    <rob> +1

    <dom> +1

    <jeffs> +1

    RESOLUTION: re. LC-2084, resolve partial since this is part of the
    fail safe mechanism defined in 4.1.5.2 that explains the use case.
    Move reference to 4.1.5.2 earlier int he sentence and simplify
    wording, add reference to example kindly to be re-provided by
    Francois

LC-1998 - No transformation for application/xhtml+xml - 4.3.6 Proxy
Decision to Transform

    Francois: Most CP's misread this section.
    ... Most of the comments are to be comprehensive on the heuristics,
    but we can't do that.

    <DKA> PROPOSED RESOLUTION: re. LC-1998, resolve no since lots of
    non-mobile web pages actually send xhtml+xml mime type.

    Francois: This may be true for the time being, but we can't really
    do this.

    <DKA> PROPOSED RESOLUTION: re. LC-1998, resolve no since lots of
    non-mobile web pages actually send xhtml+xml mime type.

    <DKA> PROPOSED RESOLUTIONS: Remove the examples of mobile-specifc
    doctypes in 4.3.6 and remain silent on this issue...

    Jo: We didn't put in content types for good reasons. We probably
    should remove the lists of doc types.

    Francois: I think it is good to have some examples, but to just say
    they are examples.

    Dom: Having examples of heuristics makes it seem like we are
    endorsing them.

    Jo: This is kind of my point.

    DKA: I think some examples are good.

    Jeff: I would really object to removing examples.

    DKA: You are limiting the scope of the document if you are limiting
    to implementors of CT proxies.

    Jo: Our job is to be clear, not discoursive (?).

    Jeff: I think the audience should also be people developing the
    content, so the examples are useful.

    DKA: We need to be clear that these are examples. We are trying to
    be responsive to the community that made these comments.

    Dom: By increasing the number of examples, we don't really do any
    service.

    <jo> PROPOSED RESOLUTION: Remove examples of heuristics from the
    main run of text and include Appendices to list in a *non-endorsed*
    way lists of stuff that other people have used but are No-endorsed
    by us, and did I mentionthat they are not endorsed

    Francois: Why don't we move the examples to an appendix?

    <jeffs> +1

    <rob> +1

    +1

    RESOLUTION: Remove examples of heuristics from the main run of text
    and include Appendices to list in a *non-endorsed* way lists of
    stuff that other people have used but are No-endorsed by us, and did
    I mentionthat they are not endorsed

    <DKA> +1 with the addition of some of the additional doctypes listed
    by the feedback...

    <jeffs> +1

    <DKA> (at editor's discression)

    <DKA> PROPOSED RESOLUTION: re. LC-1998, resolve no since lots of
    non-mobile web pages actually send xhtml+xml mime type.

    <jo> PROPOSED RESOLUTION: re. LC-1998, resolve no and point out to
    commenter that this assumption is unsafe without other supporting
    evidence.

    +1

    <francois> +1

    <rob> +1

    RESOLUTION: re. LC-1998, resolve no and point out to commenter that
    this assumption is unsafe without other supporting evidence.

    <jeffs> +1

LC-1999

    <dom> "increase your page size!"

    <jo> PROPOSED RESOLUTION: Resolve comenter and point out to
    commenter that size on its own is unsafe as an indicator of mobile
    friendlines e.g. content with emdedded flash

    +1

    <francois> +1

    <rob> +1

    PROPOSED RESOLUTION: Resolve comenter and point out to commenter
    that size on its own is unsafe as an idicator of mobile friendlines
    e.gf. content with emdedded flash

    <jeffs> +1 s/comenter/commenter

    <jo> PROPOSED RESOLUTION: Ref LC-1999 Resolve no commenter and point
    out to commenter that size on its own is unsafe as an indicator of
    mobile friendlines e.g content with embedded flash

    <DKA> +1

    RESOLUTION: Ref LC-1999 Resolve no commenter and point out to
    commenter that size on its own is unsafe as an indicator of mobile
    friendlines e.g content with embedded flash

LC-2048, LC-2002, LC-2052, LC-2021 - Heuristics - 4.3.6 Proxy Decision
to Transform

    <jo> PROPOSED RESOLUTION: Ref LC-2048 and LC-2002, LC-2052 and
    LC-2021, resolve partial, and say that we include these examples as
    non-endorsed heuristics in the non endorsed heuristics appendi

    <DKA> +1

    <francois> +1

    +1

    RESOLUTION: Ref LC-2048 and LC-2002, LC-2052 and LC-2021, resolve
    partial, and say that we include these examples as non-endorsed
    heuristics in the non endorsed heuristics appendix

    <jeffs> +1

LC-2022 - i-mode content - 4.3.6 Proxy Decision to Transform

    Francois: Put this one separate in case we missed something. I don't
    think we did.

    <jo> PROPOSED RESOLUTION: Ref LC-2022 resolve partial, we agree that
    this was not included and have added it as a non-endorsed heuristic
    in the relevant appendix

    +1

    <francois> +1

    <DKA> +1

    RESOLUTION: Ref LC-2022 resolve partial, we agree that this was not
    included and have added it as a non-endorsed heuristic in the
    relevant appendix

    <jo> x-zillon/tharg

LC-2090, LC-2000 - No extra content without the consent of the content
owner - 4.3.6 Proxy Decision to Transform

    Francois: I think this is out of scope. It's a legal matter

    <jo> PROPOSED RESOLUTION: Ref LC-2090 and LC-2000, resolve no, other
    than to note that adding extra content is forbidden where
    no-transform is present

    +1

    <rob> +1

    <jeffs> +1

    Rigo: There should be a way to keep CT proxies from transforming.

    Francois: There is another point in the comment where the CT proxy
    could add an ad.

    Jo: If I put a copyright notice on my content, but no no-transform,
    the commenters will say we are not doing our job. Should just
    copyright notice be necessary?

    Rigo: No. Copyright notice is American disease. Even in U.S.
    copyright notice is not necessary anymore.
    ... Even if you assert your copyright and put your content on the
    web, it is implicit statement that you want people to read my stuff.
    This means you need to live with what is socially adequate in the
    medium.
    ... The copyright holder needs to indicate that the he/she wants to
    opt out of this kind of thing.
    ... <Introduces self>

    <jo> PROPOSED RESOLUTION: Ref LC-2090 and LC-2000, resolve no, other
    than to note that adding extra content is forbidden where
    no-transform is present and content providers should use this if
    they want to be sure their content is not added to

    <francois> +1

    <rob> +1

    <DKA> +1

    +1

    <Kai> +1

    <jeffs> +1

    RESOLUTION: Ref LC-2090 and LC-2000, resolve no, other than to note
    that adding extra content is forbidden where no-transform is present
    and content providers should use this if they want to be sure their
    content is not added to

    <jeffs> +1

    <jo> [break]

LC-2013 - meta http-equiv - 4.3.6 Proxy Decision to Transform

    next last-call comment: 2013

    <francois> PROPOSED RESOLUTION: re. LC-2013, resolve yes, and
    clarify that we mean

    <francois> "in the absence of a Vary HTTP header and in the absence
    of a

    <francois> no-transform directive defined at the HTTP level or using
    a meta

    <francois> http-equiv element containing Cache-Control:
    no-transform"

    re: meta http-equiv - 4.3.6 Proxy Decision to Transform

    francois: this applies to 4.3.1
    ... servers may not take account of content-transformation headers

    dom: headers might have precedent

    is the only reason we do this is for legacy converters? no, servers
    may not have access to content-transformation

    <jo> PROPOSED RESOLUTION: Ref LC-2013 clarify in 4.3.1 and 4.3.6 and
    in other relevant sections that meta http-equiv should be consulted
    if the relevant actual HTTP header is not present

    dom: the only dependable indicator is cache-n-transform directory

    francois: move it to 4.3.1??

    <jo> PROPOSED RESOLUTION: Ref LC-2013, resolve yes, clarify in 4.3.1
    and 4.3.6 and in other relevant sections that meta http-equiv should
    be consulted if the relevant actual HTTP header is not present

    <francois> +1

    <dom> +1

    +1

    <DKA> +1

    RESOLUTION: Ref LC-2013, resolve yes, clarify in 4.3.1 and 4.3.6 and
    in other relevant sections that meta http-equiv should be consulted
    if the relevant actual HTTP header is not present

    <SeanP> +1

    +1

LC-2051 - Open Mobile Alliance Standard Transcoding Interface work -
Appendix A and D

    <dom>
    [57]http://www.openmobilealliance.org/technical/release_program/sti_
    v10.aspx

      [57] 
http://www.openmobilealliance.org/technical/release_program/sti_v10.aspx

    <dom> [58]Standard Transcoding Interface

      [58] 
http://www.openmobilealliance.org/technical/release_program/sti_v10.aspx

    dka: let us not put dependencies behind this, so we can finalize the
    document

    francois: will review the document and propose edits

    <dom>
    [59]http://www.openmobilealliance.org/technical/release_program/docs
    /CopyrightClick.aspx?pck=STI&file=V1_0-20050607-C/OMA-ERELD-STI-V1_0
    -20050607-C.pdf

      [59] 
http://www.openmobilealliance.org/technical/release_program/docs/CopyrightClick.aspx?pck=STI&file=V1_0-20050607-C/OMA-ERELD-STI-V1_0-20050607-C.pdf

    <francois> ACTION: LC-2051, daoust to review OMA STI to see if
    there's something relevant for CT [recorded in
    [60]http://www.w3.org/2008/10/20-bpwg-minutes.html#action04]

    <trackbot> Sorry, couldn't find user - LC-2051,

    <francois> ACTION: daoust to review OMA STI to see if there's
    something relevant for CT for LC-2051 [recorded in
    [61]http://www.w3.org/2008/10/20-bpwg-minutes.html#action05]

    <trackbot> Created ACTION-868 - Review OMA STI to see if there's
    something relevant for CT for LC-2051 [on François Daoust - due
    2008-10-27].

LC-1995 - About "recent" HTTP "drafts" - Appendix D.2

    <DKA> PROPOSED RESOLUTION: re. LC-1995, resolve yes, and replace
    "recent draft of HTTP" by "HTTP 1/1"

    LC-1995 - About "recent" HTTP "drafts" - Appendix D.2

    <dom> [should we link to mark nottingham's draft?]

    <DKA> PROPOSED RESOLUTION: re. LC-1995, resolve yes, and replace
    "recent draft of HTTP" by "HTTP /1.1"

    <DKA> PROPOSED RESOLUTION: re. LC-1995, resolve yes, and replace
    "recent draft of HTTP" by "HTTP/1.1"

    <SeanP> +1

    +1

    <DKA> +1

LC-2047 - Cascading proxies - Appendix D.4 Inter Proxy Communication

    <DKA> PROPOSED RESOLUTION: re. LC-2047, resolve no, and point out a
    specific example of why it's not that simple to the commenter

    francois: long comment about how to resolve cascading proxies case
    ... resolution is not easy in practice
    ... with cascading proxies, cannot control the chain

    jo: key point: let us define our terms
    ... I interpret "upstream" & "downstream" differently than common
    parlance

    dka: think of the stream as between the server and the client...
    therefore upstream points to server and downstream points to client

    jo: salmon metaphor

    francois: the upstream proxy cannot transform when there is a
    downstream proxy

    jo: that is not what we do
    ... we do not regard downstream proxies as user agents in their own
    right
    ... comment is pointing out the combination of proxies makes a
    non-user-agent
    ... therefore must be passed on without transformation

    dom & francois: the results are the same

    dom: saying "do as if downstream proxy is not a user agent"

    francois: there is no reason to say the downsteam proxy has
    precedence over the upstream one

    dka: the upstream proxy knows more about the content

    francois: the first part is saying we cannot choose which has
    precedence
    ... the point is about the appendix

    jo: not only about the appendix

    <dom> PROPOSED RESOLUTION: Hi Shadi

    +1

    discussion: is the proxy part of the server or not?

    jo: at whiteboard & drawing things
    ... whatever comes out of the content provider's proxy may or may
    not remain the same as it moves through intermediate proxies

    dom & jo: interchange over sould be used vs could be used

    jo: can of worms: the transformers in the middle

    dom: we should say this is not as simple as it looks and we are
    looking for a way to state the problem & solution simply

    <DKA> PROPOSED RESOLUTION: re. LC-2047, resolve no, and point out a
    specific example of why it's not that simple to the commenter

    jo: add proxies should not add cache-control header

    <DKA> PROPOSED RESOLUTION: re. LC-2047, resolve partial, and point
    out a specific example of why it's not that simple to the commenter
    and add CT proxies should not add no-transform directive on upstream
    request.

    jo: when it passes through the network, you should not add
    cache-control header
    ... if anybody is doing transformation, it should be the one closest
    to the owner of what is being requested

    jo & francois: discussion of what we have said in past

    <dom> LC-2047.a

    discussion: inter-relationships between the 3 parts of the
    comment/proposal

    rob: almost impossible to tell who has done what in chain of proxies
    along path from client (requester) to server (responder)

    <jo> PROPOSED RESOLUTION: ref LC-2047 part a. No. We do not view the
    CT proxy as being a user agent in its own right, it is a proxy like
    any other. Knowing that it is upstream of other proxies doesn't
    alter it's prescibed behaviour according to this document

    jo: if you are a conforming proxy and receive a request, what should
    you do?

    jo & dom: discussion of whether altered headers result or not

    <DKA> PROPOSED RESOLUTION: re. LC-2047, resolve partial, and point
    out a specific example of why it's not that simple to the commenter.

    dka: should we include this recommendation? jo: already prohibited

    jo: do we want to say not to change the value of the warning itself?

    <jo> PROPOSED RESOLUTION: ref LC-2047 part a. No. We do not view the
    CT proxy as being a user agent in its own right, it is a proxy like
    any other. Knowing that it is upstream of other proxies doesn't
    alter it's prescibed behaviour according to this document b. we
    think that this is defined in HTTP and don't need to elaborate on it
    unless there are specific examples of misoperation that we can...

    <jo> ...refer to and c) we disagree and think that this is very
    complex and requires a substantial use case analysis to achieve a
    complete understanding of this, and we also think that a more
    complex HTTP vocabulary is required to achieve useful results.

    dka: concern that a lot of thought went into these comments & we may
    not be addressing them thoroughly

    <jo> PROPOSED RESOLUTION: ref LC-2047 part a. No. We do not view the
    CT proxy as being a user agent in its own right, it is a proxy like
    any other. Knowing that it is upstream of other proxies doesn't
    alter it's prescibed behaviour according to this document

    +1

    <jo> PROPOSED RESOLUTION: ref LC-2047 part b. we think that this is
    defined in HTTP and don't need to elaborate on it unless there are
    specific examples of misoperation that we can refer to

    discussion: simplify to say content transformers must be
    transparent??
    ... concern over variability of possible cases

    <jo> PROPOSED RESOLUTION: ref LC-2047 part c. we disagree and think
    that this is very complex and requires a substantial use case
    analysis to achieve a complete understanding. We think that a more
    complex HTTP vocabulary for inter proxy operation is likely to be
    required to achieve useful results, and we are not chartered to
    create technology of that kind

    <jo> PROPOSED RESOLUTION: Add a section with a diagram explaining
    which proxies are in scope

    discussion: are there cases where proxy server closest to the client
    should hold forth??

    <DKA> +1 to Jo's proposed resolution triptych

    <dom> isn't it a tetraptych?

    rob: what happens when https on closest to client but not on one
    closest to destination server

    <rob> +1

    <DKA> +1 to the tetraptych then

    <francois> +1 to the tetraptych

    +1 to the tetraptych

    <SeanP> +1 to all of them

    <francois> +1 to cheeseptych

    <dom>
    [62]http://www.w3.org/Consortium/Legal/2008/04-mobileok-policy.html

      [62] http://www.w3.org/Consortium/Legal/2008/04-mobileok-policy.html

    PROPOSED RESOLUTION: ref LC-2047 part a. No. We do not view the CT
    proxy as being a user agent in its own right, it is a proxy like any
    other. Knowing that it is upstream of other proxies doesn't alter
    it's prescibed behaviour according to this document

    RESOLUTION: ref LC-2047 part a. No. We do not view the CT proxy as
    being a user agent in its own right, it is a proxy like any other.
    Knowing that it is upstream of other proxies doesn't alter it's
    prescibed behaviour according to this document

    RESOLUTION: ref LC-2047 part b. we think that this is defined in
    HTTP and don't need to elaborate on it unless there are specific
    examples of misoperation that we can refer to

    RESOLUTION: ref LC-2047 part c. we disagree and think that this is
    very complex and requires a substantial use case analysis to achieve
    a complete understanding. We think that a more complex HTTP
    vocabulary for inter proxy operation is likely to be required to
    achieve useful results, and we are not chartered to create
    technology of that kind

    RESOLUTION: Add a section with a diagram explaining which proxies
    are in scope

W3C mobileOK Logo and policy

    presentation of MobileOK logo and policy

    2.2 conditions for conformance: 2 criteria

    <dom> [63]mobileOK policy

      [63] http://www.w3.org/Consortium/Legal/2008/04-mobileok-policy.html

    conditions to use these, all tests applicable to Basic Tests 1.0
    accomplished w a PASS or a WARN & reasonable efforts undertaken to
    comply w the conditions in the conformance section and not covered
    by any test

    so who certifies someone has met the criteria?

    <dom> [64]conformance section of latest draft of mobileOK

      [64] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/081018

    must enforce the conditions set or trademark protections are lost

    <dom> (this relates to ISSUE-250)

    <dom> and ACTION-799

    businesses may emerge which certify meeting these conditions, like
    the ISO approach

    <dom> ACTION-799?

    <trackbot> ACTION-799 -- Dominique Hazaël-Massieux to get back to
    rigo on updating the mobileOK license -- due 2008-07-24 -- OPEN

    <trackbot>
    [65]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/799

      [65] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/799

    dom to rigo: in case of MobileOK 1.0 all tests are machine-testable

    rigo: suggests putting 2nd bullet point (reasonable efforts
    undertaken to comply w the conditions in the conformance seciton and
    not covered by any test) into our documents

    jo: what is meant by "conditions in the conformance section and not
    covered by any test"

    dom: mobileOK basic is only about machine-testable issues

    rigo: suggestion for today is throw out 2nd bullet point & just say
    must pass machine-run auto-testing
    ... the simpler the rule, the easier to handle
    ... could get more granular on "applicable to the resource" by
    including a URI

    jo: URI is included in document

    rigo: then I am clear

    jo: role of the checker need to be looked at in the light of this

    rigo: checker is just a tool to claim passed & thus mobileOK

    jo: is the wording about "against a single resource" okay

    rigo: change to the URI rather than the resources behind the URI

    dom: the object of conformance is a discussion topic

    rigo: must be taken in context

    dom: claims of conformance may be made by a resource identified by a
    URI

    rigo: if we say "a single URI that passes" everyone can understand

    <jo> "Specifically, a claim of mobileOK may only be made of a URI
    that when dereferenced in the manner described in [mobileOK] yields
    a response that passes all the tests contained in mobileOK Basic
    Tests."

    rigo: should we just say an object behind a URI can claim
    conformance?

    rigo will rewrite jo's sentence, likes it

    <jo> should read "Specifically, a claim of mobileOK *conformance*
    may only be made of a URI that when dereferenced in the manner
    described in [mobileOK] yields a response that passes all the tests
    contained in mobileOK Basic Tests."

    dom: various earlier questions addressed by this approach

    rigo: shape primary in establishing recognition value re logo, color
    etc changes not as critical

    <Zakim> jo, you wanted to ask if the license should specify that the
    logo should not come from w3C servers

    jo: logo is not in and of itself a conformance claim, needs to
    include something machine-readable like headers to establish claim?
    is rigo saying logo itself indicates claim is present?

    rigo: there are sufficient use cases that this version of the terms
    & conditions does not preclude us also creating a machine-run
    protocol to automatically include as meeting terms&conditions

    <dom> ISSUE-250?

    <trackbot> ISSUE-250 -- The mobileOK License -- OPEN

    <trackbot>
    [66]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/250

      [66] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/250

    <dom> ACTION: Jo to review the mobileOK license in more details and
    send further questions to rigo [recorded in
    [67]http://www.w3.org/2008/10/20-bpwg-minutes.html#action06]

    <trackbot> Created ACTION-869 - Review the mobileOK license in more
    details and send further questions to rigo [on Jo Rabin - due
    2008-10-27].

    <DKA> PROPOSED RESOLUTION: We live Rigo!

    <dom> I'm proposing to close ACTION-799

    jo: need to look this over and think about it in more detail before
    we move beyond a resolution to think about it

    <DKA> PROPOSED RESOLUTION: We love Rigo!

    RESOLUTION: we love Rigo!

    <dom> close ACTION-799

    <trackbot> ACTION-799 Get back to rigo on updating the mobileOK
    license closed

    <dom> ACTION-869?

    <trackbot> ACTION-869 -- Jo Rabin to review the mobileOK license in
    more details and send further questions to rigo -- due 2008-10-27 --
    OPEN

    <trackbot>
    [68]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/869

      [68] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/869

    jo: wants to close on the subject by (as editor of the MobileOK
    document) by forming sub-committee w Dom & Rigo to discuss and work
    on this

    <DKA> PROPOSED RESOLUTION: Dom, Jo and Rigo to form a subcommittee
    to come back with a final proposal to the group following on from
    Rigo's current proposal.

    RESOLUTION: Dom, Jo and Rigo to form a subcommittee to come back
    with a final proposal to the group within 4 weeks following on from
    Rigo's current proposal.

    <Zakim> Kai, you wanted to ask if it is not a risk to focus on the
    logo in the policy, as it will steer users to only use the visual
    representation?

    Kai: focus on logo may make machine-readable "fall by the wayside"

    shadi: wants to clarify that WCAG conformance is not about machine
    vs human testing
    ... do not be worried about having manual tests for MobileOK in
    future
    ... many models of conformance which can be explored
    ... ensure there are objectively testable criteria to avoid
    different reviewers coming up with different results

    <DKA> Resolution of Boo-yeah!

    <francois> [Meeting adjourned]

Summary of Action Items

    [NEW] ACTION: daoust to look into an appendix with relevant
    normative statements of RFC2616 and report back to the group.
    [recorded in
    [69]http://www.w3.org/2008/10/20-bpwg-minutes.html#action03]
    [NEW] ACTION: daoust to review OMA STI to see if there's something
    relevant for CT for LC-2051 [recorded in
    [70]http://www.w3.org/2008/10/20-bpwg-minutes.html#action05]
    [NEW] ACTION: Jo to include text referencing resolution to LC-2003
    [recorded in
    [71]http://www.w3.org/2008/10/20-bpwg-minutes.html#action02]
    [NEW] ACTION: Jo to review the mobileOK license in more details and
    send further questions to rigo [recorded in
    [72]http://www.w3.org/2008/10/20-bpwg-minutes.html#action06]
    [NEW] ACTION: Jo to word smith resolution on LC-2069 in line with
    its spirit and come up with something a bit cleaner andmore
    comprehensible [recorded in
    [73]http://www.w3.org/2008/10/20-bpwg-minutes.html#action01]
    [NEW] ACTION: LC-2051, daoust to review OMA STI to see if there's
    something relevant for CT [recorded in
    [74]http://www.w3.org/2008/10/20-bpwg-minutes.html#action04]

    [End of minutes]
Received on Wednesday, 22 October 2008 10:38:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC