[minutes] F2F Day 2 - 26 March 2009 - Content Transformation Guidelines from Francois Daoust on 2009-03-30 (public-bpwg@w3.org from March 2009)

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

<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

<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

<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

<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

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.

<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

<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.

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

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

<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

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

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

<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 UTC