W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

[minutes] F2F Day 2 - 26 March 2009 - Content Transformation Guidelines

From: Francois Daoust <fd@w3.org>
Date: Mon, 30 Mar 2009 14:36:03 +0200
Message-ID: <49D0BCB3.3000100@w3.org>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Hi,

The minutes of the second day of last week's F2F are available at:
  http://www.w3.org/2009/03/26-bpwg-minutes.html
... and copied as text below.

Before moving on to Content Transformation, we discussed the use of 
Canvas and/or SVG in the context of Mobile Web Application Best 
Practices. Positions varied from "nothing to recommend as BP" to "Canvas 
rulez". Dan and Jeff are to cook something up out of this.

On Content Transformation, most of the usual suspects were around the 
table. Tom could unfortunately not attend the meeting (hope you are 
well, Tom!). Eduardo was eventually able to attend the meeting 
physically thanks to dotMobi's sponsoring of part of his travel expenses.

Regarding the last remaining hot issues:

About Links rewriting
-----
We agreed that:
  1. Proxies MAY rewrite links, where content transformation is 
permitted, providing that content domain origin distinctions are 
preserved by the proxy such that browsers accessing content via the 
proxy do not inappropriately misconstrue different content origins as 
being the same and inappropriately share cookies, or allow execution of 
scripts or do other things that cause security problems as a result of 
not knowing that different origins are involved.
  2. Since there doesn't appear to be a way in which the URI sent to the 
User Agent can be manipulated to preserve security related to same 
origin policies it is permissible for a CT proxy to act on content in so 
that security is nonetheless preserved as adjudged by conformance tests 
that are to be researched. If no such security tests can be found then 
there cannot be conformance associated with link rewriting and it cannot 
be permissible for CT proxies to do so.

I am to investigate on the availability of tests to ensure that the same 
origin policy is preserved on Content Transformation proxies.


About HTTPS links rewriting
-----
The lengthy discussion and final resolution was reopened on the final 
day of the F2F.
See my upcoming email on the minutes of that last day for details.


About "heuristics" to prevent content transformation
-----
- .mobi domain names was added to the list of mandatory heuristics
- The other mandatory heuristics are that agreed during the 10 March call:
  http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0066.html
- we agreed not to list any non-mandatory heuristics, so that there be 
no confusion or false expectation on how a Content Transformation proxy 
is supposed to handle those.


On X-Device-* HTTP header fields
-----
- They are needed
- I am to progress registration of the X-Device-* headers in the IANA 
provisional message header field names:
  http://www.iana.org/assignments/message-headers/prov-headers.html


Other
-----
We reviewed the remaining actions and last call comments and agreed on 
other more minor changes that need to be brought to the guidelines.

Thanks,
Francois.


-----
26 Mar 2009

    [2]Agenda

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

    See also: [3]IRC log

       [3] http://www.w3.org/2009/03/26-bpwg-irc

Attendees

    Present
           Jo, Kai, Eduardo, Rob, SeanP, DKA, francois, Jeffs, Jonathan,
           Adam, Alan, Seungyun, Bryan_on_the_phone

    Regrets
           none

    Chair
           dka

    Scribe
           Kai, Rob, Alan

Contents

    The day started with a discussion on SVG and Canvas for the
    [4]Mobile Web Application Best Practices (MWABP) specification. The
    rest of the day was spent addressing the remaining issues on the
    [5]Guidelines for Web Content Transformation Proxies (CT)
    specification.
      * [6]Topics
          1. [7]MWABP - Canvas
          2. [8]CT - HTTPS Link Rewriting
          3. [9]Disclosure on Eduardo's presence to the F2F
          4. [10]CT - ISSUE-285 - Links rewriting
          5. [11]CT - ISSUE-288 and ISSUE-284 - Non-normative list of
             mobile heuristics
          6. [12]CT - ISSUE-289 - Are X-Device-* HTTP Header fields
             needed?
          7. [13]CT - Miscellaneous actions
          8. [14]CT - ACTION-912 - X-Device-* HTTP Header fields
             registration
          9. [15]CT - Abstract improvement
         10. [16]CT - LC-2050 - restructuring, recoding, optimization
         11. [17]CT - LC-2023 - charsets
         12. [18]CT - LC-2084 - Vary HTTP header
         13. [19]CT - LC-2047 - inter-proxy communication
         14. [20]CT - LC-2053 - preventing transformation of mobile Web
             pages
         15. [21]CT - LC-2040 - 4.1.5.5 defines a protocol
         16. [22]CT - LC-2044 - Web browsers identification
         17. [23]CT - OPES reference
         18. [24]CT - Rotan's point
         19. [25]CT - Editorial notes
         20. [26]CT - OPES and two-party consent
      * [27]Summary of Action Items

       [4] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20091703
       [5] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/0090313

Minutes of the F2F

      * [28]Day 1/3
      * [29]Day 2/3 (this page)
      * [30]Day 3/3
      _________________________________________________________

      [28] http://www.w3.org/2009/03/25-bpwg-minutes.html
      [29] http://www.w3.org/2009/03/26-bpwg-minutes.html
      [30] http://www.w3.org/2009/03/27-bpwg-minutes.html

MWABP - Canvas

    <jeffs>
    [31]http://www.it.rit.edu/~jxs/test/canvas/action910draft.html

      [31] http://www.it.rit.edu/~jxs/test/canvas/action910draft.html

    jeffs: it's a draft for content
    ... about when to use SVG or canvas and added a ref that you should
    use rich interfaces
    ... actually that there are variety of such interfaces available
    ... you don't need to draw buttons if all you need are buttons

    DKA: conversation yesterday was whether it is really a best
    practice, enough usage, enough reference material to recommend the
    use
    ... is it a forward looking BP rather than something based on
    existing practice

    jeffs: I wanted to include this because more and more full featured
    browsers in the mobile domain canvas is becoming much more tempting
    ... it is forward looking in that it is available, but not that much
    forward looking

    Jo: is there anything in canvas you cannot do with svg?

    jeffs: they are similar. the primary diff is that svg will give you
    a heavier dom and uses a compound doc like approach by the browser
    vendors
    ... canvas is easier. It is a blank slate you just draw on. It is
    lighter weight, for a developer and you don't have to learn a new
    language

    EdC: Is there are rec when to use svg or canvas?

    DKA: we don't really want to get into the debate but want to talk
    about using device capabilities

    adam: can you use canvas from the dom?

    Jo: Yes

    jeffs: no you cannot. You can change the height, but the content is
    not visible in the dom

    Jo: the problem with Javascipt is that browser consumes the content.
    What is important is that content is available.

    jeffs: that's when you want to use svg.

    Jo: so we should ban JS :-) other than for cool interaction effects

    Jo: now we are getting into personal opinion, not best practice

    jeffs: I think that is not true. I have pointed out concrete
    situations where it makes more sense to use svg or canvas and have
    tried to stay out of the debate

    EdC: But you have stayed at low level arguments in you text. I like
    what Jo said about content being discoverable
    ... so we should recommend svg and discourage canvas

    jeffs: if you want it to be discoveralbe then you need to use svg,
    but don't want to discourage canvas because it is so light weight

    SeanP: are there other categories where this fits into, as discussed
    yesterday? like conservative use of resources?

    jeffs: i missed that conversation. I guess it would fit into
    conservative use of resources. It is less intensive than doing dom
    manipulation
    ... canvas will be valuable for information display
    ... hard to teach in svg, but easy to do in canvas
    ... one could talk about it in terms of information display rather
    than dynamic graphics
    ... it makes sense to say that browsers are supporting this tag and
    we should tell people when to use it

    DKA: should we recast this as a cautionary notes on the use of
    dynamic graphic elements
    ... can discuss the pros and cons of svg and canvas

    jeffs: I would not object to that
    ... I would rather put this in positive terms, but we can do that

    DKA: doesn't have to be negative
    ... I have a problem saying use canvas

    adam: should be use the appropriate rendering api

    DKA: yes, that way we could tell people what exists

    jeffs: should we say use the appropriate rendering api or dynamic
    graphics

    Jo: we should say don't use canvas unless you can"t think of another
    way

    jeffs: canvas is about dynamic graphics.
    ... don't use it to draw user controls

    Jo: I think it would be good to say not to draw buttons
    ... lot"s to say how not to use it

    <francois> [32]Definition of the canvas element in HTML5

      [32] 
