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