IRC log of bpwg on 2009-03-26

Timestamps are in UTC.

09:08:43 [RRSAgent]
RRSAgent has joined #bpwg
09:08:43 [RRSAgent]
logging to http://www.w3.org/2009/03/26-bpwg-irc
09:08:53 [Zakim]
Zakim has joined #bpwg
09:10:31 [Jo]
Meeting: BPWG F2F London MArch 2009 (Day 2)
09:10:48 [Jo]
chair: dka
09:13:35 [DKA]
DKA has joined #bpwg
09:14:41 [DKA]
http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London3/logistics.html
09:14:56 [Jo]
Agenda: http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London3/logistics.html
09:18:22 [francois]
francois has joined #bpwg
09:21:56 [Kai]
Kai has joined #bpwg
09:23:44 [francois]
RRSAgent, draft minutes
09:23:44 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/26-bpwg-minutes.html francois
09:24:16 [francois]
RRSAgent, make logs public
09:27:50 [jeffs]
jeffs has joined #bpwg
09:28:46 [DKA]
Good morning, Jeff!
09:29:08 [jeffs]
even your chat-text sounds too cheerful for pre-sunrise ;^}
09:29:16 [jeffs]
how ya doing?
09:29:22 [francois]
zakim, room for 4 for 300 minutes?
09:29:23 [Zakim]
ok, francois; conference Team_(bpwg)09:29Z scheduled with code 26632 (CONF2) for 300 minutes until 1429Z
09:30:07 [Zakim]
Team_(bpwg)09:29Z has now started
09:30:13 [Zakim]
+jeffs
09:30:31 [EdC]
EdC has joined #bpwg
09:30:34 [jeffs]
zaqkim, who the hell am I (existential question time)
09:30:46 [jeffs]
zakim, who the hell am I (existential question time)
09:30:46 [Zakim]
I don't understand you, jeffs
09:30:53 [jeffs]
neither do I
09:33:17 [DKA]
zakim, who am i?
09:33:17 [Zakim]
I don't understand your question, DKA.
09:33:40 [DKA]
zakim, where am i?
09:33:40 [Zakim]
I don't understand your question, DKA.
09:34:36 [DKA]
zakim, tell me a joke.
09:34:36 [Zakim]
I don't understand 'tell me a joke', DKA
09:34:50 [DKA]
zakim, I'm depressed.
09:34:50 [Zakim]
I don't understand 'I'm depressed', DKA
09:34:52 [francois]
Present: Jo, Kai, Eduardo, Rob, SeanP, DKA, francois, Jeffs
09:35:45 [rob]
rob has joined #bpwg
09:35:55 [DKA]
We discussed [yesterday] some ideas for re-categorization of MWABP proposed by J.J.
09:36:27 [jeffs]
tnx, would you happen to have the notes-URI handy? no biggie if yo don't
09:38:13 [SeanP]
SeanP has joined #bpwg
09:39:07 [adam]
adam has joined #bpwg
09:39:23 [jeffs]
zakim, who is on the call
09:39:23 [Zakim]
I don't understand 'who is on the call', jeffs
09:39:29 [jeffs]
zakim, who is on the phone
09:39:29 [Zakim]
I don't understand 'who is on the phone', jeffs
09:39:42 [jeffs]
zakim, sometimes I hate you
09:39:42 [Zakim]
I don't understand 'sometimes I hate you', jeffs
09:39:47 [DKA]
q?
09:39:52 [DKA]
who's on the phone?
09:39:57 [Jo]
zakim, code?
09:39:57 [Zakim]
the conference code is 26632 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Jo
09:40:05 [jeffs]
zakim, who is on the phone?
09:40:05 [Zakim]
On the phone I see jeffs
09:40:40 [Zakim]
+berners_lee_at_google
09:41:21 [JonathanJ]
JonathanJ has joined #bpwg
09:41:40 [jeffs]
http://www.it.rit.edu/~jxs/test/canvas/action910draft.html
09:42:21 [Jo]
Topic: Canvas (MWABP)
09:43:17 [francois]
Present+ Jonathan
09:43:22 [Kai]
scribe:Kai
09:43:24 [francois]
Present+ Adam
09:44:16 [Kai]
Topic: going through Jeffs comments
09:45:33 [Kai]
jeffs: it's a draft for content
09:46:03 [Kai]
...about when to use SVG or canvas and added a ref that you should use rich interfaces
09:46:37 [Kai]
...actually that there are variety of such interfaces available
09:46:57 [Kai]
...you don't need to draw buttons if all you need are buttons
09:47:32 [Kai]
DKA: conversation yesterday was whether it is really a best practice, enough usage, enough reference material to recommend the use
09:47:59 [Kai]
...is it a forward looking BP rather than something based on existing practice
09:48:31 [Kai]
jeffs: I wanted to include this because more and more full featured browsers in the mobile domain canvas is becoming much more tempting
09:48:49 [Kai]
... it is forward looking in that it is available, but not that much forward looking
09:49:28 [Kai]
Jo: is there anything in canvas you cannot do with svg?
09:50:11 [Kai]
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
09:50:15 [Bryan]
Bryan has joined #bpwg
09:50:45 [Kai]
...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
09:50:59 [Kai]
EdC: Is there are rec when to use svg or canvas?
09:51:04 [Bryan]
hi all, what's the bridge code for today?
09:51:25 [Kai]
DKA: we don't really want to get into the debate but want to talk about using device capabilities
09:51:39 [Kai]
adam: can you use canvas from the dom?
09:51:51 [Kai]
Jo: Yes
09:52:23 [francois]
q+
09:52:26 [Kai]
jeffs: no you cannot. You can change the height, but the content is not visible in the dom
09:52:59 [Kai]
Jo: the problem with Javascipt is that browser consumes the content. What is important that content is available.
09:53:09 [Kai]
jeffs: that's when you want to use svg
09:53:28 [Kai]
Jo: so we should ban JS :-) other than for cool interaction effects
09:53:47 [Bryan]
hi jo, can you start the bridge?
09:53:47 [Kai]
...now we are getting into personal opinion, not best practice
09:54:08 [JonathanJ]
rrsagent, draft minutes
09:54:08 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/26-bpwg-minutes.html JonathanJ
09:54:30 [Kai]
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
09:54:57 [Kai]
EdC: But you have stayed at low level arguments in you text. I like what Jo said about content being discoverable
09:55:08 [Kai]
...so we should recommend svg and discourage canvas
09:55:44 [Kai]
jeffs: if you want it to be discoveralbe then you need to use svg, but don't want to discouage canvas because it is so light weight
09:56:17 [Kai]
SeanP: are there other categories where this fits into..as discussed yesterday? like conservative use of resources?
09:56:46 [Bryan]
q+ to ask if the bridge can be opened
09:56:59 [francois]
zakim, code?
09:56:59 [Zakim]
the conference code is 26632 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), francois
09:57:04 [Bryan]
q-
09:57:08 [Kai]
jeffs: i missed that conversation. I guess it would fit into conservative use of resources. It is less intensive than doing dom manipulation
09:57:20 [Kai]
...canvas will be valuable for information display
09:57:29 [Zakim]
+Bryan_Sullivan
09:57:34 [Kai]
...hard to teach in svg, but easy to do in canvas
09:57:58 [Kai]
...one could talk about it in terms of information display rather than dynamic graphics
09:58:27 [Kai]
...it makes sense to say that browsers are supporting this tag and we should tell people when to use it
09:58:51 [Kai]
DKA: should we recast this as a cautionary notes on the use of dynamic graphic elements
09:59:03 [Kai]
...can discuss the pros and cons of svg and canvas
09:59:21 [Kai]
jeffs: I would not object to that
09:59:35 [Kai]
...I would rather put this in positive terms, but we can do that
09:59:47 [Kai]
DKA: doesn't have to be negative
09:59:57 [Kai]
...I have a problem saying use canvas
10:00:11 [Kai]
adam: should be use the appropriate rendering api
10:00:25 [Kai]
DKA: yes, that way we could tell people what exists
10:01:06 [Kai]
jeffs: should we say use the appropriate rendering api or dynnamic graphics
10:01:34 [Kai]
Jo: we should say don"t use canvas unless you can"t think of another way
10:01:45 [Kai]
jeffs: canvas is about dynamic graphics.
10:01:58 [Kai]
...don"t use it to draw user controls
10:02:19 [Kai]
Jo: I think it would be good to say not to draw buttons
10:02:32 [Kai]
...lot"s to say how not to use it
10:02:51 [francois]
-> http://www.w3.org/TR/html5/the-canvas-element.html#the-canvas-element Definition of the canvas element in HTML5
10:03:05 [Kai]
DKA: Isn"t there something about drawn graphics which are useful if you don"t know screen size
10:03:08 [francois]
Extract: "Authors should not use the canvas element in a document when a more suitable element is available"
10:03:22 [Kai]
jeffs: if you feel you must draw buttons
10:03:42 [Kai]
DKA: perhaps we should encourage people to draw buttons because of scalability
10:04:00 [Kai]
SeanP: hopefully the device will know how to draw buttons
10:04:23 [Kai]
jeffs: we need to help people in situations were all three possibilities can be used
10:04:28 [Kai]
...I agree with Sean
10:04:44 [Kai]
francois: I posted an extract from HTML5 about canvas
10:05:08 [Kai]
...[reading]...
10:05:18 [Kai]
...they are still discussiing. It is a draft
10:05:27 [Kai]
... for the time being it is not clear
10:05:39 [Kai]
... there is not much to discuss at the moment
10:05:54 [Kai]
...it is an api and could have it on top of svg perhaps
10:06:15 [Kai]
...you can mix and match and play with the output
10:06:28 [Kai]
...in the past with svg we had no bp to promote
10:06:40 [Kai]
jeffs: that is an important point
10:07:11 [Kai]
...there is a temptation here if the developer doesn"t care if the content of canvas is not available
10:07:24 [Kai]
...svg is another hurdle and feels heavier
10:07:50 [Kai]
DKA: is there are mobile specific angle that the html5 guys may not have thought of
10:08:13 [Kai]
francois: it is about scalable vectors, scaling graphics, everything will adjust
10:08:18 [Kai]
DKA: and it is lower siye
10:08:27 [Kai]
s/siye/size
10:09:07 [Kai]
SeanP: we discussed the difference between various technologies in graphics. Can we say use this rather than that?
10:09:24 [Kai]
Jo: what is mobile here?
10:09:41 [Kai]
DKA: screen sizes, dynamically adjusting buttons
10:10:02 [Kai]
...in order to render that independent of screen size
10:10:15 [Kai]
....without having to make several images
10:10:32 [Kai]
...what can we say that is relevant to the mobile space?
10:10:56 [Kai]
jeffs: sucking resources dry is mobile
10:11:48 [Kai]
...I think that dynamic graphics using svg will be much heavier and coder brain power, rather than using the drawing api of canvas
10:12:24 [Kai]
Jo: you seem to be saying that developer efficiency is important compared to run time efficiency
10:12:30 [Kai]
jeffs: Yes
10:12:50 [Kai]
... if it is dynamic then use it, not for static stuff
10:13:01 [Bryan]
q+ to ask what is the specific reason that SVG vs canvas is heavier in processing requirements - reliance on DOM in somw way?
10:13:07 [francois]
q-
10:13:15 [Kai]
DKA: I suggest jeffs comes up with a new articulation of the deep analysis we just had
10:13:36 [Kai]
jeffs: I can do that. What is the focus?
10:13:45 [Kai]
Jo: mobile specific aspects
10:14:19 [Kai]
DKA: dealing with screen sizes and resolutions, efficency across the wire, but also rendering resources
10:14:41 [Kai]
adam: I feel uncomfortable about making non backup statements about resource consumption
10:14:56 [Kai]
s/backup/backed up
10:15:21 [Kai]
adam: where are the threshholds?
10:15:37 [Kai]
DKA: should we ask Dom to come with something?
10:16:02 [Kai]
s/come/come up
10:16:16 [Kai]
adam: that would be useful
10:16:31 [francois]
http://www.borismus.com/canvas-vs-svg-performance/
10:16:36 [DKA]
q?
10:16:41 [DKA]
ack br
10:16:41 [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?
10:16:56 [Kai]
Bryan: could we document what the reasons are why canvas is lighter weight?
10:17:24 [Kai]
...isn't that similar to what we talked about yesterday regarding relying on the dom?
10:17:41 [Kai]
jeffs: i thought the group had concluded that dom manipulation is resource heavy
10:17:50 [Kai]
Bryan: that seems to be challanged by adam
10:17:56 [Kai]
adam: we need values for this
10:18:20 [Kai]
jeffs: francois article may be useful. There are some metrics
10:18:34 [Kai]
adam: the document is not for mobile devices
10:18:39 [Kai]
francois: it is an indication
10:18:53 [Kai]
...it is dependent on the size of what you draw
10:19:16 [Kai]
jeffs: graphics that are redrawn a lot are better done in canvas
10:19:39 [Kai]
...I will see if I can get people to try some stuff out on various maschines
10:19:49 [Kai]
DKA: perhaps Dom could be helpful with this
10:20:06 [Kai]
francois: I fear we will end up with figures and no immediate conclusion
10:20:37 [Kai]
Jo: I think it is to early for a BP
10:20:52 [Kai]
DKA: I think we cannot say that now
10:21:10 [Kai]
Jo: an analysis will help in showing that it is too early
10:21:36 [Kai]
DKA: what could we say about exploiting device capabilities?
10:21:57 [Jo]
PROPOSED RESOLUTION: It's too early and too speculative for a BP on SVG Canvas etc.
10:22:06 [francois]
+1
10:22:10 [DKA]
-1
10:22:10 [jeffs]
-1
10:22:11 [Kai]
jeffs: I don"t agree
10:22:23 [Kai]
+0
10:22:42 [EdC]
+1 too early as a best practice (should be based on substantiated experience).
10:22:52 [Kai]
Jo: I don"t know if you will find anything that will change the fundamental problem
10:23:08 [Kai]
DKA: we need to see if there is a lot of use
10:23:22 [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
10:23:22 [Kai]
...nobody has said what people are really doing with it
10:23:36 [Kai]
...if there are many then I don't agree
10:23:50 [DKA]
-1
10:23:58 [Kai]
jeffs: I'd rather not spend energy on something that will not be useful
10:24:19 [Kai]
...in teaching i found that svg has a feeling of being heavy and canvas is not
10:24:28 [rob]
+1 unless there is specific mobile advice to give about vector graphics in general
10:24:33 [Kai]
...as for what is in use that is speculation
10:24:38 [Kai]
DKA: we need more info
10:24:50 [Kai]
...existing web apps that use svg or canvas
10:25:26 [Kai]
...who would want to find out which web apps, like apples, are using svg or canvas?
10:25:38 [Kai]
s/apples/apple's
10:25:59 [Kai]
Jo: I think we are wasting time
10:26:06 [Kai]
DKA: what if there are many?
10:26:23 [Kai]
...otherwise we are doing a good service to the readers
10:26:46 [Kai]
jeffs: I think we should show people how to use this
10:27:01 [Kai]
Jo: this has not been established as a BP
10:27:10 [Kai]
DKA: I propose Jeff and I work on it
10:27:24 [Kai]
...let's close off discussion on this
10:27:59 [Jo]
ACTION: Dan and Jeffs to wander the highways and byways of SVG and Canvas and cook something up for the group's approval
10:27:59 [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].
10:29:33 [Zakim]
-jeffs
10:29:33 [DKA]
q?
10:29:40 [DKA]
15 minute break
10:34:14 [achuter]
achuter has joined #bpwg
10:36:07 [achuter1]
achuter1 has joined #bpwg
10:42:54 [francois]
RRSAgent, draft minutes
10:42:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/26-bpwg-minutes.html francois
10:43:18 [DKA]
Topic: Content Transformation Smack-Down
10:43:55 [SeanP]
Scribenick: SeanP
10:44:06 [SeanP]
Topic: Content Transformation
10:45:13 [DKA]
http://en.wikipedia.org/wiki/WIPI
10:46:00 [SeanP]
Dan: Let's pick a contentious issue to start with.
10:46:12 [SeanP]
...We need to get to all this stuff today.
10:46:51 [SeanP]
Topic: HTTPS Link Rewriting
10:47:19 [SeanP]
Jo: Let's go with ACTION-902
10:47:31 [SeanP]
DKA: Where to we stand on this?
10:47:45 [SeanP]
Jo: There were 3 fundamental questions.
10:48:19 [SeanP]
...1. Link rewriting is a form of CT and subject to the same restrictions as other transformations
10:50:21 [SeanP]
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.
10:50:37 [SeanP]
DKA: I'm not sure how this helps us with the discussion.
10:51:10 [SeanP]
Francois: We need to be clear in the document that insertion of links also is like link rewriting.
10:51:33 [SeanP]
DKA: How about making our definition of link rewriting to include insertion of links.
10:51:47 [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
10:52:32 [SeanP]
DKA: For positions where we have two different opposite viewpoints, maybe each person should take the other's sides.
10:52:50 [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
10:53:16 [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
10:53:16 [SeanP]
Rob: What about flattening out the frameset, where you end up with several documents all placed into one document after CT?
10:53:26 [rob]
+1
10:53:27 [francois]
+1
10:53:30 [SeanP]
+1
10:53:31 [Jo]
+1
10:53:32 [Kai]
+1
10:53:35 [DKA]
+1
10:53:36 [Bryan]
+1
10:53:46 [JonathanJ]
+1
10:53:49 [SeanP]
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
10:54:39 [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
10:54:42 [rob]
+1
10:54:43 [francois]
+1
10:54:51 [SeanP]
+1
10:54:56 [EdC]
+1
10:55:18 [DKA]
+1
10:55:20 [SeanP]
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
10:55:31 [Bryan]
q+
10:55:57 [DKA]
q?
10:55:59 [DKA]
ack bry
10:56:05 [JonathanJ]
+EOF
10:56:42 [SeanP]
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.
10:57:51 [SeanP]
Rob: You may need to rewrite URIs with frameset flattening, pagination, and javascript links.
10:58:56 [SeanP]
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.
10:59:12 [SeanP]
DKA: Can you make a resolution on this?
10:59:28 [Jo]
PROPOSED RESOLUTION: Proxies MAY rewrite links, where content transformation is permitted, providing that content domain origin distinctions are preserved by the proxy.
10:59:36 [SeanP]
Rob: Is the Google transformation engine out of scope.
10:59:57 [SeanP]
DKA: Can you explain this Jo?
11:00:23 [SeanP]
Francois: I though we agreed that this wouldn't work.
11:01:00 [SeanP]
Jo: There are two parallel threads here. 1. Is this required for hygene on the web? 2. Are the techniques available?
11:01:43 [SeanP]
Francois: Should we do the techniques first?
11:02:04 [SeanP]
Rob: There are two parallel threads and the answer to both is yes.
11:02:22 [DKA]
+1
11:02:49 [SeanP]
Jo: What we mean by this resolution is that content domain origin distinctions are preserved.
11:03:28 [SeanP]
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?
11:03:44 [Bryan]
+1
11:03:56 [SeanP]
Rob: We are trying to preserve security; safety from cross-domain attacks.
11:04:16 [Bryan]
q+ to explain that we should give an example of how "domain origins distinctions can be preserved"
11:04:54 [francois]
ack Bryan
11:04:54 [Zakim]
Bryan, you wanted to explain that we should give an example of how "domain origins distinctions can be preserved"
11:05:07 [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...
11:05:09 [Jo]
...problems as a result of not knowing that different origins are involved
11:05:34 [SeanP]
Bryan: We should provide an example of how domain origins can be preserved. To me this isn't clear and needs to be shown.
11:06:46 [SeanP]
Jo: I agree. We need to show that there are techniques that it can be done and that it is testable.
11:06:51 [francois]
+1
11:07:21 [Kai]
+1
11:07:23 [DKA]
+1
11:07:31 [SeanP]
+1
11:07:33 [rob]
+1
11:07:36 [Jo]
+1
11:07:55 [Bryan]
+1
11:08:02 [JonathanJ]
+1
11:08:48 [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...
11:08:50 [Jo]
...security problems as a result of not knowing that different origins are involved
11:08:54 [Jo]
+1
11:08:57 [EdC]
+1
11:09:09 [JonathanJ]
+1
11:09:10 [francois]
+1
11:09:14 [DKA]
+1
11:09:26 [rob]
+1
11:09:28 [Jo]
+1
11:09:30 [SeanP]
+1
11:09:49 [SeanP]
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
11:09:56 [SeanP]
...security problems as a result of not knowing that different origins are involved
11:10:14 [SeanP]
Jo: We need to show that there are testable techniques.
11:10:46 [SeanP]
Francois: I don't really understand the testable parts. Do we need to show the testable techniques in the guidelines.
11:11:05 [SeanP]
Jo: Since you own the conformance statement, you need to do it.
11:11:27 [SeanP]
Rob: The problems are in the DOM; needs to be testable in the DOM spec.
11:12:01 [SeanP]
Francois: There needs to be something testable in the proxy.
11:12:12 [SeanP]
Rob: Testable the same way as in a browser.
11:12:34 [SeanP]
Francois: What are the examples?
11:12:35 [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
11:12:35 [Bryan]
e required since all browser requests flow through the CT Proxy."
11:12:59 [SeanP]
Rob: Look up XXS.
11:13:10 [francois]
-> http://www.w3.org/TR/2009/WD-cors-20090317 Cross-origin resource sharing draft
11:13:24 [SeanP]
Francois: There is some work to allow cross-origin resource sharing.
11:13:42 [SeanP]
...based on HTTP header fields saying I allow access to the other origin.
11:13:49 [SeanP]
Jo: Isn't that easy to subvert.
11:13:59 [SeanP]
Francois: May be more involved than that.
11:14:45 [SeanP]
DKA: Let's not get into philosophical discussions.
11:15:15 [SeanP]
Francois: We need to provide some examples of how same origin can be preserved.
11:16:02 [SeanP]
Rob: One reason for rewriting URIs is that they get too long. Many handsets truncate URIs at 256 characters.
11:16:39 [SeanP]
Jo: Let's summarize the techniques that we have discussed today.
11:16:56 [SeanP]
...differences in ports does not work.
11:17:06 [SeanP]
Rob: Not all ports are are open as well.
11:17:26 [SeanP]
Jo: Can't use subdomains.
11:18:00 [SeanP]
Francois: Having a star in the URI doesn't work as Brian pointed out.
11:18:17 [SeanP]
Jo: Can't use URI decorating.
11:18:20 [francois]
s/in the URI/in the DNS record
11:18:35 [Jo]
s/Brian/Bryan/
11:19:10 [SeanP]
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.
11:19:39 [SeanP]
Eduardo: If scripts are passed down to the handset then you could have a problem.
11:20:28 [SeanP]
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.
11:20:41 [SeanP]
Eduardo: How can we say that in the guidelines?
11:20:58 [SeanP]
Rob: We need to do some tests like with browsers, but on the proxy.
11:21:08 [SeanP]
Eduardo: Where to you do the tests?
11:21:28 [SeanP]
Rob: You do the tests on the origin server.
11:21:57 [SeanP]
Kai: Why are we worried about this. If some one wants to do this they won't care about this document.
11:22:14 [SeanP]
Rob: The tools are there already.
11:22:27 [francois]
-> http://www.w3.org/DOM/Test/ DOM conformance test suite
11:22:48 [SeanP]
Francois: We can use the DOM conformance test suite.
11:24:10 [Bryan]
q+
11:24:23 [SeanP]
Jo: Which is the relevant specification for the tests?
11:24:45 [SeanP]
ack Bryan
11:25:50 [DKA]
+alan
11:26:12 [SeanP]
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.
11:26:21 [Jo]
present+ Alan
11:27:27 [SeanP]
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.
11:28:22 [SeanP]
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
11:28:56 [SeanP]
Rob: Yes, we just need to say that if a CT proxy handles the scripts, then it needs to handle the cookies.
11:29:04 [SeanP]
s/domain.1/domain/
11:29:30 [SeanP]
Francois: these tests don't cover the cookies.
11:29:44 [SeanP]
Rob: Yes, but there are tests that cover cookies.
11:30:13 [SeanP]
DKA: Can we reference these tests right now and look at them later?
11:30:32 [SeanP]
Jo: We need to look at them first.
11:32:52 [SeanP]
Jo: 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.
11:33:29 [SeanP]
Francois: What we are saying is that the CT proxy becomes a web browser and has to be tested like a web browser.
11:34:40 [SeanP]
Francois: I don't think that these tests cover security.
11:34:47 [achuter]
achuter has joined #bpwg
11:34:54 [SeanP]
Rob: Maybe the Opera guys have some security tests.
11:35:49 [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...
11:35:51 [Jo]
...rewriting and it cannot be permissible for CT proxies to do so.
11:37:18 [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...
11:37:20 [Jo]
...conformance associated with link rewriting and it cannot be permissible for CT proxies to do so.
11:37:40 [DKA]
+1
11:38:13 [SeanP]
Rob: Is it worth mentioning what tests were are looking for--JavaScript and cookies?
11:38:31 [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).
11:38:32 [SeanP]
...and DOM?
11:38:45 [Bryan]
Bryan has joined #bpwg
11:38:56 [rob]
+1
11:39:04 [Bryan]
+1
11:39:13 [SeanP]
Francois: What else could there be? I think just cookies and scripts.
11:39:23 [francois]
+1
11:39:35 [Jo]
+1
11:39:38 [EdC]
+1
11:39:47 [SeanP]
Francois: Just so I understand, if we can't find tests then we won't allow link rewriting.
11:39:53 [SeanP]
Jo: Yes.
11:40:03 [SeanP]
+1
11:40:16 [Jo]
+1
11:40:19 [JonathanJ]
+1
11:40:23 [SeanP]
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...
11:40:32 [SeanP]
...conformance associated with link rewriting and it cannot be permissible for CT proxies to do so.
11:42:05 [SeanP]
Francois: Could be linked to HTML 5; they are the ones defining same origin.
11:42:10 [Jo]
ACTION: daoust to ascertain the availability of tests that ensure that same origin policy conformance, when implemented in this way, can be tested
11:42:11 [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].
11:42:51 [SeanP]
DKA: Let's move on to the next resolution.
11:43:10 [Bryan]
q+
11:43:18 [Jo]
PROPOSED RESOLUTION: Interception of HTTPS is not permissible without consent from the user on a case by case basis
11:43:33 [SeanP]
Jo: We need to agree on what Case-by-case basis means.
11:44:12 [SeanP]
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...
11:44:14 [SeanP]
...as normal HTTP proxies (e.g. configured or transparent) for the browser, but may not b
11:44:32 [SeanP]
e required since all browser requests flow through the CT Proxy."
11:44:58 [SeanP]
Jo: Why don't include that as a note under link rewriting?
11:45:02 [SeanP]
Bryan: OK
11:45:16 [DKA]
q?
11:45:19 [DKA]
ack bry
11:45:23 [Bryan]
q-
11:45:43 [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....
11:45:45 [DKA]
zakim, who is here?
11:45:45 [Zakim]
On the phone I see berners_lee_at_google, Bryan_Sullivan (muted)
11:45:45 [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."
11:45:46 [Zakim]
On IRC I see Bryan, achuter, JonathanJ, adam, SeanP, rob, EdC, Kai, francois, DKA, Zakim, RRSAgent, Jo, trackbot
11:46:04 [EdC]
+1
11:46:13 [Bryan]
+1
11:46:30 [JonathanJ]
+1
11:46:46 [SeanP]
+1
11:46:50 [Jo]
+1
11:46:54 [rob]
+1
11:46:58 [DKA]
+1
11:47:10 [adam]
+1
11:47:29 [SeanP]
Francois: I am at a bit of a loss on this resolution. The other resolution still stands, right.
11:47:37 [francois]
+1
11:47:41 [SeanP]
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....
11:47:55 [SeanP]
...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."
11:48:03 [Jo]
PROPOSED RESOLUTION: Interception of HTTPS is not permissible without consent from the user on a case by case basis
11:49:07 [DKA]
q?
11:49:16 [SeanP]
Jo: What does case-by-case basis mean?
11:49:32 [francois]
[FYI, the following page seems to be pretty complete on same origin policy and security settings: http://code.google.com/p/browsersec/wiki/Part2#Standard_browser_security_features ]
11:51:22 [SeanP]
Jo: What we are trying to avoid with "case-by-case basis" is blanket preferences and also making the user do nonsensical things.
11:51:24 [Jo]
PROPOSED RESOLUTION: Interception of HTTPS is not permissible without explicit prior agreement from the Content Provider
11:51:53 [Bryan]
q+ to ask if this is testable
11:51:54 [Jo]
[we need to solve the next Proposed resolution prior to the previous]
11:52:05 [SeanP]
Jo: Let's look at the next resolution because the case-by-case problem won't exist if we take the next resolution.
11:52:46 [SeanP]
DKA: If we are viewing the CT proxy as the browser, then this HTTPS resolution doesn't make sense.
11:53:13 [SeanP]
Francois: Earlier we decide that a CT proxy is a distributed browser.
11:54:13 [SeanP]
Bryan: On Jo's proposed resolution, are we only including resolutions that are testable? I don't think explicit prior agreement is testable.
11:54:48 [SeanP]
DKA: I don't think that it even makes sense. A bank is one thing, but what about other types of transactions?
11:55:26 [SeanP]
Jo: It is impossible to second-guess a CP's use of HTTPS. They want a secure transaction.
11:55:48 [SeanP]
DKA: I don't see that this is testable or scalable. I agree with Bryan.
11:56:22 [SeanP]
Jo: Then you would say that the resolution must be taken and can't use non-testable as a cop out.
11:56:29 [SeanP]
DKA: What do others think?
11:57:21 [SeanP]
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.
11:57:33 [SeanP]
DKA: What about Opera Mini, SkyFire?
11:58:06 [SeanP]
Francois: There is tight integration between client and server.
11:58:24 [SeanP]
DKA: You should still hijack the Opera server.
11:58:39 [SeanP]
Rob: Could happen on Firefox as well.
11:59:29 [SeanP]
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.
12:00:09 [DKA]
DKA has joined #bpwg
12:00:42 [SeanP]
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.
12:00:55 [SeanP]
DKA: We talked about Opera Mini.
12:01:05 [SeanP]
Jo: Out of scope of this document.
12:01:25 [SeanP]
DKA: There is the opportunity for malware even on a desktop browser.
12:01:52 [SeanP]
Jo: Are you saying that because there are opportunities for malware, why not introduce more?
12:02:33 [SeanP]
DKA: If you assume that the actors are benign, then what we are talking about malware.
12:03:02 [SeanP]
Jo: I don't agree. We are saying that the CP doesn't want anyone to listen in.
12:04:08 [SeanP]
Kai: Obtaining permission from the origin server means that the CT proxy goes out of scope.
12:05:33 [SeanP]
Francois: The only reason to allow HTTPS link rewriting is to allow good user experience.
12:07:00 [SeanP]
Francois: You are not honoring the spirit of the HTTPS.
12:07:58 [SeanP]
DKA: So one reason not to allow HTTPS link rewriting would be because the user couldn't examine the certificate.
12:08:40 [Bryan]
q+ to point out dependency upon domain validation for downloaded or signed objects
12:08:48 [SeanP]
...You might not be able prevent phishing attacks.
12:08:58 [DKA]
ack bry
12:08:58 [Zakim]
Bryan, you wanted to ask if this is testable and to point out dependency upon domain validation for downloaded or signed objects
12:09:13 [SeanP]
Rob: You could allow the user to see the real certificate through some UI.
12:09:58 [SeanP]
Bryan: You have the same trust issues as with the scripts and cookies and some domain stuff.
12:11:12 [SeanP]
Bryan: I can be downloading content for use outside the browser and the trust might be broken because I downloaded it through the proxy.
12:11:38 [SeanP]
Rob: That comes back to the link-rewriting argument.
12:12:16 [francois]
zakim, where is +31?
12:12:16 [Zakim]
country code 31 is Netherlands
12:12:18 [SeanP]
Eduardo: There might be some cases where HTTPS could be used--on phones where the cert handling might be broken.
12:13:15 [SeanP]
DKA: I'm warming to requiring consent for HTTPS link rewriting; it's just web breaking.
12:14:05 [SeanP]
Rob: What about the long tail where there is HTTPS but no mobile site.
12:14:45 [SeanP]
DKA: How about giving a strongly worded warning to the user that their connection is not secure?
12:15:02 [SeanP]
Francois: Because it is not necessarily up just to the user.
12:16:04 [SeanP]
DKA: What about if I give someone my password? Then the CP is not necessarily talking to the real user.
12:17:05 [SeanP]
Rob: True. It is usually the user's responsibility to take on the risk.
12:17:35 [SeanP]
Francois: What about banks that don't allow CT proxies to intervene?
12:18:04 [SeanP]
DKA: Well, there is no reason that CT proxies couldn't be more restrictive that what we say.
12:18:34 [SeanP]
Kai: The CP is selecting HTTPS, and it shouldn't be changed.
12:19:48 [SeanP]
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.
12:20:11 [SeanP]
Francois: There is no way for the CP to refuse the choice.
12:20:26 [SeanP]
Kai: no-tranfoirm?
12:20:43 [SeanP]
Francois: But it is already too late?
12:21:07 [SeanP]
Rob: The HTTPS request should have a via header that would not normally be there.
12:21:21 [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.
12:21:28 [SeanP]
Francois: That is not enough.
12:22:04 [SeanP]
Eduardo: As a CP, I would feel comfortable with this. Also, the legal framework could be a problem.
12:22:40 [SeanP]
DKA: We can't always say "don't do this if it is illegal"
12:22:43 [Bryan]
q+ to state we should not require such a consent to be real-time or explicit
12:22:51 [DKA]
PROPOSED RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
12:23:00 [EdC]
Change "I feel comfortable" with "I do not feel conformtable".
12:23:04 [DKA]
ack bry
12:23:04 [Zakim]
Bryan, you wanted to state we should not require such a consent to be real-time or explicit
12:24:13 [SeanP]
s/I would feel comfortable/I would not feel comfortable/
12:25:03 [SeanP]
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.
12:25:27 [SeanP]
...We've had significant problems with HTTPS and the way it is used and prompting the user.
12:25:57 [SeanP]
Kai: I would second that. You might have to do it for every asset on the page.
12:26:00 [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.
12:27:07 [SeanP]
Rob: The user can give their consent in real time. The HTTPS link stays up for a long time.
12:27:51 [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"
12:27:55 [SeanP]
DKA: You would have a strong warning that required consent. You might really need to get to your bank.
12:28:32 [SeanP]
Kai: Users try to avoid that popup. It happens when secure content is mixed with insecure content.
12:28:48 [SeanP]
...What is more important that users know they are leaving a secure connection;.
12:29:32 [SeanP]
DKA: What is really important is that the user knows that the HTTPS connection is going through a CT proxy.
12:29:46 [SeanP]
Kai: Are user's going to understand the implications of this?
12:30:42 [SeanP]
DKA: If the user trusts Vodafone, then the user may want the HTTPS link through the CT proxy.
12:31:11 [SeanP]
Kai: What about some unknown company?
12:31:23 [SeanP]
DKA: Then the user can refuse.
12:32:09 [SeanP]
Rob: There is the long tail where there are websites that have been written long ago that provide HTTPS.
12:32:13 [DKA]
PROPOSED RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
12:33:38 [adam]
Rob: It's not a symmetric aggreement. The server knows nothing about the user's identity.
12:34:04 [Jo]
i/Rob:/scribenick: adam
12:34:56 [adam]
francois: Technically, yes, but the impression is that it's symmetrical.
12:35:21 [adam]
DKA: We need to draw this to a close.
12:35:58 [adam]
Kai: I don't want anybody else to do anything with my https content. It's secured content.
12:36:14 [adam]
Kai: Supportive of the resolution.
12:36:15 [SeanP]
-1
12:36:17 [rob]
-1 because this is not scalable to even a thousand long-tail websites that may use HTTPS for log-in
12:36:18 [Kai]
+1
12:36:23 [EdC]
+1
12:36:50 [Bryan]
+1
12:36:55 [Jo]
+1
12:36:55 [francois]
+1 (because something's missing in the technology stack to enable that)
12:37:27 [adam]
Bryan: We're not saying anything about the verifiability of such agreement
12:38:04 [Kai]
of course, if there is an agreement it is out of scope of this document :-)
12:38:07 [adam]
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.
12:38:25 [adam]
DKA: Yes, but this resolution says: *never*.
12:38:47 [adam]
rob: This resolution is about the consent of the origin server. The consent of the user is separate resolution.
12:39:05 [adam]
DKA: Yes, but if we pass this resolution then we'll never encounter the other one in reality.
12:39:44 [adam]
DKA: This would mean that a lot of existing implementations are not-compliant.
12:39:51 [adam]
kai: Perhaps rightfully so.
12:40:47 [adam]
kai: Can the intermediary be trusted not to do anything with the secured data?
12:42:17 [adam]
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.
12:42:46 [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.
12:43:02 [Jo]
-1
12:43:08 [francois]
-1
12:43:12 [adam]
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.
12:43:25 [EdC]
-1
12:43:35 [adam]
DKA: This is the opposite resolution.
12:43:57 [adam]
SeanP: So there will be a warning every time?
12:44:01 [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
12:44:11 [adam]
DKA: The warning will be each time the user starts a session.
12:44:38 [Kai]
-1 because an agreement between user and proxy operator may still hold the CP responsible, which is untenable
12:45:13 [Jo]
[two party consent is required and can't be achieved]
12:45:18 [adam]
DKA: Disagree with "CT proxy session" -- my decision to trust the CT depends on the sites I am interacting with.
12:46:14 [adam]
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.
12:50:06 [francois]
RRSAgent, draft minutes
12:50:06 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/26-bpwg-minutes.html francois
12:50:38 [adam]
[ Discussion on whether a bank (for example) would be happy with this proposal ]
12:50:55 [adam]
DKA: We don't want to weaken the perceived security of mobile internet.
12:51:44 [adam]
Jo: May be pragmatic to transform https content without consent of CP, but can't be a BP.
12:52:24 [DKA]
PROPOSED RESOLUTION: We will remain silent on https content rewriting.
12:54:35 [DKA]
PROPOSED RESOLUTION: We will identify https transformation as a feature at risk - something you can remove from the document.
12:54:44 [adam]
Francois: Could mark it as a feature at risk, we may have to remove this recommendation if we can't implement it.
12:55:47 [francois]
-> http://www.w3.org/2005/10/Process-20051014/tr.html#at-risk-feature Definition of a feature at risk
12:56:35 [adam]
Jo: If we allow https transformation we leave CP with no way of saying: "I don't want this to happen."
13:00:08 [adam]
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.
13:01:00 [adam]
dka: What happens on the handshake when the ct proxy establishes the connection with the origin server?
13:02:05 [adam]
Bryan: SSL handshake between CT Proxy and origin server.
13:02:24 [adam]
Bryan: But the origin server has no way to know that this is coming from the proxy and not from a browser.
13:02:42 [adam]
Rob: You could put in a via header... But that's after the SSL is established.
13:03:37 [adam]
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.
13:04:40 [adam]
Kai: So the via header is required.
13:04:43 [adam]
Jo: Yes.
13:06:48 [adam]
DKA: Is this the middle-way we want? The control is back on the server.
13:07:18 [adam]
Francois: But legacy content that doesn't know about this will quietly get opted-in.
13:09:29 [adam]
Jo: Two party consent is fundamental principle. But this isn't two party consent -- it's one party consent and one party ignorance.
13:10:08 [adam]
DKA: This doesn't break two party consent.
13:10:48 [adam]
Kai: The server has an opportunity to refuse because it sees the header.
13:11:11 [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.
13:13:00 [DKA]
PROPOSED RESOLUTION: We will remain silent on https content rewriting.
13:13:08 [adam]
Kai: Is the user protected from unwanted manipulation?
13:13:25 [adam]
DKA: None of this prevents bad proxies / malware.
13:13:52 [adam]
Kai: The goal we are trying to acheive is measure conformance to this document.
13:15:00 [adam]
DKA: There isn't much consensus. The weight of opinion is on explicitly disallowing https transformation.
13:15:37 [DKA]
PROPOSED RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
13:16:04 [adam]
Francois: We've already had significant feedback saying please don't allow HTTPS link re-writing.
13:16:54 [adam]
Rob: We could say that proxies may transform (subject to user consent) and mark it as a feature at risk.
13:17:21 [adam]
Jo: Feature at risk is only valid on the grounds of implementation experience -- if it turns out to be unviable.
13:19:12 [adam]
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.
13:19:38 [adam]
DKA: That sounds like an informative statement. Remain silent means: No normative statement.
13:20:14 [adam]
Jo: I think it would look strange.
13:21:13 [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.
13:21:50 [adam]
EdC: Replace "or" with "and" and I agree.
13:22:19 [Bryan]
-1 we should not mandate the "at the begginning..."
13:23:24 [adam]
Bryan: Don't want to make statements about when consent is provided since it can have unforeseen effects.
13:23:30 [DKA]
zakim, remind me in 7 minutes
13:23:30 [Zakim]
ok, DKA
13:23:42 [adam]
SeanP: Agree with Bryan, user experience might not be good.
13:24:16 [adam]
Rob: If we go with a resolution like this a number of resolutions on when consent is provided is likely to follow.
13:24:58 [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"
13:25:05 [Jo]
PROPOSED RESOLUTION: Two party consent is required for HTTPS link rewriting
13:25:49 [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.
13:26:12 [SeanP]
+1 to the last one
13:26:16 [EdC]
-1 same issue: "and" instead of "or"
13:26:46 [Kai]
-1 it continues to leave the CP being responsible
13:26:55 [Kai]
+1 to Jo's proposal
13:27:55 [rob]
+1 if it is legally OK to have one-party consent
13:28:22 [Jo]
PROPOSED RESOLUTION: Per OPES two party consent is required for HTTPS link rewriting (by the content provider and the user)
13:29:50 [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
13:30:30 [Zakim]
DKA, you asked to be reminded at this time
13:30:53 [DKA]
PROPOSED RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
13:31:21 [Bryan]
+1
13:31:35 [Kai]
+1
13:31:40 [Bryan]
I want breakfast
13:31:47 [SeanP]
-1
13:31:49 [francois]
+1
13:31:49 [EdC]
+1
13:31:53 [rob]
-1
13:31:54 [DKA]
+0
13:31:55 [Jo]
+1
13:31:57 [adam]
0
13:32:26 [adam]
RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
13:32:27 [JonathanJ]
0
13:32:31 [achuter]
+0
13:32:48 [adam]
Rob: This will give us trouble with reference implementations.
13:33:17 [DKA]
Topic: Lunch
13:33:18 [Jo]
[adjourned]
13:33:23 [Zakim]
-Bryan_Sullivan
13:33:26 [francois]
RRSAgent, draft minutes
13:33:26 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/26-bpwg-minutes.html francois
13:40:35 [Zakim]
-berners_lee_at_google
13:40:36 [Zakim]
Team_(bpwg)09:29Z has ended
13:40:37 [Zakim]
Attendees were jeffs, berners_lee_at_google, Bryan_Sullivan
14:11:31 [EdC]
EdC has joined #bpwg
14:13:55 [achuter1]
achuter1 has joined #bpwg
14:16:06 [adam]
adam has joined #bpwg
14:18:37 [Zakim]
Team_(bpwg)09:29Z has now started
14:18:44 [Zakim]
+Bryan_Sullivan
14:19:00 [JonathanJ]
Present+ Seungyun
14:22:20 [rob]
Scribe: Rob
14:22:26 [rob]
ScribeNick: rob
14:22:52 [francois]
zakim, who is on the phone?
14:22:52 [Zakim]
On the phone I see Bryan_Sullivan
14:23:00 [francois]
zakim, code?
14:23:00 [Zakim]
the conference code is 26632 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), francois
14:23:10 [rob]
SeanP: from a practical sense, nearly every deployment Novarra's done has involved HTTPS rewriting
14:23:30 [Jo]
zakim, who is on the phone?
14:23:30 [Zakim]
On the phone I see Bryan_Sullivan
14:23:33 [rob]
... and those that didn't it was asked for later
14:23:55 [rob]
DKA: this is a victim of dogma over common sense
14:24:03 [seungyun]
seungyun has joined #bpwg
14:24:09 [Bryan]
Sean, do the deployments act as a transparent or configured proxy?
14:24:15 [Zakim]
+berners_lee_at_google
14:24:23 [SeanP]
Both
14:24:30 [Jo]
present+ seungyun
14:25:43 [rob]
EdC: My presence here at this meeting is sponsored by dotmobi
14:26:02 [Jo]
s/is/is partly/
14:26:32 [EdC]
All my thanks to dotmobi to allow me to participate in the F2F meeting.
14:26:55 [rob]
Topic: Issue 285
14:27:05 [rob]
Jo: I think we can close this
14:27:23 [rob]
DKA: do we need any further resolutions to close this?
14:28:50 [rob]
francois: we can link the action to the issue
14:29:30 [rob]
Topic: Issue 288
14:30:37 [rob]
Jo: under sec 4.2.9 of the CTG draft we have the heuristics
14:31:19 [rob]
... the resolution is a SHOULD take account of these heuristics. So they are no longer heuristics
14:31:32 [rob]
... Is there a textual change to make here?
14:32:17 [rob]
francois: the examples are no longer examples but a list of things that unambiguously make a page mobile-aware
14:32:25 [francois]
-> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0066.html minutes on mandating heuristics
14:33:11 [rob]
... and the other things in the appendix remain examples of heuristics that could also be taken into account of under undocumented circumstances
14:35:29 [rob]
Jo: ok, so I'll reword 4.2.9
14:37:13 [rob]
DKA: So we still have some non-mandatory heuristics
14:37:58 [rob]
francois: These could create confusion if people expect that following them will result in certain actions
14:38:01 [Jo]
ACTION: Jo to inser sections under proxy decision to transform a. to specify SHOULD NOT in the presence of the features listed at http://www.w3.org/2009/03/10-bpwg-minutes.html and b. to include the current cullets listed as heuristics
14:38:01 [trackbot]
Created ACTION-926 - Inser sections under proxy decision to transform a. to specify SHOULD NOT in the presence of the features listed at 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].
14:38:19 [rob]
... but it's just a probable
14:39:00 [rob]
... and we've already seen in the past examples of "W3C said ..." quotes out of context
14:39:29 [DKA]
PROPOSED RESOLUTION: We delete all non-normative heuristics and close issue-288
14:40:01 [DKA]
PROPOSED RESOLUTION: We delete non-normative heuristics except for doctypes and close issue-288
14:41:24 [DKA]
PROPOSED RESOLUTION: We delete all non-normative heuristics and close issue-288.
14:41:24 [francois]
+1
14:42:43 [rob]
DKA: it's not our job to tell CT-proxy vendors how to do everything
14:43:25 [rob]
Jo: but a domain name of *.mobi is a very good indication we should keep
14:43:59 [rob]
francois: In theory it's not although in practice it is
14:44:23 [rob]
Jo: what about the TAG finding that URIs should be "meaningful"?
14:45:12 [rob]
francois: your point is valid as a good practice
14:46:09 [rob]
SeanP: the mandatory ones are SHOULD, can the rest be MAY?
14:49:08 [rob]
francois: different levels of SHOULD, MAY, might, could... are confusing
14:50:29 [rob]
Jo:I'll try to find this TAG advice
14:51:41 [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.
14:52:10 [Jo]
--> http://www.w3.org/2001/tag/doc/metaDataInURI-31.html TAG FINDING on Metadata in URIs
14:53:57 [rob]
Rob: but the use of different User-Agents to view content isn't always relevant to the direct-use-URI
14:54:41 [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
14:55:38 [rob]
francois: is there a reference (eg .mobi charter) we can use?
14:58:47 [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
14:59:05 [Zakim]
This conference is in overtime; all ports must be freed
14:59:32 [Bryan]
oops - need a new bridge code?
14:59:52 [adam2]
adam2 has joined #bpwg
15:00:27 [rob]
Kai: are there dotmobi constraints that guarantee this?
15:00:49 [Jo]
zakim, drop everyone
15:00:49 [Zakim]
sorry, Jo, I do not see a party named 'everyone'
15:01:01 [Jo]
zakim, who is on the phone?
15:01:01 [Zakim]
On the phone I see Bryan_Sullivan (muted), berners_lee_at_google
15:01:05 [Zakim]
-berners_lee_at_google
15:01:08 [Zakim]
-Bryan_Sullivan
15:01:09 [Zakim]
Team_(bpwg)09:29Z has ended
15:01:11 [Zakim]
Attendees were Bryan_Sullivan, berners_lee_at_google
15:01:13 [francois]
zakim, room for 4 for 300 minutes?
15:01:15 [Zakim]
ok, francois; conference Team_(bpwg)15:01Z scheduled with code 26632 (CONF2) for 300 minutes until 2001Z; however, please note that capacity is now overbooked
15:01:27 [rob]
Jo: Yes, there are compliance rules with the company dotmobi to take out a *.mobi domain name
15:01:37 [Zakim]
Team_(bpwg)15:01Z has now started
15:01:43 [Jo]
zakim, code?
15:01:43 [Zakim]
the conference code is 26632 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Jo
15:01:46 [Zakim]
+Bryan_Sullivan
15:02:15 [Zakim]
+berners_lee_at_google
15:02:52 [rob]
+1
15:02:53 [DKA]
+1
15:02:56 [achuter1]
+1
15:03:04 [EdC]
+1
15:03:06 [Jo]
[am conflicted so 0]
15:03:17 [JonathanJ]
+1
15:03:19 [Bryan]
+1
15:03:29 [Kai]
0
15:03:32 [francois]
0 (note there could be a vendor-neutrality problem on top of the Web arch possible push-back)
15:03:36 [rob]
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
15:03:44 [SeanP]
0
15:04:13 [Bryan]
what about "m.domain" type hostnames?
15:04:46 [rob]
francois: I think we shouldn't even mention the rest htat are not SHOULDs
15:04:58 [rob]
s/htat/that/
15:06:02 [rob]
EdC: but combinations such as application/xhtml+xml AND http://m.* will actually be good practice
15:06:22 [rob]
francois: but it doesn't give the content-provider any guarantees
15:06:51 [rob]
EdC: they are ambiguous but they are in use
15:07:13 [rob]
SeanP: I don't see a big problem leaving them in a non-normative appendix
15:07:43 [rob]
jo: are we abandoning the list in 4.2.9?
15:08:10 [rob]
francois: apart from the agreed SHOULD parts, yes
15:08:24 [Bryan]
Which version is 4.2.9 in? Can someone past a URI to the draft?
15:08:48 [rob]
... the rest either delete or move to an appendix
15:10:16 [rob]
jo: even the mobileOK Basic confomance mark?
15:10:50 [DKA]
PROPOSED RESOLUTION: close issue-288 and move on.
15:11:00 [rob]
Rob: it's a feature-at-risk because there is currently no standard machine-readable trustmark
15:11:11 [Bryan]
Can we say which bullets in "Examples of heuristics:" (in 4.2.8 in 081107) are being removed?
15:11:43 [DKA]
PROPOSED RESOLUTION: We delete all non-normative heuristics and close issue-288.
15:12:27 [Bryan]
Which ones are "non-normative"?
15:13:14 [francois]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090313#sec-proxy-decision-to-transform
15:14:09 [francois]
+1
15:14:11 [rob]
Jo: ok, let's just remove the non-mandatory items
15:14:20 [SeanP]
0
15:14:25 [rob]
0
15:16:10 [rob]
EdC: even remove the line "the user-agent has features ... to allow it to present the content"
15:16:26 [rob]
s/content"/content"?/
15:17:27 [Bryan]
q+
15:18:05 [rob]
francois: yes because User-Agent was considered at the HTTP Request stage
15:18:51 [rob]
jo: but it could also be considered in conjunction with the content of the response
15:19:02 [Jo]
--> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090313 Current Draft
15:21:22 [rob]
francois: but that is difficult to test
15:22:41 [rob]
... eg the user-agent can render tables but it may be so wide as to be unviewable
15:23:47 [rob]
Rob: as Kai points out there's definitely no best-practice here
15:23:48 [DKA]
PROPOSED RESOLUTION: We delete all non-normative heuristics and close issue-288.
15:23:55 [francois]
+1
15:24:17 [Jo]
+1
15:24:20 [DKA]
+1
15:24:28 [rob]
0
15:24:37 [rob]
RESOLUTION: We delete all non-normative heuristics and close issue-288
15:25:13 [DKA]
CLOSE ISSUE-288
15:25:13 [trackbot]
ISSUE-288 Should the Content Transformation Guidelines include a non normative list of non-mandated mobile heuristics? closed
15:25:17 [rob]
Topic: Issue 289
15:25:57 [DKA]
PROPOSED RESOLUTION: Close Issue-284
15:26:02 [DKA]
+1
15:26:04 [rob]
+1
15:26:06 [francois]
+1
15:26:06 [EdC]
+1
15:26:11 [DKA]
CLOSE ISSUE-284
15:26:11 [trackbot]
ISSUE-284 W3C mobile addressing standards closed
15:26:28 [rob]
RESOLUTION: Close Issue-284
15:29:07 [rob]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/open
15:30:45 [rob]
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
15:31:13 [rob]
francois: then you're already mobile-friendly enough that the CT-proxy has nothing to adapt
15:31:33 [rob]
DKA: what if there is something that needs adapting?
15:31:49 [rob]
EdC: like what?
15:33:02 [rob]
SeanP: there are cases where altered headers might be sent first, then what?
15:33:36 [rob]
francois: Then the Vary; User-Agent header can be used to indicate there was alternate content available
15:34:00 [rob]
s/Vary;/Vary:/
15:34:19 [achuter1]
scribenick: achuter1
15:34:26 [DKA]
ScribeNick: achuter1
15:34:34 [DKA]
Scribe: Alan
15:34:57 [achuter1]
François: Headers can be interpreted only on basis of prior experience
15:35:21 [achuter1]
François: Often no way to get original UA header.
15:36:34 [achuter1]
Jo: Knowing that there is a mobile present, user requests desktop version
15:37:01 [achuter1]
EdC: We need the x-device header
15:37:27 [Jo]
PROPOSED RESOLUTION: Leave X-Device headers in as they add value
15:38:00 [achuter1]
EdC: then the provider can know what the requester really is.
15:38:17 [francois]
-1
15:38:18 [Jo]
PROPOSED RESOLUTION: Leave X-Device headers in as they add value and close ISSUE-289
15:38:20 [SeanP]
+1
15:38:22 [francois]
-1
15:38:32 [achuter1]
François: I would like to take them out
15:38:33 [rob]
0
15:38:41 [EdC]
+1
15:38:45 [DKA]
+1
15:39:38 [Jo]
[francois explains that his -1 is a formal objection and is not to be taken seriously]
15:39:58 [achuter1]
RESOLUTION: Leave X-Device headers in as they add value and close ISSUE-289
15:39:59 [DKA]
CLOSE Issue-289
15:39:59 [trackbot]
ISSUE-289 Should CT proxies send X-Device-* headers after having determined the content is not mobile-optimized? closed
15:40:14 [DKA]
q?
15:40:17 [DKA]
ack bry
15:40:18 [Bryan]
q-
15:41:09 [DKA]
ACTION-830?
15:41:09 [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
15:41:09 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/830
15:41:14 [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.]
15:45:01 [achuter1]
Bryan: would be provied by implementation
15:45:19 [SeanP]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2065?cid=2065
15:45:32 [achuter1]
dan: How to responmd to LC 2065
15:46:57 [achuter1]
Bryan: had resolution that was partial agreement with this.
15:49:12 [achuter1]
Dan: LC 2065 says that CT proxy must allow user possibility of obtaining transformed version, but our document gives a should not a MUST.
15:50:08 [francois]
s/provied/provided/
15:50:15 [achuter1]
Dan: LC 2065 secxond point in list says CT proxies must allow users possibility to turn off transformation.
15:50:32 [Jo]
CLOSE ACTION-830
15:50:32 [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
15:51:40 [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.
15:51:53 [DKA]
+1
15:51:55 [EdC]
+1
15:52:00 [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.
15:52:18 [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.
15:53:09 [DKA]
ACTION-850?
15:53:09 [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
15:53:09 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/850
15:53:21 [achuter1]
Jo: About Action 850
15:53:25 [DKA]
LC-2003?
15:53:26 [Jo]
--> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/850 ACTION-850
15:54:15 [achuter1]
Bryan: do we really need to say anything about whitelists?
15:54:19 [DKA]
CLOSE ACTION-850
15:54:19 [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
15:54:31 [achuter1]
Jo: Action was attempt to reintroduce it.
15:54:53 [francois]
ACTION-858?
15:54:53 [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
15:54:53 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/858
15:55:05 [DKA]
CLOSE ACTION-858
15:55:05 [trackbot]
ACTION-858 Find out if novarra has figures on whether users choose to proceed at the HTTPS interstitial page closed
15:55:16 [DKA]
ACTION-867?
15:55:16 [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
15:55:16 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/867
15:55:45 [DKA]
CLOSE ACTION-867
15:55:45 [trackbot]
ACTION-867 Look into an appendix with relevant normative statements of RFC2616 and report back to the group. closed
15:55:56 [DKA]
ACTION-886?
15:55:57 [trackbot]
ACTION-886 -- Jo Rabin to propose beefed up text on heuristics in respect of practice vs good practice -- due 2008-12-02 -- OPEN
15:55:57 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/886
15:56:05 [DKA]
CLOSE ACTION-886?
15:56:07 [DKA]
CLOSE ACTION-886
15:56:07 [trackbot]
ACTION-886 Propose beefed up text on heuristics in respect of practice vs good practice closed
15:56:16 [DKA]
ACTION-887
15:56:20 [DKA]
ACTION-887?
15:56:20 [trackbot]
ACTION-887 -- Jo Rabin to put a reference somewhere to the Best Practice about exploiting device capabilities -- due 2008-12-02 -- OPEN
15:56:20 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/887
15:56:31 [DKA]
CLOSE ACTION-887
15:56:31 [trackbot]
ACTION-887 Put a reference somewhere to the Best Practice about exploiting device capabilities closed
15:56:39 [DKA]
ACTION-889?
15:56:40 [trackbot]
ACTION-889 -- Jo Rabin to take the editorial comments in 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
15:56:40 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/889
15:56:49 [francois]
[relevant section removed for ACTION-887]
15:58:22 [DKA]
zakim, mute Bryan
15:58:22 [Zakim]
Bryan_Sullivan should now be muted
15:59:19 [achuter1]
[Eduardo's comments]
15:59:44 [achuter1]
Jo: changed "header fields" to "value of header fields"
16:01:13 [achuter1]
Jo: Will preface the first sentence in 4.1.5
16:01:43 [Jo]
ACTION: Jo tpo preface the first sentence in 4.1.5 with Aside from the usual procedures defined in [RFC 2616 HTTP]
16:01:43 [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].
16:03:20 [DKA]
PROPOSED RESOLUTION: Accept Jo's editorial changes detailed in email 13-March-2009 and close ACTION-927
16:03:37 [DKA]
PROPOSED RESOLUTION: Accept Jo's editorial changes detailed in email 13-March-2009 and close ACTION-889
16:03:42 [achuter1]
Jo: All Eduardo's comments dealt with.
16:03:53 [achuter1]
RESOLUTION: Accept Jo's editorial changes detailed in email
16:04:04 [DKA]
CLOSE ACTION-889
16:04:04 [trackbot]
ACTION-889 Take the editorial comments in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.html into account for next version of the draft closed
16:04:13 [DKA]
ACTION-892?
16:04:13 [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
16:04:13 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/892
16:05:58 [DKA]
ACTION-893?
16:05:58 [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
16:05:58 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/893
16:06:15 [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
16:06:15 [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.
16:06:26 [Bryan]
q+
16:06:40 [DKA]
ack bry
16:07:00 [DKA]
ACTION-850?
16:07:00 [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
16:07:00 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/850
16:08:44 [DKA]
ACTION-893?
16:08:44 [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
16:08:44 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/893
16:10:25 [achuter1]
Rob: Was about man-in-the-middle security
16:10:40 [achuter1]
Jo: Can't have a BP that requires a security audit.
16:10:47 [DKA]
CLOSE ACTION-893
16:10:47 [trackbot]
ACTION-893 Start putting together a set of guidelines that could help address the security issues triggered by links rewriting. closed
16:11:05 [achuter1]
Jo: Now a moot point after the link rewriting resolution.
16:11:14 [achuter1]
[break now]
16:25:08 [DKA]
[resuming]
16:25:18 [francois]
Scribe: Kai
16:25:52 [DKA]
ACTION-896?
16:25:52 [trackbot]
ACTION-896 -- François Daoust to stimulate discussion on the SHOULD NOT question ref mobile heuristics -- due 2009-01-20 -- PENDINGREVIEW
16:25:52 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/896
16:25:59 [DKA]
CLOSE ACTION-896
16:25:59 [trackbot]
ACTION-896 Stimulate discussion on the SHOULD NOT question ref mobile heuristics closed
16:26:05 [DKA]
ACTION-900?
16:26:05 [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
16:26:05 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/900
16:26:21 [DKA]
ACTION-901?
16:26:21 [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
16:26:21 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/901
16:27:07 [Kai]
SeanP: I think it is done
16:27:14 [francois]
http://www.w3.org/2009/01/20-bpwg-minutes.html#item04
16:28:33 [DKA]
CLOSE ACTION-901
16:28:33 [trackbot]
ACTION-901 Raise issue the thread he started on transforming mobile content entitled \"RE: [minutes] CT Call 6 january 2009\" closed
16:28:58 [DKA]
ACTION-902
16:29:01 [DKA]
ACTION-902?
16:29:01 [trackbot]
ACTION-902 -- Jo Rabin to summarise current discussions on https link re writing -- due 2009-01-27 -- PENDINGREVIEW
16:29:01 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/902
16:29:10 [DKA]
CLOSE ACTION-902
16:29:10 [trackbot]
ACTION-902 Summarise current discussions on https link re writing closed
16:29:16 [DKA]
ACTION 912?
16:29:16 [trackbot]
Sorry, bad ACTION syntax
16:29:20 [DKA]
ACTION-912?
16:29:20 [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
16:29:20 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/912
16:29:43 [EdC]
http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0058.html
16:30:31 [francois]
q+ to report on discussion with IETF
16:30:43 [Kai]
EdC: this has not been resolved on a call
16:31:10 [Kai]
Jo: I have added some text to EdC proposed text
16:31:50 [DKA]
q?
16:31:54 [DKA]
ack franc
16:31:54 [Zakim]
francois, you wanted to report on discussion with IETF
16:31:57 [Kai]
Jo: do you, EdC, have a problem with my text
16:31:59 [Kai]
EdC: no
16:32:23 [Kai]
francois: i was asked to join a liaison call with IETF
16:33:10 [Kai]
...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.
16:33:53 [Kai]
...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
16:34:28 [Kai]
...we need solid use cases. On the naming we can move forward with the X- prefix
16:35:12 [DKA]
PROPOSED RESOLUTION: adopt the text as proposed bt Eduardo and modified by Jo regarding X- prefix.
16:35:16 [achuter2]
achuter2 has joined #bpwg
16:35:31 [DKA]
PROPOSED RESOLUTION: adopt the text as proposed bt Eduardo and modified by Jo regarding X- prefix and close ACTION-912
16:35:53 [Kai]
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.
16:36:16 [Kai]
Jo: what is the problem here?
16:36:35 [Kai]
francois: the header fields need to be registered in the IANA DB
16:37:02 [Kai]
...if we will have an objection we will have to convince them we need them
16:37:25 [Kai]
Jo: is that really necessary?
16:37:52 [Kai]
francois: there are two levels of registration. One is simple and does not require support by the IETF
16:38:01 [Kai]
EdC: there will be discussion
16:38:28 [Kai]
francois: they should appear in some list and moving them to the repository will then be harder
16:38:41 [Kai]
Jo: we will have disbanded by then
16:39:03 [Kai]
francois: we already recevied comments that this should not be in a W3C draft
16:39:18 [Jo]
s/we will have disbanded by then//
16:39:49 [Kai]
francois: we should action somebody to register this on the temporary registry
16:40:12 [Kai]
...to envoke grandfathering we need to find out how uses these header fields
16:41:21 [Kai]
rob: I think we can use them. It is default, but in practice they don't
16:41:49 [Kai]
Jo: can we ask francois to do this, knowing that we may run out of time to finish this
16:42:21 [Kai]
francois: I am not sure I agree. We cannot really move forward on something that is not fully defined
16:42:36 [Kai]
..if we use it we must define it
16:43:00 [Kai]
EdC: you ask to go through a process that make them deprecated and then have them removed
16:44:29 [Kai]
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
16:44:31 [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
16:44:44 [Kai]
EdC: there are some fields that have been temporary for a long time
16:45:06 [Kai]
SeanP: they also recommed X-forwarded
16:45:16 [Kai]
francois: it is related to proxy in general
16:45:30 [Kai]
..it has nothing to do with transformation
16:45:45 [Kai]
DKA: look at the proposal please
16:46:15 [Kai]
SeanP: what is difference between edc and jo's text/
16:46:33 [Kai]
EdC: Jo said we may or may not committ...
16:46:45 [EdC]
+1
16:46:51 [rob]
+1
16:46:51 [francois]
0
16:46:53 [DKA]
+1
16:47:15 [DKA]
+2
16:47:17 [SeanP]
+1
16:47:37 [Kai]
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
16:47:43 [Jo]
ACTION: daoust to progress registration of the X- headers irrespective his personal distate for the subject
16:47:43 [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].
16:48:57 [DKA]
ACTION-925?
16:48:57 [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
16:48:57 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/925
16:49:05 [DKA]
CLOSE ACTION-912
16:49:05 [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
16:49:19 [Kai]
francois: so far I found out that no two browsers behave the same
16:49:41 [Kai]
...what you can do with a client script depends on the browser
16:52:58 [Kai]
Jo: Matt points out the abstract is wrong and incomprehensible
16:53:26 [Kai]
Topic: further comments on the document
16:53:41 [Kai]
Jo: Matt points out the abstract is wrong and incomprehensible
16:54:27 [Kai]
Jo: we were told not to tell transforming proxy providers how to do their work
16:54:54 [Kai]
DKA: there could be informative guidance
16:55:23 [Kai]
..somebody want to write a good abstract?\
16:55:34 [Kai]
EdC: I'll do it
16:55:59 [Kai]
... with the gist of what is here and that it provides informative guidance
16:56:10 [Kai]
Jo: leave out the informative
16:56:15 [DKA]
ACTION Eduardo to write an abstract for CT.
16:56:15 [trackbot]
Created ACTION-929 - Write an abstract for CT. [on Eduardo Casais - due 2009-04-02].
16:56:21 [Kai]
..we'll leave that with Eduardo
16:57:09 [Kai]
Jo: next point is not completely implemented resolutions
16:57:35 [Kai]
...[going into LCs]
16:57:53 [Kai]
LC-2050
16:58:36 [Kai]
Jo: we wanted to change something in the scope section
16:59:15 [Kai]
...do we need to maintain these definitions? We did not define these concepts very formally because they are used lightly.
17:00:15 [Kai]
Jo: making the distinction is good
17:01:26 [Kai]
[we are talking about 2.2]
17:02:55 [Kai]
jo: i thought the mandatory heuristics mean that a no tranform is implied
17:02:59 [Kai]
...but it is not
17:05:12 [Jo]
PROPOSED RESOLUTION: Ref LC-2050 RESOLVE NO to expanidng the definitions and leave defininitons in place
17:05:22 [rob]
+1
17:05:26 [SeanP]
+1
17:05:28 [Kai]
RESOLUTION: Ref LC-2050 RESOLVE NO to expanidng the definitions and leave defininitons in place
17:05:42 [Kai]
Topic: LC-2023
17:06:10 [Kai]
Jo: i put in a note here [reading note]
17:06:17 [Kai]
...rather than what I was mandated to do
17:06:47 [Kai]
...resolution was already taken
17:07:01 [Kai]
Topic: LC-2084
17:07:30 [Kai]
Jo: Resolution was taken
17:07:38 [Kai]
francois: I did provide this and can reprovide
17:07:53 [Kai]
...Jo has already reinserted it
17:09:09 [Kai]
francois: it was on receiving http headers
17:09:28 [Kai]
Jo: so no further action required
17:09:49 [Kai]
Topic: LC-2047
17:10:13 [Kai]
[viewing the LC]
17:10:35 [Kai]
Jo: what did we resolve?
17:10:47 [Kai]
[viewing]
17:11:38 [Kai]
Jo: is this clear without a diagram?
17:11:55 [Kai]
...if I add one will it help?
17:12:08 [Kai]
...perhaps we should scrap the idea
17:12:18 [Kai]
EdC: is there a text on what it is called?
17:12:27 [Kai]
Jo: yes there is
17:12:36 [Kai]
[viewing]
17:12:43 [Kai]
1.3 Scope
17:13:02 [Kai]
Jo: mumbles into his non existing beard as he reads the section
17:13:21 [Kai]
..no action
17:13:32 [Kai]
Topic: LC-2053
17:13:44 [Kai]
DKA: we clarified that yesterday
17:13:58 [Kai]
EdC: it seems closely linked ot hte normative heuristic
17:14:05 [Kai]
Jo: lets close it
17:14:30 [Kai]
Jo: LC-2040 done
17:14:46 [Kai]
DKA: should we send a note to the commenter?
17:15:09 [Kai]
francois: by the time we send the response we will be done
17:15:33 [Kai]
Topic: LC-2044
17:15:40 [Kai]
Jo is mumbling again
17:15:56 [Kai]
[viewing]
17:16:13 [Kai]
DKA: we do this
17:16:43 [Kai]
EdC: section 4.1.3 is completely different
17:16:53 [Kai]
francois: we discussed this in Mandeljeu
17:17:09 [Kai]
...we removed the normative part on detecting http browser request
17:17:25 [Kai]
...we are now talking about it in a normative way
17:17:39 [Kai]
Jo: the resolution then seems to have changed
17:18:00 [Kai]
Topic: LC-2044
17:18:03 [Kai]
Jo: all done
17:18:10 [Kai]
Topic: OPES
17:18:25 [Kai]
Jo: I put some wording in
17:18:38 [Kai]
...we need to review
17:19:07 [Kai]
..we were asked to note that we refer to IAB, about two party consent
17:19:36 [Kai]
..which we did
17:19:54 [Kai]
...is not really dangling then
17:20:17 [Kai]
Topic: Rotan's point
17:21:02 [Kai]
..about the CT Doc missing a statement about role of main parties ...etc.
17:21:09 [Kai]
Jo is mumbling
17:22:02 [Kai]
Jo: we used to say in the doc in previous version that the principles operatr similar to CSS
17:22:15 [Kai]
... in that the user can override
17:23:15 [Kai]
SeanP: I found the statement
17:23:31 [Kai]
...it was in June
17:24:24 [francois]
-> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080606#sec-proxy-control CT former draft with control
17:25:05 [Kai]
[viewing coupled with mumbling]
17:25:21 [Kai]
Jo: I thought we had something about CSS
17:25:26 [SeanP]
http://www.w3.org/TR/2008/WD-ct-guidelines-20080414/#sec-control-conflicts
17:26:01 [Kai]
Jo: if nobody thinks its useful lets move on
17:26:11 [Kai]
DKA: I think it would be useful in the intro
17:26:30 [Kai]
..especially with regard to respect to each others choices
17:27:08 [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
17:27:08 [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].
17:27:17 [Zakim]
-Bryan_Sullivan
17:27:19 [Zakim]
-berners_lee_at_google
17:27:20 [Zakim]
Team_(bpwg)15:01Z has ended
17:27:21 [Zakim]
Attendees were Bryan_Sullivan, berners_lee_at_google
17:27:32 [francois]
RRSAgent, draft minutes
17:27:32 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/26-bpwg-minutes.html francois
17:27:53 [Kai]
jo: done with this then
17:28:02 [Kai]
Topic: Editorial notes
17:28:13 [Kai]
Jo: we have done some, just making sure...
17:28:31 [Kai]
4.1.5
17:28:59 [Kai]
Jo: goes back a long way....
17:29:23 [Kai]
...it is more likely that the accept header will cause heuristic responses
17:30:02 [Kai]
...if we can say that alteration of the UA Header field doesn't achieve anything then we can leave it
17:30:13 [Kai]
rob: it is hard to prove. Will be in the long tail.
17:31:16 [Kai]
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
17:31:44 [Kai]
rob: during the browser wars this became common place and they are still there in the long tail
17:31:57 [Kai]
..it is not in mobile adapted pages
17:32:19 [Kai]
francois: is this just for 406 error code?
17:32:44 [Kai]
jo: if we say you can ignore 406 then what other mechanism do we offer CPs?
17:33:12 [Kai]
...what we are doing is being helpful in saying that a site needs a browser revision
17:33:43 [Kai]
...we may make it difficult for them
17:34:15 [Kai]
... for example for security reasons a CP may not want to serve content
17:34:33 [Kai]
...if with a 406 you rewrite the header, what can the CP do?
17:34:53 [Kai]
DKA: so legitimate uses of 406...
17:35:03 [Kai]
francois: a bit different from the note here
17:35:27 [Kai]
SeanP: this sounds theoretical
17:35:36 [Kai]
EdC: I have done this...and with a bank
17:35:58 [Kai]
....they did not want to take liability with anything else
17:36:31 [Kai]
francois: is one way out to not allow to change the UA ?
17:36:48 [Kai]
Jo: I don't think it works
17:39:17 [Kai]
DKA: can we say don't pay attention to 406?
17:40:03 [Kai]
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
17:40:23 [Kai]
DKA: ideally send a 406, in reality an errorpage with 200 code
17:40:43 [Kai]
...it is up to the provider or CT proxy provider
17:41:08 [Kai]
rob: in a case where they really don"t want to, won't they send a 403?
17:41:22 [Kai]
Jo: we must be careful not remove choices for CPs
17:41:45 [Kai]
...so we should put a note on using 403 in there
17:41:49 [DKA]
q?
17:42:32 [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
17:42:32 [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].
17:43:26 [Jo]
ACTION: Jo to specify what he means by the USer Agent editorial note under 4.1.5
17:43:26 [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].
17:44:34 [Kai]
Jo: 4.1.6.1
17:44:47 [Kai]
about the via header
17:45:03 [Kai]
francois: it just shows that there is a CT proxy active
17:45:10 [Kai]
Jo: ok
17:45:18 [Kai]
4.2.9
17:45:52 [Kai]
no it is 4.2.7
17:46:13 [Kai]
Jo: need to do some reorganzing here
17:46:32 [Kai]
4.2.8
17:46:48 [Kai]
Jo: do we also mean other legacy WML content?
17:47:21 [Kai]
francois: in the rest we don't talk about other types, but yes do mean it
17:47:44 [Kai]
EdC: you can only determine the type, but you can't look in it
17:48:01 [Kai]
Jo: remain silent on it then
17:48:14 [Kai]
5.0
17:48:48 [Kai]
seungyun: this section is fine for me (had a question regarding an older version(
17:50:00 [Kai]
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
17:50:24 [Kai]
SeanP: operatos will deploy this...will they want to make it available for anybody
17:52:41 [Kai]
Kai: CPs will not leave this open to the public
17:53:12 [Kai]
seungyun: is transformed content still mobileOK?
17:53:26 [Kai]
....it should be aligned with mobileOK
17:53:47 [Kai]
Jo: we have touched upon this and then stepped back from it. Difficult to say something meaningful
17:53:56 [Kai]
seungyun: how do we test then?
17:54:43 [Kai]
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.
17:55:03 [Kai]
francois: can you think of a wording to solve this?
17:55:05 [Kai]
Jo: no
17:55:23 [Kai]
SeanP: You can put in something like "reasonable"
17:56:29 [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
17:56:29 [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].
18:00:37 [Kai]
I think this section already expresses openness
18:03:09 [Jo]
[reasonable and non-discriminatory]
18:03:22 [Kai]
[discussion this needing something to prevent unreasonable hindrances to fulfillment]
18:03:36 [Kai]
Section E
18:04:02 [Kai]
no, D 1.3.2
18:04:47 [Kai]
Jo: this is about thematic consistency
18:05:46 [Kai]
...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.
18:06:37 [Jo]
ACTION: Jo to try to draft another doc to the TAG about D.1.3.2
18:06:37 [trackbot]
Created ACTION-934 - Try to draft another doc to the TAG about D.1.3.2 [on Jo Rabin - due 2009-04-02].
18:07:35 [Kai]
Jo: that's it
18:08:12 [Kai]
rob: I have one more question. Can"t find the reference in OPES about two party consent
18:08:51 [Kai]
francois: OPES states that we should aim at two party consent but one party consent is enough
18:09:17 [Kai]
...there are other guidelines, from which Jo infered, that state two party consent is needed
18:11:52 [francois]
http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0052.html
18:16:01 [Kai]
Jo: where to go with this?
18:16:12 [Kai]
EdC: we already did take a resolution on it
18:16:32 [Kai]
rob: the dialog around it mentions two party consent
18:17:23 [Kai]
Jo: I believe as we say later on that one party consent is not enough. so what do they mean by "by itself"?
18:17:37 [Kai]
EdC: does only what opes says has value?
18:17:53 [Kai]
Jo: we can say more but should not contradict it
18:17:58 [francois]
RRSAgent, draft minutes
18:17:58 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/26-bpwg-minutes.html francois
18:22:17 [adam2]
k
18:22:21 [rob]
rob has left #bpwg
18:22:27 [francois]
RRSAgent, bye
18:22:27 [RRSAgent]
I see 10 open action items saved in http://www.w3.org/2009/03/26-bpwg-actions.rdf :
18:22:27 [RRSAgent]
ACTION: Dan and Jeffs to wander the highways and byways of SVG and Canvas and cook something up for the group's approval [1]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T10-27-59
18:22:27 [RRSAgent]
ACTION: daoust to ascertain the availability of tests that ensure that same origin policy conformance, when implemented in this way, can be tested [2]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T11-42-10
18:22:27 [RRSAgent]
ACTION: Jo to inser sections under proxy decision to transform a. to specify SHOULD NOT in the presence of the features listed at http://www.w3.org/2009/03/10-bpwg-minutes.html and b. to include the current cullets listed as heuristics [3]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T14-38-01
18:22:27 [RRSAgent]
ACTION: Jo tpo preface the first sentence in 4.1.5 with Aside from the usual procedures defined in [RFC 2616 HTTP] [4]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T16-01-43
18:22:27 [RRSAgent]
ACTION: daoust to progress registration of the X- headers irrespective his personal distate for the subject [5]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T16-47-43
18:22:27 [RRSAgent]
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 [6]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T17-27-08
18:22:27 [RRSAgent]
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 [7]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T17-42-32
18:22:27 [RRSAgent]
ACTION: Jo to specify what he means by the USer Agent editorial note under 4.1.5 [8]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T17-43-26
18:22:27 [RRSAgent]
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 [9]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T17-56-29
18:22:27 [RRSAgent]
ACTION: Jo to try to draft another doc to the TAG about D.1.3.2 [10]
18:22:27 [RRSAgent]
recorded in http://www.w3.org/2009/03/26-bpwg-irc#T18-06-37