http://www.w3.org/TR/html5/the-canvas-element.html#the-canvas-element

    DKA: Isn't there something about drawn graphics which are useful if
    you don't know screen size

    jeffs: if you feel you must draw buttons

    DKA: perhaps we should encourage people to draw buttons because of
    scalability

    SeanP: hopefully the device will know how to draw buttons

    jeffs: we need to help people in situations were all three
    possibilities can be used
    ... I agree with Sean

    francois: I posted an extract from HTML5 about canvas
    ... [reading]...
    ... they are still discussiing. It is a draft
    ... for the time being it is not clear
    ... there is not much to discuss at the moment
    ... it is an api and could have it on top of svg perhaps
    ... you can mix and match and play with the output
    ... in the past with svg we had no bp to promote

    jeffs: that is an important point
    ... there is a temptation here if the developer doesn"t care if the
    content of canvas is not available
    ... svg is another hurdle and feels heavier

    DKA: is there are mobile specific angle that the html5 guys may not
    have thought of

    francois: it is about scalable vectors, scaling graphics, everything
    will adjust

    DKA: and it is lower size

    SeanP: we discussed the difference between various technologies in
    graphics. Can we say use this rather than that?

    Jo: what is mobile here?

    DKA: screen sizes, dynamically adjusting buttons
    ... in order to render that independent of screen size
    ... without having to make several images
    ... what can we say that is relevant to the mobile space?

    jeffs: sucking resources dry is mobile
    ... I think that dynamic graphics using svg will be much heavier and
    coder brain power, rather than using the drawing api of canvas

    Jo: you seem to be saying that developer efficiency is important
    compared to run time efficiency

    jeffs: Yes
    ... if it is dynamic then use it, not for static stuff

    DKA: I suggest jeffs comes up with a new articulation of the deep
    analysis we just had

    jeffs: I can do that. What is the focus?

    Jo: mobile specific aspects

    DKA: dealing with screen sizes and resolutions, efficency across the
    wire, but also rendering resources

    adam: I feel uncomfortable about making non backed up statements
    about resource consumption
    ... where are the threshholds?

    DKA: should we ask Dom to come up with something?

    adam: that would be useful

    <francois> [33]http://www.borismus.com/canvas-vs-svg-performance/

      [33] http://www.borismus.com/canvas-vs-svg-performance/

    <Zakim> Bryan, you wanted to ask what is the specific reason that
    SVG vs canvas is heavier in processing requirements - reliance on
    DOM in somw way?

    Bryan: could we document what the reasons are why canvas is lighter
    weight?
    ... isn't that similar to what we talked about yesterday regarding
    relying on the dom?

    jeffs: i thought the group had concluded that dom manipulation is
    resource heavy

    Bryan: that seems to be challanged by adam

    adam: we need values for this

    jeffs: francois article may be useful. There are some metrics

    adam: the document is not for mobile devices

    francois: it is an indication
    ... it is dependent on the size of what you draw

    jeffs: graphics that are redrawn a lot are better done in canvas
    ... I will see if I can get people to try some stuff out on various
    maschines

    DKA: perhaps Dom could be helpful with this

    francois: I fear we will end up with figures and no immediate
    conclusion

    Jo: I think it is to early for a BP

    DKA: I think we cannot say that now

    Jo: an analysis will help in showing that it is too early

    DKA: what could we say about exploiting device capabilities?

    <Jo> PROPOSED RESOLUTION: It's too early and too speculative for a
    BP on SVG Canvas etc.

    <francois> +1

    <DKA> -1

    <jeffs> -1

    jeffs: I don't agree

    +0

    <EdC> +1 too early as a best practice (should be based on
    substantiated experience).

    Jo: I don't know if you will find anything that will change the
    fundamental problem

    DKA: we need to see if there is a lot of use

    <Jo> PROPOSED RESOLUTION: It's too early and too speculative for a
    BP on SVG Canvas etc. plus there is not a specific enough mobile
    motivation for any such statement

    DKA: nobody has said what people are really doing with it
    ... if there are many then I don't agree

    <DKA> -1

    jeffs: I'd rather not spend energy on something that will not be
    useful
    ... in teaching i found that svg has a feeling of being heavy and
    canvas is not

    <rob> +1 unless there is specific mobile advice to give about vector
    graphics in general

    jeffs: as for what is in use that is speculation

    DKA: we need more info
    ... existing web apps that use svg or canvas
    ... who would want to find out which web apps, like apple's, are
    using svg or canvas?

    Jo: I think we are wasting time

    DKA: what if there are many?
    ... otherwise we are doing a good service to the readers

    jeffs: I think we should show people how to use this

    Jo: this has not been established as a BP

    DKA: I propose Jeff and I work on it
    ... let's close off discussion on this

    <Jo> ACTION: Dan and Jeffs to wander the highways and byways of SVG
    and Canvas and cook something up for the group's approval [recorded
    in [34]http://www.w3.org/2009/03/26-bpwg-minutes.html#action01]

    <trackbot> Created ACTION-924 - And Jeffs to wander the highways and
    byways of SVG and Canvas and cook something up for the group's
    approval [on Daniel Appelquist - due 2009-04-02].

    <DKA> 15 minute break

    <DKA> [35]http://en.wikipedia.org/wiki/WIPI

      [35] http://en.wikipedia.org/wiki/WIPI

CT - HTTPS Link Rewriting

    Dan: Let's pick a contentious issue to start with.
    ... We need to get to all this stuff today.

    Jo: Let's go with ACTION-902

    DKA: Where do we stand on this?

    Jo: There were 3 fundamental questions.
    ... 1. Link rewriting is a form of CT and subject to the same
    restrictions as other transformations

    Francois: The security problems are caused by the changing of the
    origin of the link, no necessarily the link rewriting itself. Adding
    links can also be a problem.

    DKA: I'm not sure how this helps us with the discussion.

    Francois: We need to be clear in the document that insertion of
    links also is like link rewriting.

    DKA: How about making our definition of link rewriting to include
    insertion of links.

    <Jo> PROPOSED RESOLUTION: IN the following and in all subsequent
    discussions Link Rewrioting is considered to include insertion of
    links that introduce the "ame domain" issue

    DKA: For positions where we have two different opposite viewpoints,
    maybe each person should take the other's sides.

    <Jo> PROPOSED RESOLUTION: In the following and in all subsequent
    discussions Link Rewriting is considered to include insertion of
    links and frame flattening and other techniques that introduce the
    "same domain" issue

    <Jo> > PROPOSED RESOLUTION: In the following and in all subsequent
    discussions Link Rewriting is considered to include insertion of
    links and frame flattening and other techniques that introduce the
    "same origin" issue

    Rob: What about flattening out the frameset, where you end up with
    several documents all placed into one document after CT?

    <rob> +1

    <francois> +1

    +1

    <Jo> +1

    <Kai> +1

    <DKA> +1

    <Bryan> +1

    <JonathanJ> +1

    RESOLUTION: In the following and in all subsequent discussions Link
    Rewriting is considered to include insertion of links and frame
    flattening and other techniques that introduce the "same origin"
    issue

    <Jo> PROPOSED RESOLUTION: Link rewriting is a form of transformation
    and at a minimum is subject to the same limitations as other forms
    of transformation described in this document

    <rob> +1

    <francois> +1

    +1

    <EdC> +1

    <DKA> +1

    RESOLUTION: Link rewriting is a form of transformation and at a
    minimum is subject to the same limitations as other forms of
    transformation described in this document

    <JonathanJ> +EOF

    Bryan: It might we worthwhile to note that it is an aspect of
    non-proxy operation. Link rewriting is unnecessary if the CT proxy
    is acting as a true proxy.

    Rob: You may need to rewrite URIs with frameset flattening,
    pagination, and javascript links.

    Bryan: True, but it is important to note that in proxy mode link
    rewriting is not always necessary, but for a non-proxy mode CT proxy
    it is always necessary.

    DKA: Can you make a resolution on this?

    <Jo> PROPOSED RESOLUTION: Proxies MAY rewrite links, where content
    transformation is permitted, providing that content domain origin
    distinctions are preserved by the proxy.

    Rob: Is the Google transformation engine out of scope.

    DKA: Can you explain this Jo?

    Francois: I though we agreed that this wouldn't work.

    Jo: There are two parallel threads here. 1. Is this required for
    hygene on the web? 2. Are the techniques available?

    Francois: Should we do the techniques first?

    Rob: There are two parallel threads and the answer to both is yes.

    <DKA> +1

    Jo: What we mean by this resolution is that content domain origin
    distinctions are preserved.

    Rob: Do we mean that content domain origin distinctions are kept
    between the CP and the CT proxy or the CT proxy and the handset?

    <Bryan> +1

    Rob: We are trying to preserve security; safety from cross-domain
    attacks.

    <Zakim> Bryan, you wanted to explain that we should give an example
    of how "domain origins distinctions can be preserved"

    <Jo> PROPOSED RESOLUTION: Proxies MAY rewrite links, where content
    transformation is permitted, providing that content domain origin
    distinctions are preserved by the proxy such that browsers accessing
    the proxy do not inappropriately misconstrue different content
    origins as being the same and inappropriately share cookies, or
    allow execution of scripts or do other things that cause security...

    <Jo> ...problems as a result of not knowing that different origins
    are involved

    Bryan: We should provide an example of how domain origins can be
    preserved. To me this isn't clear and needs to be shown.

    Jo: I agree. We need to show that there are techniques that it can
    be done and that it is testable.

    <francois> +1

    <Kai> +1

    <DKA> +1

    +1

    <rob> +1

    <Jo> +1

    <Bryan> +1

    <JonathanJ> +1

    <Jo> PROPOSED RESOLUTION: Proxies MAY rewrite links, where content
    transformation is permitted, providing that content domain origin
    distinctions are preserved by the proxy such that browsers accessing
    content via the proxy do not inappropriately misconstrue different
    content origins as being the same and inappropriately share cookies,
    or allow execution of scripts or do other things that cause...

    <Jo> ...security problems as a result of not knowing that different
    origins are involved

    <Jo> +1

    <EdC> +1

    <JonathanJ> +1

    <francois> +1

    <DKA> +1

    <rob> +1

    <Jo> +1

    +1

    RESOLUTION: Proxies MAY rewrite links, where content transformation
    is permitted, providing that content domain origin distinctions are
    preserved by the proxy such that browsers accessing content via the
    proxy do not inappropriately misconstrue different content origins
    as being the same and inappropriately share cookies, or allow
    execution of scripts or do other things that cause security problems
    as a result of not knowing that different origins are involved

    Jo: We need to show that there are testable techniques.

    Francois: I don't really understand the testable parts. Do we need
    to show the testable techniques in the guidelines.

    Jo: Since you own the conformance statement, you need to do it.

    Rob: The problems are in the DOM; needs to be testable in the DOM
    spec.

    Francois: There needs to be something testable in the proxy.

    Rob: Testable the same way as in a browser.

    Francois: What are the examples?

    <Bryan> Here is the proposed informative text "Link rewriting is
    always used by CT Proxies that are accessed as an origin server
    initially, e.g. which provide mobile-adapted web search and
    navigation to the web pages returned in the search results, or to
    which the browser is redirected through the CT Proxy for adaptation
    of a web page. Link rewriting *may* be used by CT Proxies acting as
    normal HTTP proxies (e.g. configured or transparent) for the
    browser, but may not b

    <Bryan> e required since all browser requests flow through the CT
    Proxy."

    Rob: Look up XXS.

    <francois> [36]Cross-origin resource sharing draft

      [36] http://www.w3.org/TR/2009/WD-cors-20090317

    Francois: There is some work to allow cross-origin resource sharing.
    ... based on HTTP header fields saying I allow access to the other
    origin.

    Jo: Isn't that easy to subvert.

    Francois: May be more involved than that.

    DKA: Let's not get into philosophical discussions.

    Francois: We need to provide some examples of how same origin can be
    preserved.

    Rob: One reason for rewriting URIs is that they get too long. Many
    handsets truncate URIs at 256 characters.

    Jo: Let's summarize the techniques that we have discussed today.
    ... differences in ports does not work.

    Rob: Not all ports are are open as well.

    Jo: Can't use subdomains.

    Francois: Having a star in the DNS record doesn't work as Bryan
    pointed out.

    Jo: Can't use URI decorating.

    Rob: So come back to how most CT proxies work, and that is use a
    single domain for which the rest of the web is available.

    Eduardo: If scripts are passed down to the handset then you could
    have a problem.

    Rob: But the scripts are executed on the CT proxy. This is where the
    guidelines come into play, which says that CT proxy needs to execute
    scripts and handle the cookies.

    Eduardo: How can we say that in the guidelines?

    Rob: We need to do some tests like with browsers, but on the proxy.

    Eduardo: Where do you do the tests?

    Rob: You do the tests on the origin server.

    Kai: Why are we worried about this. If some one wants to do this
    they won't care about this document.

    Rob: The tools are there already.

    <francois> [37]DOM conformance test suite

      [37] http://www.w3.org/DOM/Test/

    Francois: We can use the DOM conformance test suite.

    Jo: Which is the relevant specification for the tests?

    <DKA> +alan

    Bryan: I wanted to comment on something said by Rob about the CT
    proxy handling the cookies and scripts; I think this is true in
    non-proxy mode. However, we don't do this in proxy mode. We wouldn't
    want imply that a CT proxy always has to manage cookies.

    Rob: True, but if it is necessary to execute the scripts on the CT
    proxy, then for consistency the CT proxy needs to handle the
    cookies.

    Bryan: OK, but we want to be clear that just because the CT proxy
    handles cookies for some pages on the domain, it doesn't have to do
    it for all pages on the domain.l

    Rob: Yes, we just need to say that if a CT proxy handles the
    scripts, then it needs to handle the cookies.

    s/domain.1/domain/

    Francois: these tests don't cover the cookies.

    Rob: Yes, but there are tests that cover cookies.

    DKA: Can we reference these tests right now and look at them later?

    Jo: We need to look at them first.
    ... Let's take a resolution that since we don't think it is possible
    for the CT proxy to manipulate the URI, then we will say that the
    proxy has to maintain security pending that we find some tests that
    we can test the CT proxy with.

    Francois: What we are saying is that the CT proxy becomes a web
    browser and has to be tested like a web browser.
    ... I don't think that these tests cover security.

    Rob: Maybe the Opera guys have some security tests.

    <Jo> PROPOSED RESOLUTION: Since there doesn't appear to be a way in
    which the URI sent to the User Agent can be manipulated to preserve
    security it is permissible for a CT proxy to act on content in so
    that security is nonetheless preserved as adjudged by conformance
    tests that are to be researched. If no such security tests can be
    found then there cannot be conformance associated with link...

    <Jo> ...rewriting and it cannot be permissible for CT proxies to do
    so.

    <Jo> PROPOSED RESOLUTION: Since there doesn't appear to be a way in
    which the URI sent to the User Agent can be manipulated to preserve
    security related to same origin policies it is permissible for a CT
    proxy to act on content in so that security is nonetheless preserved
    as adjudged by conformance tests that are to be researched. If no
    such security tests can be found then there cannot be...

    <Jo> ...conformance associated with link rewriting and it cannot be
    permissible for CT proxies to do so.

    <DKA> +1

    Rob: Is it worth mentioning what tests were are looking
    for--JavaScript and cookies?

    <EdC> I would replace "to do so" with "to rewrite links in such a
    way that they do not preserve domain origin distinction" (other URL
    rewriting that preserve it being ok in principle).

    Rob: and DOM?

    <rob> +1

    <Bryan> +1

    Francois: What else could there be? I think just cookies and
    scripts.

    <francois> +1

    <Jo> +1

    <EdC> +1

    Francois: Just so I understand, if we can't find tests then we won't
    allow link rewriting.

    Jo: Yes.

    +1

    <Jo> +1

    <JonathanJ> +1

    RESOLUTION: Since there doesn't appear to be a way in which the URI
    sent to the User Agent can be manipulated to preserve security
    related to same origin policies it is permissible for a CT proxy to
    act on content in so that security is nonetheless preserved as
    adjudged by conformance tests that are to be researched. If no such
    security tests can be found then there cannot be conformance
    associated with link rewriting and it cannot be permissible for CT
    proxies to do so.

    Francois: Could be linked to HTML 5; they are the ones defining same
    origin.

    <Jo> ACTION: daoust to ascertain the availability of tests that
    ensure that same origin policy conformance, when implemented in this
    way, can be tested [recorded in
    [38]http://www.w3.org/2009/03/26-bpwg-minutes.html#action02]

    <trackbot> Created ACTION-925 - Ascertain the availability of tests
    that ensure that same origin policy conformance, when implemented in
    this way, can be tested [on François Daoust - due 2009-04-02].

    <francois> [FWIW, the following page seems to be pretty complete on
    same origin policy and security settings:
    [39]http://code.google.com/p/browsersec/wiki/Part2#Standard_browser_
    security_features ]

      [39] 
http://code.google.com/p/browsersec/wiki/Part2#Standard_browser_security_features

    DKA: Let's move on to the next resolution.

    <Jo> PROPOSED RESOLUTION: Interception of HTTPS is not permissible
    without consent from the user on a case by case basis

    Jo: We need to agree on what Case-by-case basis means.

    Bryan' text: Here is the proposed informative text "Link rewriting
    is always used by CT Proxies that are accessed as an origin server
    initially, e.g. which provide mobile-adapted web search and
    navigation to the web pages returned in the search results, or to
    which the browser is redirected through the CT Proxy for adaptation
    of a web page. Link rewriting *may* be used by CT Proxies acting...

    scribe: as normal HTTP proxies (e.g. configured or transparent) for
    the browser, but may not be required since all browser requests flow
    through the CT Proxy."

    Jo: Why don't include that as a note under link rewriting?

    Bryan: OK

    <Jo> PROPOSED RESOLUTION: Include text on the following lines as a
    note under a section on Link Rewriting: "Link rewriting is always
    used by CT Proxies that are accessed as an origin server initially,
    e.g. which provide mobile-adapted web search and navigation to the
    web pages returned in the search results, or to which the browser is
    redirected through the CT Proxy for adaptation of a web page....

    <Jo> ...Link rewriting *may* be used by CT Proxies acting as normal
    HTTP proxies (e.g. configured or transparent) for the browser, but
    may not be required since all browser requests flow through the CT
    Proxy."

    <EdC> +1

    <Bryan> +1

    <JonathanJ> +1

    +1

    <Jo> +1

    <rob> +1

    <DKA> +1

    <adam> +1

    Francois: I am at a bit of a loss on this resolution. The other
    resolution still stands, right.

    <francois> +1

    RESOLUTION: Include text on the following lines as a note under a
    section on Link Rewriting: "Link rewriting is always used by CT
    Proxies that are accessed as an origin server initially, e.g. which
    provide mobile-adapted web search and navigation to the web pages
    returned in the search results, or to which the browser is
    redirected through the CT Proxy for adaptation of a web page. Link
    rewriting *may* be used by CT Proxies acting as normal HTTP proxies
    (e.g. configured or transparent) for the browser, but may not be
    required since all browser requests flow through the CT Proxy."

    <Jo> PROPOSED RESOLUTION: Interception of HTTPS is not permissible
    without consent from the user on a case by case basis

    Jo: What does case-by-case basis mean?

    Jo: What we are trying to avoid with "case-by-case basis" is blanket
    preferences and also making the user do nonsensical things.

    <Jo> PROPOSED RESOLUTION: Interception of HTTPS is not permissible
    without explicit prior agreement from the Content Provider

    <Jo> [we need to solve the next Proposed resolution prior to the
    previous]

    Jo: Let's look at the next resolution because the case-by-case
    problem won't exist if we take the next resolution.

    DKA: If we are viewing the CT proxy as the browser, then this HTTPS
    resolution doesn't make sense.

    Francois: Earlier we decide that a CT proxy is a distributed
    browser.

    Bryan: On Jo's proposed resolution, are we only including
    resolutions that are testable? I don't think explicit prior
    agreement is testable.

    DKA: I don't think that it even makes sense. A bank is one thing,
    but what about other types of transactions?

    Jo: It is impossible to second-guess a CP's use of HTTPS. They want
    a secure transaction.

    DKA: I don't see that this is testable or scalable. I agree with
    Bryan.

    Jo: Then you would say that the resolution must be taken and can't
    use non-testable as a cop out.

    DKA: What do others think?

    Eduardo: As a CP, I have an expectation that there will be security.
    I'm going to break it, I'm not going to even tell you about.

    DKA: What about Opera Mini, SkyFire?

    Francois: There is tight integration between client and server.

    DKA: You should still hijack the Opera server.

    Rob: Could happen on Firefox as well.

    DKA: If you assume that all of the actors in the chain are well
    behaved, then what we are really talking about is malware somewhere
    in the chain.

    Kai: When HTTPS is used, it is carefully chosen. There is a
    performance loss. It is used when we mean it. It shouldn't be mucked
    with. There are serious legal concerns.

    DKA: We talked about Opera Mini.

    Jo: Out of scope of this document.

    DKA: There is the opportunity for malware even on a desktop browser.

    Jo: Are you saying that because there are opportunities for malware,
    why not introduce more?

    DKA: If you assume that the actors are benign, then what we are
    talking about malware.

    Jo: I don't agree. We are saying that the CP doesn't want anyone to
    listen in.

    Kai: Obtaining permission from the origin server means that the CT
    proxy goes out of scope.

    Francois: The only reason to allow HTTPS link rewriting is to allow
    good user experience.
    ... You are not honoring the spirit of HTTPS.

    DKA: So one reason not to allow HTTPS link rewriting would be
    because the user couldn't examine the certificate.
    ... You might not be able prevent phishing attacks.

    <Zakim> Bryan, you wanted to ask if this is testable and to point
    out dependency upon domain validation for downloaded or signed
    objects

    Rob: You could allow the user to see the real certificate through
    some UI.

    Bryan: You have the same trust issues as with the scripts and
    cookies and some domain stuff.
    ... I can be downloading content for use outside the browser and the
    trust might be broken because I downloaded it through the proxy.

    Rob: That comes back to the link-rewriting argument.

    Eduardo: There might be some cases where HTTPS could be used--on
    phones where the cert handling might be broken.

    DKA: I'm warming to requiring consent for HTTPS link rewriting; it's
    just web breaking.

    Rob: What about the long tail where there is HTTPS but no mobile
    site.

    DKA: How about giving a strongly worded warning to the user that
    their connection is not secure?

    Francois: Because it is not necessarily up just to the user.

    DKA: What about if I give someone my password? Then the CP is not
    necessarily talking to the real user.

    Rob: True. It is usually the user's responsibility to take on the
    risk.

    Francois: What about banks that don't allow CT proxies to intervene?

    DKA: Well, there is no reason that CT proxies couldn't be more
    restrictive that what we say.

    Kai: The CP is selecting HTTPS, and it shouldn't be changed.

    Rob: What the CP is saying is that I'm providing a secure connection
    to your PC, and it's the user's choice to have a distributed
    browser.

    Francois: There is no way for the CP to refuse the choice.

    Kai: no-transform?

    Francois: But it is already too late?

    Rob: The HTTPS request should have a via header that would not
    normally be there.

    <DKA> PROPOSED RESOLUTION: It's enough to get the user's consent (in
    response to a strongly worded warning) in order for proxies to
    transform https content.

    Francois: That is not enough.

    Eduardo: As a CP, I would not feel comfortable with this. Also, the
    legal framework could be a problem.

    DKA: We can't always say "don't do this if it is illegal"

    <DKA> PROPOSED RESOLUTION: Proxies must never transform https
    content unless a prior agreement has been reached with the specific
    origin server.

    <EdC> Change "I feel comfortable" with "I do not feel conformtable".

    <Zakim> Bryan, you wanted to state we should not require such a
    consent to be real-time or explicit

    Bryan: Getting user consent on a case-by-case basis will really bug
    users and they'll give up. If you are doing it often, it's going to
    break.
    ... We've had significant problems with HTTPS and the way it is used
    and prompting the user.

    Kai: I would second that. You might have to do it for every asset on
    the page.

    <DKA> PROPOSED RESOLUTION: It's enough to get the user's consent on
    https session set-up (in response to a strongly worded warning) in
    order for proxies to transform https content.

    Rob: The user can give their consent in real time. The HTTPS link
    stays up for a long time.

    <Bryan> for the minutes: "We've had significant problems with HTTPS"
    should be "We've seen significant issues with interrupting the
    normal flow of applications using HTTPS"

    DKA: You would have a strong warning that required consent. You
    might really need to get to your bank.

    Kai: Users try to avoid that popup. It happens when secure content
    is mixed with insecure content.
    ... What is more important that users know they are leaving a secure
    connection;.

    DKA: What is really important is that the user knows that the HTTPS
    connection is going through a CT proxy.

    Kai: Are user's going to understand the implications of this?

    DKA: If the user trusts Vodafone, then the user may want the HTTPS
    link through the CT proxy.

    Kai: What about some unknown company?

    DKA: Then the user can refuse.

    Rob: There is the long tail where there are websites that have been
    written long ago that provide HTTPS.

    <DKA> PROPOSED RESOLUTION: Proxies must never transform https
    content unless a prior agreement has been reached with the specific
    origin server.

    <inserted> scribenick: adam

    Rob: It's not a symetric agreement. The server knows nothing about
    the user's identity.

    francois: Technically, yes, but the impression is that it's
    symmetrical.

    DKA: We need to draw this to a close.

    Kai: I don't want anybody else to do anything with my https content.
    It's secured content.
    ... Supportive of the resolution.

    <SeanP> -1

    <rob> -1 because this is not scalable to even a thousand long-tail
    websites that may use HTTPS for log-in

    <Kai> +1

    <EdC> +1

    <Bryan> +1

    <Jo> +1

    <francois> +1 (because something's missing in the technology stack
    to enable that)

    Bryan: We're not saying anything about the verifiability of such
    agreement

    <Kai> of course, if there is an agreement it is out of scope of this
    document :-)

    Bryan: Unless there is some kind of agreement with both origin
    server and user, then you shouldn't transform. It doesn't have to be
    realtime or explicit though.

    DKA: Yes, but this resolution says: *never*.

    rob: This resolution is about the consent of the origin server. The
    consent of the user is separate resolution.

    DKA: Yes, but if we pass this resolution then we'll never encounter
    the other one in reality.
    ... This would mean that a lot of existing implementations are
    not-compliant.

    kai: Perhaps rightfully so.
    ... Can the intermediary be trusted not to do anything with the
    secured data?

    Rob: Assuming we don't pass this resolution because it's a "never",
    we may pass one that says "may" in which case it's the user's choice
    to trust the intermediary.

    <DKA> PROPOSED RESOLUTION: Proxies may transform https content in
    the cases where there is a pre-existing agreement between the proxy
    operator and the source or in the case where user consent has been
    given on a warning provided at the beginning of the https setup.

    <Jo> -1

    <francois> -1

    Rob: There's two sides to it. Does the CP agree? Does the user
    agree? But because with this resolution there's no way for the
    content providers to agree the user will never get a choice.

    <EdC> -1

    DKA: This is the opposite resolution.

    SeanP: So there will be a warning every time?

    <Bryan> -1 the user consent should be required no more often than
    once per browsing session, and should be able to apply to all sites
    accessed through the CT proxy in that session

    DKA: The warning will be each time the user starts a session.

    <Kai> -1 because an agreement between user and proxy operator may
    still hold the CP responsible, which is untenable

    <Jo> [two party consent is required and can't be achieved]

    DKA: Disagree with "CT proxy session" -- my decision to trust the CT
    depends on the sites I am interacting with.

    Kai: If the CP has decided his content needs to be secured, but this
    security is compromised by intermediary (because there is an
    agreement with the user) then the CP might still be held
    responsible.

    [ Discussion on whether a bank (for example) would be happy with
    this proposal ]

    DKA: We don't want to weaken the perceived security of mobile
    internet.

    Jo: May be pragmatic to transform https content without consent of
    CP, but can't be a BP.

    <DKA> PROPOSED RESOLUTION: We will remain silent on https content
    rewriting.

    <DKA> PROPOSED RESOLUTION: We will identify https transformation as
    a feature at risk - something you can remove from the document.

    Francois: Could mark it as a feature at risk, we may have to remove
    this recommendation if we can't implement it.

    <francois> [40]Definition of a feature at risk

      [40] 
http://www.w3.org/2005/10/Process-20051014/tr.html#at-risk-feature

    Jo: If we allow https transformation we leave CP with no way of
    saying: "I don't want this to happen."

    dka: Could we give the origin server a way to tell the origin server
    on set-up that I don't want you to transform https content.
    ... What happens on the handshake when the ct proxy establishes the
    connection with the origin server?

    Bryan: SSL handshake between CT Proxy and origin server.
    ... But the origin server has no way to know that this is coming
    from the proxy and not from a browser.

    Rob: You could put in a via header... But that's after the SSL is
    established.

    DKA: At that point (on seeing the first HTTP request on the SSL
    connection with a via) can return a 403 and close. And the CT Proxy
    knows that the origin server doesn't want to establish an SSL
    connection.

    Kai: So the via header is required.

    Jo: Yes.

    DKA: Is this the middle-way we want? The control is back on the
    server.

    Francois: But legacy content that doesn't know about this will
    quietly get opted-in.

    Jo: Two party consent is fundamental principle. But this isn't two
    party consent -- it's one party consent and one party ignorance.

    DKA: This doesn't break two party consent.

    Kai: The server has an opportunity to refuse because it sees the
    header.

    <EdC> 3 issues: (1) only opt-out for CP, no opt-in (silence ==
    accept https break). (2) We assume via header fields never get
    suppressed ior transit (3) We are implicitly specifying a protocol
    for https: first establish tsl/ssl session, then check http via -- I
    can already foresee the broadsides of the IETF.

    <DKA> PROPOSED RESOLUTION: We will remain silent on https content
    rewriting.

    Kai: Is the user protected from unwanted manipulation?

    DKA: None of this prevents bad proxies / malware.

    Kai: The goal we are trying to acheive is measure conformance to
    this document.

    DKA: There isn't much consensus. The weight of opinion is on
    explicitly disallowing https transformation.

    <DKA> PROPOSED RESOLUTION: Proxies must never transform https
    content unless a prior agreement has been reached with the specific
    origin server.

    Francois: We've already had significant feedback saying please don't
    allow HTTPS link re-writing.

    Rob: We could say that proxies may transform (subject to user
    consent) and mark it as a feature at risk.

    Jo: Feature at risk is only valid on the grounds of implementation
    experience -- if it turns out to be unviable.

    Rob: We shouldn't remain silent. We have things to say about user
    consent and should note that there is no way for the origin server
    to consent.

    DKA: That sounds like an informative statement. Remain silent means:
    No normative statement.

    Jo: I think it would look strange.

    <DKA> PROPOSED RESOLUTION: Proxies may transform https content in
    the cases where there is a pre-existing agreement between the proxy
    operator and the source or in the case where user consent has been
    given on a warning provided at the beginning of the https setup.

    EdC: Replace "or" with "and" and I agree.

    <Bryan> -1 we should not mandate the "at the begginning..."

    Bryan: Don't want to make statements about when consent is provided
    since it can have unforeseen effects.

    SeanP: Agree with Bryan, user experience might not be good.

    Rob: If we go with a resolution like this a number of resolutions on
    when consent is provided is likely to follow.

    <Bryan> I suggest "... or in the case where user consent has been
    given by prior agreement or in response to a warning provided by the
    CT Proxy"

    <Jo> PROPOSED RESOLUTION: Two party consent is required for HTTPS
    link rewriting

    <DKA> PROPOSED RESOLUTION: Proxies may transform https content in
    the cases where there is a pre-existing agreement between the proxy
    operator and the source or or in the case where user consent has
    been given by prior agreement or in response to a warning provided
    by the CT Proxy.

    <SeanP> +1 to the last one

    <EdC> -1 same issue: "and" instead of "or"

    <Kai> -1 it continues to leave the CP being responsible

    <Kai> +1 to Jo's proposal

    <rob> +1 if it is legally OK to have one-party consent

    <Jo> PROPOSED RESOLUTION: Per OPES two party consent is required for
    HTTPS link rewriting (by the content provider and the user)

    <Bryan> my core opinion on this is that HTTPS link rewriting will
    end up breaking sites and is a bad idea in general, but I would not
    want to restrict someone's ability to solve that challenge

    <DKA> PROPOSED RESOLUTION: Proxies must never transform https
    content unless a prior agreement has been reached with the specific
    origin server.

    <Bryan> +1

    <Kai> +1

    <Bryan> I want breakfast

    <SeanP> -1

    <francois> +1

    <EdC> +1

    <rob> -1

    <DKA> +0

    <Jo> +1

    0

    RESOLUTION: Proxies must never transform https content unless a
    prior agreement has been reached with the specific origin server.

    Note inserted after the meeting: the above resolution has been
    revised during the following day of the F2F after another discussion
    on OPES and two-party consent. See [41]the corresponding topic and
    resolution in the minutes of day 3.

      [41] http://www.w3.org/2009/03/27-bpwg-minutes.html#item01

    <JonathanJ> 0

    <achuter> +0

    Rob: This will give us trouble with reference implementations.

    <Jo> [adjourned]

    SeanP: from a practical sense, nearly every deployment Novarra's
    done has involved HTTPS rewriting
    ... and those that didn't it was asked for later

    DKA: this is a victim of dogma over common sense

    <Bryan> Sean, do the deployments act as a transparent or configured
    proxy?

    <SeanP> Both

Disclosure on Eduardo's presence to the F2F

    EdC: My presence here at this meeting is partly sponsored by dotMobi

    <EdC> All my thanks to dotMobi to allow me to participate in the F2F
    meeting.

CT - ISSUE-285 - Links rewriting

    Jo: I think we can close this

    DKA: do we need any further resolutions to close this?

    francois: we can link the action to the issue

CT - ISSUE-288 and ISSUE-284 - Non-normative list of mobile heuristics

    Jo: under sec 4.2.9 of the CTG draft we have the heuristics
    ... the resolution is a SHOULD take account of these heuristics. So
    they are no longer heuristics
    ... Is there a textual change to make here?

    francois: the examples are no longer examples but a list of things
    that unambiguously make a page mobile-aware

    <francois> [42]minutes on mandating heuristics

      [42] http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0066.html

    francois: and the other things in the appendix remain examples of
    heuristics that could also be taken into account of under
    undocumented circumstances

    Jo: ok, so I'll reword 4.2.9

    DKA: So we still have some non-mandatory heuristics

    francois: These could create confusion if people expect that
    following them will result in certain actions

    <Jo> ACTION: Jo to inser sections under proxy decision to transform
    a. to specify SHOULD NOT in the presence of the features listed at
    [43]http://www.w3.org/2009/03/10-bpwg-minutes.html and b. to include
    the current cullets listed as heuristics [recorded in
    [44]http://www.w3.org/2009/03/26-bpwg-minutes.html#action03]

      [43] http://www.w3.org/2009/03/10-bpwg-minutes.html

    <trackbot> Created ACTION-926 - Inser sections under proxy decision
    to transform a. to specify SHOULD NOT in the presence of the
    features listed at
    [45]http://www.w3.org/2009/03/10-bpwg-minutes.html and b. to include
    the current cullets listed as heuristics [on Jo Rabin - due
    2009-04-02].

      [45] http://www.w3.org/2009/03/10-bpwg-minutes.html

    francois: but it's just a probable
    ... and we've already seen in the past examples of "W3C said ..."
    quotes out of context

    <DKA> PROPOSED RESOLUTION: We delete all non-normative heuristics
    and close issue-288

    <DKA> PROPOSED RESOLUTION: We delete non-normative heuristics except
    for doctypes and close issue-288

    <DKA> PROPOSED RESOLUTION: We delete all non-normative heuristics
    and close issue-288.

    <francois> +1

    DKA: it's not our job to tell CT-proxy vendors how to do everything

    Jo: but a domain name of *.mobi is a very good indication we should
    keep

    francois: In theory it's not although in practice it is

    Jo: what about the TAG finding that URIs should be "meaningful"?

    francois: your point is valid as a good practice

    SeanP: the mandatory ones are SHOULD, can the rest be MAY?

    francois: different levels of SHOULD, MAY, might, could... are
    confusing

    Jo: I'll try to find this TAG advice

    <Jo> TAG FINDING: Good Practice: URIs intended for direct use by
    people should be easy to understand, and should be suggestive of the
    resource actually named.

    <Jo> --> [46]http://www.w3.org/2001/tag/doc/metaDataInURI-31.html
    TAG FINDING on Metadata in URIs

      [46] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html

    Rob: but the use of different User-Agents to view content isn't
    always relevant to the direct-use-URI

    <Jo> PROPOSED RESOLUTION: Add .mobi to the list of mandatory
    heuristics as it is a stronger indication of mobile intent than many
    of the content-types and DOCTYPEs already agreed

    francois: is there a reference (eg .mobi charter) we can use?

    <Jo> PROPOSED RESOLUTION: Add .mobi to the list of mandatory
    heuristics as it is a stronger indication of mobile intent than many
    of the content-types and DOCTYPEs already agreed - other URI
    patterns are more ambiguous as to their intent

    <Bryan> oops - need a new bridge code?

    Kai: are there dotmobi constraints that guarantee this?

    Jo: Yes, there are compliance rules with the company dotmobi to take
    out a *.mobi domain name

    +1

    <DKA> +1

    <achuter1> +1

    <EdC> +1

    <Jo> [am conflicted so 0]

    <JonathanJ> +1

    <Bryan> +1

    <Kai> 0

    <francois> 0 (note there could be a vendor-neutrality problem on top
    of the Web arch possible push-back)

    RESOLUTION: Add .mobi to the list of mandatory heuristics as it is a
    stronger indication of mobile intent than many of the content-types
    and DOCTYPEs already agreed - other URI patterns are more ambiguous
    as to their intent

    <SeanP> 0

    <Bryan> what about "m.domain" type hostnames?

    francois: I think we shouldn't even mention the rest that are not
    SHOULDs

    EdC: but combinations such as application/xhtml+xml AND
    [47]http://m.* will actually be good practice

      [47] http://m.*/

    francois: but it doesn't give the content-provider any guarantees

    EdC: they are ambiguous but they are in use

    SeanP: I don't see a big problem leaving them in a non-normative
    appendix

    jo: are we abandoning the list in 4.2.9?

    francois: apart from the agreed SHOULD parts, yes

    <Bryan> Which version is 4.2.9 in? Can someone past a URI to the
    draft?

    francois: the rest either delete or move to an appendix

    jo: even the mobileOK Basic confomance mark?

    <DKA> PROPOSED RESOLUTION: close issue-288 and move on.

    Rob: it's a feature-at-risk because there is currently no standard
    machine-readable trustmark

    <Bryan> Can we say which bullets in "Examples of heuristics:" (in
    4.2.8 in 081107) are being removed?

    <DKA> PROPOSED RESOLUTION: We delete all non-normative heuristics
    and close issue-288.

    <Bryan> Which ones are "non-normative"?

    <francois>
    [48]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-draf
    ts/Guidelines/090313#sec-proxy-decision-to-transform

      [48] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090313#sec-proxy-decision-to-transform

    <francois> +1

    Jo: ok, let's just remove the non-mandatory items

    <SeanP> 0

    0

    EdC: even remove the line "the user-agent has features ... to allow
    it to present the content"?

    francois: yes because User-Agent was considered at the HTTP Request
    stage

    jo: but it could also be considered in conjunction with the content
    of the response

    <Jo> -->
    [49]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-draf
    ts/Guidelines/090313 Current Draft

      [49] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090313

    francois: but that is difficult to test
    ... eg the user-agent can render tables but it may be so wide as to
    be unviewable

    Rob: as Kai points out there's definitely no best-practice here

    <DKA> PROPOSED RESOLUTION: We delete all non-normative heuristics
    and close issue-288.

    <francois> +1

    <Jo> +1

    <DKA> +1

    0

    RESOLUTION: We delete all non-normative heuristics and close
    issue-288

    <DKA> CLOSE ISSUE-288

    <trackbot> ISSUE-288 Should the Content Transformation Guidelines
    include a non normative list of non-mandated mobile heuristics?
    closed

    <DKA> PROPOSED RESOLUTION: Close Issue-284

    <DKA> +1

    +1

    <francois> +1

    <EdC> +1

    <DKA> CLOSE ISSUE-284

    <trackbot> ISSUE-284 W3C mobile addressing standards closed

    RESOLUTION: Close Issue-284

CT - ISSUE-289 - Are X-Device-* HTTP Header fields needed?

    [50]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/open

      [50] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/open

    DKA: haven't we already talked about "content selection" which isn't
    "content transformation" but is about selecting suitable content for
    the user's situation

    francois: then you're already mobile-friendly enough that the
    CT-proxy has nothing to adapt

    DKA: what if there is something that needs adapting?

    EdC: like what?

    SeanP: there are cases where altered headers might be sent first,
    then what?

    francois: Then the Vary: User-Agent header can be used to indicate
    there was alternate content available

    <achuter1> scribenick: achuter1

    <DKA> ScribeNick: achuter1

    <DKA> Scribe: Alan

    Fran�ois: Headers can be interpreted only on basis of prior
    experience

    Fran�ois: Often no way to get original UA header.

    Jo: Knowing that there is a mobile present, user requests desktop
    version

    EdC: We need the x-device header

    <Jo> PROPOSED RESOLUTION: Leave X-Device headers in as they add
    value

    EdC: then the provider can know what the requester really is.

    <francois> -1

    <Jo> PROPOSED RESOLUTION: Leave X-Device headers in as they add
    value and close ISSUE-289

    <SeanP> +1

    <francois> -1

    Fran�ois: I would like to take them out

    <rob> 0

    <EdC> +1

    <DKA> +1

    <Jo> [francois explains that his -1 is a formal objection and is not
    to be taken seriously]

    RESOLUTION: Leave X-Device headers in as they add value and close
    ISSUE-289

    <DKA> CLOSE Issue-289

    <trackbot> ISSUE-289 Should CT proxies send X-Device-* headers after
    having determined the content is not mobile-optimized? closed

CT - Miscellaneous actions

    <DKA> ACTION-830?

    <trackbot> ACTION-830 -- Bryan Sullivan to review correspondence
    with Dennis cf LC-2065 and to draft a) proposed changes to the
    document and b) a proposed response to Dennis -- due 2008-09-09 --
    OPEN

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

      [51] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/830

    <francois> [I think the real problem to solve is the availability of
    the original HTTP request, and that, once this is solved, there is
    no strong use case to have the origin HTTP header fields along with
    altered ones.]

    Bryan: would be provided by implementation

    <SeanP>
    [52]http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidel
    ines-20080801/2065?cid=2065

      [52] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2065?cid=2065

    dan: How to respond to LC 2065

    Bryan: had resolution that was partial agreement with this.

    Dan: LC 2065 says that CT proxy must allow user possibility of
    obtaining transformed version, but our document gives a should not a
    MUST.
    ... LC 2065 secxond point in list says CT proxies must allow users
    possibility to turn off transformation.

    <Jo> CLOSE ACTION-830

    <trackbot> ACTION-830 Review correspondence with Dennis cf LC-2065
    and to draft a) proposed changes to the document and b) a proposed
    response to Dennis closed

    <DKA> PROPOSED RESOLUTION: Regarding LC-2065 write back to Dennis
    that we agree and we think sections 4.2.2 and 4.2.9 of current draft
    (1q) accomodate this.

    <DKA> +1

    <EdC> +1

    <DKA> RESOLUTION: Regarding LC-2065 write back to Dennis that we
    agree and we think sections 4.2.2 and 4.2.9 of current draft (1q)
    accomodate this.

    <Bryan> Section "4.2.9.1 Alteration of Response" says "If a proxy
    alters the response then: ... It should indicate to the user that
    the content has been transformed for mobile presentation and provide
    an option to view the original, unmodified content.". This meets the
    intent but not the requirement level as requested.

    <DKA> ACTION-850?

    <trackbot> ACTION-850 -- Bryan Sullivan to provide some text on
    whitelists to see if we can include them somehow and come to an
    agreement re. LC-2003 -- due 2008-09-29 -- OPEN

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

      [53] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/850

    Jo: About Action 850

    <DKA> LC-2003?

    <Jo> --> [54]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/850
    ACTION-850

      [54] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/850

    Bryan: do we really need to say anything about whitelists?

    <DKA> CLOSE ACTION-850

    <trackbot> ACTION-850 Provide some text on whitelists to see if we
    can include them somehow and come to an agreement re. LC-2003 closed

    Jo: Action was attempt to reintroduce it.

    <francois> ACTION-858?

    <trackbot> ACTION-858 -- Sean Patterson to find out if novarra has
    figures on whether users choose to proceed at the HTTPS interstitial
    page -- due 2008-10-13 -- OPEN

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

      [55] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/858

    <DKA> CLOSE ACTION-858

    <trackbot> ACTION-858 Find out if novarra has figures on whether
    users choose to proceed at the HTTPS interstitial page closed

    <DKA> ACTION-867?

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

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

      [56] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/867

    <DKA> CLOSE ACTION-867

    <trackbot> ACTION-867 Look into an appendix with relevant normative
    statements of RFC2616 and report back to the group. closed

    <DKA> ACTION-886?

    <trackbot> ACTION-886 -- Jo Rabin to propose beefed up text on
    heuristics in respect of practice vs good practice -- due 2008-12-02
    -- OPEN

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

      [57] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/886

    <DKA> CLOSE ACTION-886?

    <DKA> CLOSE ACTION-886

    <trackbot> ACTION-886 Propose beefed up text on heuristics in
    respect of practice vs good practice closed

    <DKA> ACTION-887

    <DKA> ACTION-887?

    <trackbot> ACTION-887 -- Jo Rabin to put a reference somewhere to
    the Best Practice about exploiting device capabilities -- due
    2008-12-02 -- OPEN

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

      [58] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/887

    <DKA> CLOSE ACTION-887

    <trackbot> ACTION-887 Put a reference somewhere to the Best Practice
    about exploiting device capabilities closed

    <DKA> ACTION-889?

    <trackbot> ACTION-889 -- Jo Rabin to take the editorial comments in
    [59]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.
    html into account for next version of the draft -- due 2008-12-09 --
    PENDINGREVIEW

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

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

      [60] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/889

    <francois> [relevant section removed for ACTION-887]

    [Eduardo's comments]

    Jo: changed "header fields" to "value of header fields"
    ... Will preface the first sentence in 4.1.5

    <Jo> ACTION: Jo tpo preface the first sentence in 4.1.5 with Aside
    from the usual procedures defined in [RFC 2616 HTTP] [recorded in
    [61]http://www.w3.org/2009/03/26-bpwg-minutes.html#action04]

    <trackbot> Created ACTION-927 - Tpo preface the first sentence in
    4.1.5 with Aside from the usual procedures defined in [RFC 2616
    HTTP] [on Jo Rabin - due 2009-04-02].

    <DKA> PROPOSED RESOLUTION: Accept Jo's editorial changes detailed in
    email 13-March-2009 and close ACTION-927

    <DKA> PROPOSED RESOLUTION: Accept Jo's editorial changes detailed in
    email 13-March-2009 and close ACTION-889

    Jo: All Eduardo's comments dealt with.

    RESOLUTION: Accept Jo's editorial changes detailed in email

    <DKA> CLOSE ACTION-889

    <trackbot> ACTION-889 Take the editorial comments in
    [62]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.
    html into account for next version of the draft closed

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

    <DKA> ACTION-892?

    <trackbot> ACTION-892 -- François Daoust to prepare an ICS with
    MUST/MUST NOT (to view if that's a good idea), try to add a "depends
    on" column, explain "Not applicable" or remove it. -- due 2008-12-09
    -- OPEN

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

      [63] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/892

    <DKA> ACTION-893?

    <trackbot> ACTION-893 -- Robert Finean to start putting together a
    set of guidelines that could help address the security issues
    triggered by links rewriting. -- due 2008-12-23 -- OPEN

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

      [64] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/893

    <Bryan> Here is my proposed response to 850 (sorry about the line
    breaks): Re "1. Content transformation proxies...": Section "4.2.9.1
    Alteration of Response" says "If a proxy alters the response then:
    ... It should indicate to the user that the content has been
    transformed for mobile presentation and provide an option to view
    the original, unmodified content." Re "2. Content transformation
    proxies...": this will be addressed by adding text to "4.1.5.3 User
    Selection of

    <Bryan> Restructured Experience": "Proxies SHOULD provide users with
    the option to enable or disable content transformation, as a
    preference to be applied until changed." These changes meet the
    intent but not the requirement level as requested. The reason for
    the requirement leve difference is that not all CT Proxies may be
    capable of retaining user preferences.

    <DKA> ACTION-850?

    <trackbot> ACTION-850 -- Bryan Sullivan to provide some text on
    whitelists to see if we can include them somehow and come to an
    agreement re. LC-2003 -- due 2008-09-29 -- CLOSED

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

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

    <DKA> ACTION-893?

    <trackbot> ACTION-893 -- Robert Finean to start putting together a
    set of guidelines that could help address the security issues
    triggered by links rewriting. -- due 2008-12-23 -- OPEN

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

      [66] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/893

    Rob: Was about man-in-the-middle security

    Jo: Can't have a BP that requires a security audit.

    <DKA> CLOSE ACTION-893

    <trackbot> ACTION-893 Start putting together a set of guidelines
    that could help address the security issues triggered by links
    rewriting. closed

    Jo: Now a moot point after the link rewriting resolution.

    [break now]

    <DKA> [resuming]

    <francois> Scribe: Kai

    <DKA> ACTION-896?

    <trackbot> ACTION-896 -- François Daoust to stimulate discussion on
    the SHOULD NOT question ref mobile heuristics -- due 2009-01-20 --
    PENDINGREVIEW

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

      [67] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/896

    <DKA> CLOSE ACTION-896

    <trackbot> ACTION-896 Stimulate discussion on the SHOULD NOT
    question ref mobile heuristics closed

    <DKA> ACTION-900?

    <trackbot> ACTION-900 -- Jo Rabin to raise issues on inconclusive CT
    threads once the new draft of CT is prepared -- due 2009-01-27 --
    PENDINGREVIEW

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

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

    <DKA> ACTION-901?

    <trackbot> ACTION-901 -- Sean Patterson to raise issue the thread he
    started on transforming mobile content entitled \"RE: [minutes] CT
    Call 6 january 2009\" -- due 2009-01-27 -- OPEN

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

      [69] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/901

    SeanP: I think it is done

    <francois> [70]http://www.w3.org/2009/01/20-bpwg-minutes.html#item04

      [70] http://www.w3.org/2009/01/20-bpwg-minutes.html#item04

    <DKA> CLOSE ACTION-901

    <trackbot> ACTION-901 Raise issue the thread he started on
    transforming mobile content entitled \"RE: [minutes] CT Call 6
    january 2009\" closed

    <DKA> ACTION-902

    <DKA> ACTION-902?

    <trackbot> ACTION-902 -- Jo Rabin to summarise current discussions
    on https link re writing -- due 2009-01-27 -- PENDINGREVIEW

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

      [71] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/902

    <DKA> CLOSE ACTION-902

    <trackbot> ACTION-902 Summarise current discussions on https link re
    writing closed

CT - ACTION-912 - X-Device-* HTTP Header fields registration

    <DKA> ACTION-912?

    <trackbot> ACTION-912 -- Eduardo Casais to suggest some new wording
    on X-Device-* HTTP header fields keeping the normative meaning but
    noting that we're working with IETF and may deprecate this in the
    future -- due 2009-03-10 -- PENDINGREVIEW

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

      [72] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/912

    <EdC>
    [73]http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0058.htm
    l

      [73] http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0058.html

    EdC: this has not been resolved on a call

    Jo: I have added some text to EdC proposed text

    <Zakim> francois, you wanted to report on discussion with IETF

    Jo: do you, EdC, have a problem with my text

    EdC: no

    francois: i was asked to join a liaison call with IETF
    ... the point was not to talk about it being a good or bad idea, but
    how to register such a header field, when it has already been
    implemented.
    ... it can be grandfathered in. It is too late and we don't want to
    add more confusion we can choose the most recent deployed one and it
    should be accepted by IETF
    ... we need solid use cases. On the naming we can move forward with
    the X- prefix

    <DKA> PROPOSED RESOLUTION: adopt the text as proposed bt Eduardo and
    modified by Jo regarding X- prefix.

    <DKA> PROPOSED RESOLUTION: adopt the text as proposed bt Eduardo and
    modified by Jo regarding X- prefix and close ACTION-912

    francois: in the guidelines we will have a normative statement to
    use headers which we will not register. I think that will be hard to
    move forward.

    Jo: what is the problem here?

    francois: the header fields need to be registered in the IANA DB
    ... if we will have an objection we will have to convince them we
    need them

    Jo: is that really necessary?

    francois: there are two levels of registration. One is simple and
    does not require support by the IETF

    EdC: there will be discussion

    francois: they should appear in some list and moving them to the
    repository will then be harder

    Jo:

    francois: we already recevied comments that this should not be in a
    W3C draft
    ... we should action somebody to register this on the temporary
    registry
    ... to envoke grandfathering we need to find out how uses these
    header fields

    rob: I think we can use them. It is default, but in practice they
    don't

    Jo: can we ask francois to do this, knowing that we may run out of
    time to finish this

    francois: I am not sure I agree. We cannot really move forward on
    something that is not fully defined
    ... if we use it we must define it

    EdC: you ask to go through a process that make them deprecated and
    then have them removed

    francois: IETF and W3C work closely together and they have already
    said this is not our task so if we don't go through the process we
    will just get the same answer

    <DKA> PROPOSED RESOLUTION: adopt the text as proposed bt Eduardo and
    modified by Jo regarding X- prefix, we will register the header with
    IETF and close ACTION-912

    EdC: there are some fields that have been temporary for a long time

    SeanP: they also recommed X-forwarded

    francois: it is related to proxy in general
    ... it has nothing to do with transformation

    DKA: look at the proposal please

    SeanP: what is difference between edc and jo's text/

    EdC: Jo said we may or may not committ...

    <EdC> +1

    <rob> +1

    <francois> 0

    <DKA> +1

    <DKA> +2

    <SeanP> +1

    RESOLUTION: adopt the text as proposed bt Eduardo and modified by Jo
    regarding X- prefix, we will register the header with IETF and close
    ACTION-912

    <Jo> ACTION: daoust to progress registration of the X- headers
    irrespective his personal distate for the subject [recorded in
    [74]http://www.w3.org/2009/03/26-bpwg-minutes.html#action05]

    <trackbot> Created ACTION-928 - Progress registration of the X-
    headers irrespective his personal distate for the subject [on
    François Daoust - due 2009-04-02].

    <DKA> ACTION-925?

    <trackbot> ACTION-925 -- François Daoust to ascertain the
    availability of tests that ensure that same origin policy
    conformance, when implemented in this way, can be tested -- due
    2009-04-02 -- OPEN

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

      [75] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/925

    <DKA> CLOSE ACTION-912

    <trackbot> ACTION-912 Suggest some new wording on X-Device-* HTTP
    header fields keeping the normative meaning but noting that we're
    working with IETF and may deprecate this in the future closed

    francois: so far I found out that no two browsers behave the same
    ... what you can do with a client script depends on the browser

CT - Abstract improvement

    Jo: Matt points out the abstract is wrong and incomprehensible

    Jo: Matt points out the abstract is wrong and incomprehensible
    ... we were told not to tell transforming proxy providers how to do
    their work

    DKA: there could be informative guidance
    ... somebody want to write a good abstract?

    EdC: I'll do it
    ... with the gist of what is here and that it provides informative
    guidance

    Jo: leave out the informative

    <DKA> ACTION Eduardo to write an abstract for CT.

    <trackbot> Created ACTION-929 - Write an abstract for CT. [on
    Eduardo Casais - due 2009-04-02].

    Jo: we'll leave that with Eduardo
    ... next point is not completely implemented resolutions
    ... [going into LCs]

CT - LC-2050 - restructuring, recoding, optimization

    [76]LC-2050

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

    Jo: we wanted to change something in the scope section
    ... do we need to maintain these definitions? We did not define
    these concepts very formally because they are used lightly.
    ... making the distinction is good

    [we are talking about 2.2]

    jo: i thought the mandatory heuristics mean that a no tranform is
    implied
    ... but it is not

    <Jo> PROPOSED RESOLUTION: Ref LC-2050 RESOLVE NO to expanidng the
    definitions and leave defininitons in place

    <rob> +1

    <SeanP> +1

    RESOLUTION: Ref LC-2050 RESOLVE NO to expanidng the definitions and
    leave defininitons in place

CT - LC-2023 - charsets

    [77]LC-2023

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

    Jo: i put in a note here [reading note]
    ... rather than what I was mandated to do
    ... resolution was already taken

CT - LC-2084 - Vary HTTP header

    [78]LC-2084

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

    Jo: Resolution was taken

    francois: I did provide this and can reprovide
    ... Jo has already reinserted it
    ... it was on receiving http headers

    Jo: so no further action required

CT - LC-2047 - inter-proxy communication

    [79]LC-2047

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

    [viewing the LC]

    Jo: what did we resolve?

    [viewing]

    Jo: is this clear without a diagram?
    ... if I add one will it help?
    ... perhaps we should scrap the idea

    EdC: is there a text on what it is called?

    Jo: yes there is

    [viewing]

    1.3 Scope

    Jo: [mumbles into his non existing beard as he reads the section
    ... no action]

CT - LC-2053 - preventing transformation of mobile Web pages

    [80]LC-2053

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

    DKA: we clarified that yesterday

    EdC: it seems closely linked ot hte normative heuristic

    Jo: lets close it

CT - LC-2040 - 4.1.5.5 defines a protocol

    [81]LC-2040

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

    Jo: LC-2040 done

    DKA: should we send a note to the commenter?

    francois: by the time we send the response we will be done

CT - LC-2044 - Web browsers identification

    [82]LC-2044

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

    Jo is mumbling again

    [viewing]

    DKA: we do this

    EdC: section 4.1.3 is completely different

    francois: we discussed this in Mandeljeu
    ... we removed the normative part on detecting http browser request
    ... we are now talking about it in a normative way

    Jo: the resolution then seems to have changed
    ... all done

CT - OPES reference

    Jo: I put some wording in
    ... we need to review
    ... we were asked to note that we refer to IAB, about two party
    consent
    ... which we did
    ... is not really dangling then

CT - Rotan's point

    Jo: about the CT Doc missing a statement about role of main parties
    ...etc.

    Jo: we used to say in the doc in previous version that the
    principles operate similar to CSS
    ... in that the user can override

    SeanP: I found the statement
    ... it was in June

    <francois> [83]CT former draft with control

      [83] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080606#sec-proxy-control

    [viewing coupled with mumbling]

    Jo: I thought we had something about CSS

    <SeanP>
    [84]http://www.w3.org/TR/2008/WD-ct-guidelines-20080414/#sec-control
    -conflicts

      [84] 
http://www.w3.org/TR/2008/WD-ct-guidelines-20080414/#sec-control-conflicts

    Jo: if nobody thinks it's useful lets move on

    DKA: I think it would be useful in the intro
    ... especially with regard to respect to each others choices

    <Jo> ACTION: Jo to write something in the introduction about respect
    for CP prefgernces, respect for user preferences and the CP's
    ultimate sanction on the degree of preference they are willing to
    accommodate [recorded in
    [85]http://www.w3.org/2009/03/26-bpwg-minutes.html#action06]

    <trackbot> Created ACTION-930 - Write something in the introduction
    about respect for CP prefgernces, respect for user preferences and
    the CP's ultimate sanction on the degree of preference they are
    willing to accommodate [on Jo Rabin - due 2009-04-02].

    jo: done with this then

CT - Editorial notes

    Jo: we have done some, just making sure...

    4.1.5

    Jo: goes back a long way....
    ... it is more likely that the accept header will cause heuristic
    responses
    ... if we can say that alteration of the UA Header field doesn't
    achieve anything then we can leave it

    rob: it is hard to prove. Will be in the long tail.

    Jo: if the web site adapts in response to the UA header then we
    should not do anything with it. It is a user preference

    rob: during the browser wars this became common place and they are
    still there in the long tail
    ... it is not in mobile adapted pages

    francois: is this just for 406 error code?

    jo: if we say you can ignore 406 then what other mechanism do we
    offer CPs?
    ... what we are doing is being helpful in saying that a site needs a
    browser revision
    ... we may make it difficult for them
    ... for example for security reasons a CP may not want to serve
    content
    ... if with a 406 you rewrite the header, what can the CP do?

    DKA: so legitimate uses of 406...

    francois: a bit different from the note here

    SeanP: this sounds theoretical

    EdC: I have done this...and with a bank
    ... they did not want to take liability with anything else

    francois: is one way out to not allow to change the UA ?

    Jo: I don't think it works

    DKA: can we say don't pay attention to 406?

    Jo: if the CP does not want to serve content to a particular device,
    proxy etc. what do we anticipate them to do to signal that

    DKA: ideally send a 406, in reality an errorpage with 200 code
    ... it is up to the provider or CT proxy provider

    rob: in a case where they really don't want to, won't they send a
    403?

    Jo: we must be careful not remove choices for CPs
    ... so we should put a note on using 403 in there

    <Jo> ACTION: Jo to insert informative text in the relevant aqppendix
    describing the use of 403 in declining to server content because of
    security concerns or whatever [recorded in
    [86]http://www.w3.org/2009/03/26-bpwg-minutes.html#action07]

    <trackbot> Created ACTION-931 - Insert informative text in the
    relevant aqppendix describing the use of 403 in declining to server
    content because of security concerns or whatever [on Jo Rabin - due
    2009-04-02].

    <Jo> ACTION: Jo to specify what he means by the USer Agent editorial
    note under 4.1.5 [recorded in
    [87]http://www.w3.org/2009/03/26-bpwg-minutes.html#action08]

    <trackbot> Created ACTION-932 - Specify what he means by the USer
    Agent editorial note under 4.1.5 [on Jo Rabin - due 2009-04-02].

    Jo: 4.1.6.1

    about the via header

    francois: it just shows that there is a CT proxy active

    Jo: ok

    4.2.9

    no it is 4.2.7

    Jo: need to do some reorganizing here

    4.2.8

    Jo: do we also mean other legacy WML content?

    francois: in the rest we don't talk about other types, but yes do
    mean it

    EdC: you can only determine the type, but you can't look in it

    Jo: remain silent on it then

    5.0

    seungyun: this section is fine for me (had a question regarding an
    older version(

    Jo: if I am a CP and somebody has a problem with my content I want
    to find out if they have a problem with my proxy

    SeanP: operatos will deploy this...will they want to make it
    available for anybody

    Kai: CPs will not leave this open to the public

    seungyun: is transformed content still mobileOK?
    ... it should be aligned with mobileOK

    Jo: we have touched upon this and then stepped back from it.
    Difficult to say something meaningful

    seungyun: how do we test then?

    Jo: we have a conformance claim against this document and the other
    if you do transform you produce mobileOK content. It would not be
    good to limit this by combining them.

    francois: can you think of a wording to solve this?

    Jo: no

    SeanP: You can put in something like "reasonable"

    <Jo> ACTION: Jo to propose text for section 5 referring to
    "reasonable terms, timeliness, of access and so on, relating to the
    use cases of bug determinations, testing and so on [recorded in
    [88]http://www.w3.org/2009/03/26-bpwg-minutes.html#action09]

    <trackbot> Created ACTION-933 - Propose text for section 5 referring
    to \"reasonable terms, timeliness, of access and so on, relating to
    the use cases of bug determinations, testing and so on [on Jo Rabin
    - due 2009-04-02].

    I think this section already expresses openness

    <Jo> [reasonable and non-discriminatory]

    [discussion this needing something to prevent unreasonable
    hindrances to fulfillment]

    Section E

    no, D 1.3.2

    Jo: this is about thematic consistency
    ... bottom line we have a muddle. We need to ask TAG how to apply
    this or is the following correct...asking them to clear up the
    muddle.

    <Jo> ACTION: Jo to try to draft another doc to the TAG about D.1.3.2
    [recorded in
    [89]http://www.w3.org/2009/03/26-bpwg-minutes.html#action10]

    <trackbot> Created ACTION-934 - Try to draft another doc to the TAG
    about D.1.3.2 [on Jo Rabin - due 2009-04-02].

    Jo: that's it

CT - OPES and two-party consent

    rob: I have one more question. Can"t find the reference in OPES
    about two party consent

    francois: OPES states that we should aim at two party consent but
    one party consent is enough
    ... there are other guidelines, from which Jo infered, that state
    two party consent is needed

    <francois>
    [90]http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0052.htm
    l

      [90] http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0052.html

    Jo: where to go with this?

    EdC: we already did take a resolution on it

    rob: the dialog around it mentions two party consent

    Jo: I believe as we say later on that one party consent is not
    enough. so what do they mean by "by itself"?

    EdC: does only what opes says has value?

    Jo: we can say more but should not contradict it

Summary of Action Items

    [NEW] ACTION: Dan and Jeffs to wander the highways and byways of SVG
    and Canvas and cook something up for the group's approval [recorded
    in [91]http://www.w3.org/2009/03/26-bpwg-minutes.html#action01]
    [NEW] ACTION: daoust to ascertain the availability of tests that
    ensure that same origin policy conformance, when implemented in this
    way, can be tested [recorded in
    [92]http://www.w3.org/2009/03/26-bpwg-minutes.html#action02]
    [NEW] ACTION: daoust to progress registration of the X- headers
    irrespective his personal distate for the subject [recorded in
    [93]http://www.w3.org/2009/03/26-bpwg-minutes.html#action05]
    [NEW] ACTION: Jo to inser sections under proxy decision to transform
    a. to specify SHOULD NOT in the presence of the features listed at
    [94]http://www.w3.org/2009/03/10-bpwg-minutes.html and b. to include
    the current cullets listed as heuristics [recorded in
    [95]http://www.w3.org/2009/03/26-bpwg-minutes.html#action03]
    [NEW] ACTION: Jo to insert informative text in the relevant
    aqppendix describing the use of 403 in declining to server content
    because of security concerns or whatever [recorded in
    [96]http://www.w3.org/2009/03/26-bpwg-minutes.html#action07]
    [NEW] ACTION: Jo to propose text for section 5 referring to
    "reasonable terms, timeliness, of access and so on, relating to the
    use cases of bug determinations, testing and so on [recorded in
    [97]http://www.w3.org/2009/03/26-bpwg-minutes.html#action09]
    [NEW] ACTION: Jo to specify what he means by the USer Agent
    editorial note under 4.1.5 [recorded in
    [98]http://www.w3.org/2009/03/26-bpwg-minutes.html#action08]
    [NEW] ACTION: Jo to try to draft another doc to the TAG about
    D.1.3.2 [recorded in
    [99]http://www.w3.org/2009/03/26-bpwg-minutes.html#action10]
    [NEW] ACTION: Jo to write something in the introduction about
    respect for CP prefgernces, respect for user preferences and the
    CP's ultimate sanction on the degree of preference they are willing
    to accommodate [recorded in
    [100]http://www.w3.org/2009/03/26-bpwg-minutes.html#action06]
    [NEW] ACTION: Jo tpo preface the first sentence in 4.1.5 with Aside
    from the usual procedures defined in [RFC 2616 HTTP] [recorded in
    [101]http://www.w3.org/2009/03/26-bpwg-minutes.html#action04]

      [94] http://www.w3.org/2009/03/10-bpwg-minutes.html

    [End of minutes]
Received on Monday, 30 March 2009 12:36:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 March 2009 12:36:49 GMT