00:20:56 RRSAgent has joined #bpwg 00:20:56 logging to http://www.w3.org/2008/03/03-bpwg-irc 00:21:00 Zakim has joined #bpwg 00:21:54 SL: First time having a W3C meeting in Korea. 00:21:58 Rotan has joined #bpwg 00:26:33 Meeting: BPWG F2F Seoul - 1st day 00:26:56 Chair: DKA, Jo 00:27:19 jcantera has joined #bpwg 00:27:44 wonsuk has joined #bpwg 00:28:11 Date: 3 March 2008 00:32:16 scribenick: bryan 00:32:24 Topic: Agenda 00:34:05 DKA: for BP2, propose to use the sessions for live editing 00:34:47 DKA: BP2 will likely spill over to 2nd day 00:35:26 DKA: any other changes to agenda? 00:37:37 Jo: the accessibility doc review may be difficult with Alan missing; we might reuse that time for the other agenda items. Also MobileOK TF is not represented, so BP2 could continue. 00:38:01 Present: DKA, Jo, MartinJ, jcantera, rob, SeanP, Bryan, francois, wonsuk, JonathanJ, SeungyunLee, KangchanLee 00:40:35 Present+ Minkyo 00:41:10 sunghan 00:41:13 Present+ SungHan 00:41:26 Agenda: http://docs.google.com/Doc?docid=dd3jk8v_89f6vrqk9w&hl=en 00:41:42 Present+ Soonho_Lee 00:42:02 Topic: CT - Introduction/Guidelines (1 and 2) 00:42:32 Present+SunYoung 00:42:40 -> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080227 CT draft 00:43:11 Francois: update on the status, overview of goals 00:45:03 Francois: some CT proxies have been deployed in the market, to enable whole web access from mobile devices; problems are lack of consistent rules, and CP's complained 00:45:26 Francois: So W3C started a program to set expectations on CT proxy behavior 00:46:16 Francois: After a year, we need decisions, e.g. on the scope re use of new technologies e.g. new HTTP headers 00:47:10 Francois: CT will probably need more flexible ways in the future, so we decided to stick to existing technologies. Thus the current draft we are reviewing. 00:48:28 Francois: "Summary of requirements" section is an overview for all entities in the delivery chain. 00:49:16 Francois: An assumption is that legacy browsers are used, thus the user (and not user-agent) is in the loop for any controls of CT behavior. 00:49:23 [note to editor to correct section 2.1 where it says HTTP between user and user agent 00:49:38 thanks to DKA and francois for pointing this out!] 00:50:11 Francois: So the requirements are a little outdated, with the current scope, and cannot be fulfilled with current technologies. But it is a good hint for the future. 00:50:55 q? 00:51:04 Francois: "Types of Proxy" are what HTTP defines, included here to establish the terms. 00:51:52 Jo: Wonders if we can revisit the decision on the CT entity being a "proxy". 00:52:10 [the proxy is indeed a proxy not a user agent extension or a gateway] 00:52:29 q+ 00:52:44 q? 00:53:07 ack seanp 00:53:27 Francois: We do not view the CT proxy as an user-agent extension (masquerader), but as a simple intermediary. 00:53:41 q+ 00:53:50 ack j 00:53:59 Sean: Are we leaving the specialized client/'server solutions e.g. Opera Mini, out of the scope of these guidelines? 00:54:49 Jo: We are addressing how HTTP path entities should behave. 00:55:10 q+ to suggest it is out of scope 00:55:14 Francois: We could consider Opera Mini as two different parts. 00:55:16 q+ 00:55:19 q+ 00:55:34 Francois: Opera Mini is both. 00:56:03 q+ to suggest that we need to make reference to the principles, which are to facilitate the communication between the user and the content provider 00:56:04 Dan: It is a different animal, an integrated system built in a special way. 00:56:09 q? 00:56:09 ack d 00:56:10 DKA, you wanted to suggest it is out of scope 00:56:14 ack br 00:56:19 q? 00:56:23 q? 00:56:25 jo 00:56:27 jo beep 00:56:54 q+ to add that we should raise an issue on this and askOpera 00:57:05 q? 00:57:07 ack seanp 00:57:14 q+ to add that there is something about user choice of user agent 00:57:17 Bryan: Opera Mini is an application with specialized behavior, and does not necessarily use HTTP. 00:57:53 q? 00:57:56 ack jo 00:57:56 jo, you wanted to suggest that we need to make reference to the principles, which are to facilitate the communication between the user and the content provider and to add that we 00:57:59 ... should raise an issue on this and askOpera and to add that there is something about user choice of user agent 00:58:17 Sean: It does operate different from normal browsers, and does appear to use something other than HTTP. But Novarra has similar experience with clients that do use HTTP. 00:59:04 Jo: We should ask Chaals about his attitude on this. 00:59:37 q? 01:00:04 Jo: We could get distracted by considering all the types of solutions, and if we consider on the normal proxy, we can focus on the case where the user has not made an active choice (e.g. to use an specialized browser). 01:00:08 ack jcantera 01:00:14 act 01:00:20 s/act// 01:00:48 sylee has joined #bpwg 01:00:58 q+ 01:00:59 ACTION: Patterson to raise and issue on the distinction between a CT proxy and (say) Opera Mini 01:00:59 Created ACTION-678 - Raise and issue on the distinction between a CT proxy and (say) Opera Mini [on Sean Patterson - due 2008-03-10]. 01:01:00 Jose: Guidelines of the CT TF should cover all the cases including specialized cases and normal browsers. 01:01:14 francois_ has joined #bpwg 01:01:19 q? 01:01:26 Jo: Doesn't disagree, just wants to discuss it later. 01:01:41 ack s 01:01:43 q+ 01:01:56 q? 01:01:59 ack br 01:01:59 ack b 01:02:33 RRSAgent, draft minutes 01:02:33 I have made the request to generate http://www.w3.org/2008/03/03-bpwg-minutes.html francois_ 01:03:21 Bryan: Thinks that some usability aspects will be useful nonetheless even if we don't address any client-server enhancements e.g. that are enabled by HTTP extensions. 01:05:06 Francois: Going on to "control by the user", re ability of client to use "no-transform" directive to control the CT proxy behavior. This is a limited control that new browsers could leverage. 01:06:52 Jo: Back on 2.4 ("types of transformation"), suggests that we clarify the scope to avoid giving mixed messages on what a proxy should/should-not do. 01:08:09 Francois: We don't mention those special types of transformation later. 01:09:06 [jo points out that this has gone from the document for now, but is likely to come back in the form of POWDER descriptions] 01:09:10 Francois: For the moment we don't have any guidelines on how to use particular types of special transformation. We might link the transformations to other documents later on. 01:09:49 Francois: Leaving "controlled by the server" as is for the time being. 01:10:35 q+ 01:10:41 q? 01:10:50 Topic: CT - no-transform directive in Request (3.1.1) 01:10:55 Francois: In Section 3, the most common control is to use "no-transform" to affect CT proxy behavior. 01:11:18 q- 01:11:19 q+ 01:11:50 ack jo 01:12:00 Francois: We can't expect this from legacy browsers, but there could be out-of-band arrangements to control the behavior. 01:12:49 Jo: Re section 3.1.1, we have an issue for the CT proxy to act transparently for non-browsers. 01:12:59 q+ 01:13:05 ack bryan 01:13:14 RH has joined #bpwg 01:13:41 q+ 01:14:02 q? 01:14:10 q+ 01:14:13 ack martin 01:14:22 q+ 01:14:35 q? 01:14:37 Bryan: Use of proxies for non-browsers is a common deployment, and must be addressed. 01:15:26 Martin: the guidelines should be firmer, and stated such that the CT proxy should be transparent unless it can be sure that the user agent is a browser, e.g. using user-agent lists. 01:15:30 ack rob 01:15:37 q? 01:15:54 q+ to suggest that Martin 01:16:06 ack seanp 01:16:19 q+ to add should take an action to express his point as a proposed text 01:16:19 q? 01:16:26 Robert: Its a difficult problem, but does need to be addressed since all HTTP is likely going thru the proxy. 01:17:05 ack jo 01:17:05 jo, you wanted to suggest that Martin and to add should take an action to express his point as a proposed text 01:17:38 ACTION: Martin to propose text re browser identification: para 2 of sectio 3.1.1 01:17:38 Sorry, amibiguous username (more than one match) - Martin 01:17:38 Try using a different identifier, such as family name or username (eg. mharris2, mjones4) 01:17:49 Jo: Suggests that Martin take an action to propose text for 3.1.1 based upon the discussion, 01:17:49 q? 01:18:06 ACTION: Jones to propose text for para 2 of 3.1.1 01:18:06 Created ACTION-679 - Propose text for para 2 of 3.1.1 [on Martin Jones - due 2008-03-10]. 01:18:57 Topic: CT - Proxy decision to Transform (3.1.2) 01:18:58 Francois: Moving on to 3.1.2 "proxy decision to transform", these are the ways the proxy can know what to do. 01:19:51 Jo: As editor, unclear how to take the section forward. 01:20:04 q+ 01:20:24 Francois: It's just a collection of options on how to control the behavior. 01:20:26 ack rob 01:21:08 Rob: It's a SHOULD, thus there is a list of things to consider, and the overall is helpful. 01:21:55 minkyo has joined #bpwg 01:22:36 q+ 01:23:29 q+ 01:23:51 Francois: About the editorial note, its similar to what we would write if we were considering the browser extension role for the CT proxy. 01:24:17 ack SeanP 01:24:20 ack jo 01:24:52 Sean: What was intended by the call comment that prompted the note, was that the user may want a specialized adaptation of the desktop content. 01:25:01 q? 01:26:18 Jo: Not altering the headers is mandated unless its essential to what the user wanted. 01:26:25 q+ 01:26:40 ack se 01:26:47 q? 01:27:20 sylee_ has joined #bpwg 01:27:35 Sean: In the last CT call Aaron mentioned for legacy servers a 200 response which says "use a different browser" is not always clear as an error indication to the user. 01:28:39 Francois: Moving on, re the open question on request bodies, it was mentioned that the CT proxy may modify body encoding if the body does not match that requested by the server. 01:28:51 q+ 01:29:07 q+ 01:29:26 Francois: Not convinced there is a real problem to be mentioned here. 01:30:20 Jo: Confused about this; not sure what the problem is that is not general; can the server mandate a specific request body for any specific action 01:30:24 ack j 01:30:28 ack b 01:31:22 RH has joined #bpwg 01:31:42 Bryan: See this as a corner case, not a normal proxy behavior, and maybe something for specialized service access. 01:31:42 q+ 01:31:57 Francois: Suggests we ask Aaron for more input,. 01:32:08 q+ 01:32:19 ack rob 01:32:23 Jo: We could say that the body should not be altered unless there is a specific mobile use case being addressed. 01:33:21 Rob: The proxy may modifying a form as needed, e.g. to break a page into subpages. 01:33:53 Francois: How does that work in practice, e.g. the pages and form functions are split up? 01:34:20 Rob: Yes, that's how it happens. 01:35:04 Ron: The handset sent form may be modified by the CT proxy if necessary for adapting the page. 01:35:07 q- 01:36:37 q+ 01:36:43 Francois: Other notes need to be considered re breaking a page into subpages which are locally served by the proxy. 01:37:32 Jo: The choices for this document is to say whether the entity body should be modified or not, or being more detailed eg. should not do (a) unless (b). 01:39:05 ack s 01:39:15 We do form splitting. Have found that user perception of goal/purpose/intent of form can be affected by how much of the form can be seen at one time. So it's more than a pure technical issue. 01:39:18 q+ seanP 01:39:27 Bryan: The two cases are being discussed; a single request-response with modification, and a request that is delivered in pieces to the user, with possible form modifications as needed to make the page work. 01:40:16 Dan: Would like to see if any CT discussions we are having resonates for the Korean market, and what input they will have. 01:40:19 People tend to read forms first. Then fill them in. By limiting the form (or "wizarding" it) you change the way a user perceives the form. It's psychology... :) 01:41:25 zakim, pingme at 0200 01:41:25 I don't understand 'pingme at 0200', jo 01:41:35 zakim, ping me at 0200 01:41:35 I don't understand 'ping me at 0200', jo 01:41:45 zakim, ping me in 19 mins 01:41:45 ok, jo 01:41:59 [coffee break] 01:51:15 soonho has joined #bpwg 02:00:35 Scribe: Dan 02:00:43 ScribeNick: DKA 02:00:45 jo, you asked to be pinged at this time 02:01:14 q? 02:02:18 Sean: going back to the talk of forms - transforming the request - at one point the novarra server would change the form to a more streamlined version - for example, integers refering to each field in the form - and that would get sent back to the proxy and the proxy would change it back to what the original form id values were. 02:02:31 ack se 02:02:38 Sean: So you're basically changing the form on the way down and changing it back to the original on the way up. 02:03:15 [fancois asks for examples of this behavior] 02:03:17 Francois: could we have an example of that? 02:03:25 s/fancois/francois/ 02:03:27 Sean: I think we can do it. 02:03:33 Rob: I could do a pseudo-code example. 02:03:38 jcantera has joined #bpwg 02:03:47 Francois: to see what's being done in practice 02:04:09 s/can/can't/ 02:04:35 ACTION: Rob to provide a pseudo-code example of form transformation for CT document. 02:04:35 Sorry, couldn't find user - Rob 02:05:00 ACTION: finean to provide a pseudo-code example of form transformation for CT document. 02:05:00 Created ACTION-680 - Provide a pseudo-code example of form transformation for CT document. [on Robert Finean - due 2008-03-10]. 02:05:35 Jo: We need more text - we need something from Aaron. 02:05:37 Bryan_Sullivan has joined #bpwg 02:06:15 ACTION: daoust to ask aaron kemp for clarification of the character encoding issue 02:06:15 Created ACTION-681 - Ask aaron kemp for clarification of the character encoding issue [on François Daoust - due 2008-03-10]. 02:07:02 Francois: reaching the identified issue that needs to be addressed - how should the CT proxy behave when it has a request and it needs to forward it to the server. 02:07:55 Francois: one proposal is that it issues a HEAD request and analyze the response, then if it's still in doubt issue a GET request with the original headers and if it's still in doubt issue a GET request with altered headers. 02:07:56 jcantera has joined #bpwg 02:09:03 Francois: We'd like the CT proxy not to change the original headers. However, the CT proxies do that because they have to do this because many servers won't respond correctly when they get a mobile user agent string - they might respond with a 406 or they may respond with a 200 but none-the-less it's an error page saying they can't serve the page. 02:09:31 Francois: My POV on that would be to forget the HEAD requests. 02:09:43 q+ to explain why the HEAD request is there 02:11:03 Francois: From the server's POV there should be only one request. An example of why this is necessary is when the server computes statistics - another example would be for example confirmation URIs or GET requests with parameters which change a state [and therefore double-requesting these URIs would be problematic]. 02:11:53 Francois: I think when you send a HEAD request to the server, the server will just perceive it as a GET request and only return the headers - so the underlying code would be excecuted. Needs to be checked in practice. So issuing a HEAD request is _as harmfull_ as issuing a GET request. 02:12:30 q+ 02:12:42 Francois: I suggest we only issue the request with the original headers and as a fallback issue with the altered headers but that would mean we have a way to determine when the response fromt he server is unsuitable. 02:14:02 Jo: The HEAD request is to retreive meta information in the resource. Couple of problems here. Chicken and egg situation here - we need to know meta information about resources without retreiving it so we should do some research on whether using HEAD would be harmful. Because HEAD is in HTTP specifically for this very purpose. 02:14:18 This is the case for Apache. 02:14:24 Francois: You want to check that a HEAD request would be processed on the server as if it were a GET request. 02:14:37 Apache generates the content, then throws it away as it responds to HEAD. 02:14:56 Jo: Yes - Although we probably need to kick this one upstairs to the TAG. 02:15:39 Francois: I'll take an action to try it with different servers -- how it would be handled with Apache and IIS - with JSP, ASP, PHP, etc... 02:16:14 q+ 02:16:15 ACTION: Francois to write some simple tests for well-known server environments for how they deal with HEAD requests. 02:16:15 Sorry, couldn't find user - Francois 02:16:17 q? 02:16:21 jcantera has joined #bpwg 02:16:21 ack j 02:16:21 jo, you wanted to explain why the HEAD request is there 02:16:23 WSGI systems replace HEAD with GET when passing on requests. 02:16:29 ack seanP 02:17:05 q+ 02:17:06 Sean: The idea of making multiple requests seems overly complicated to me - the simplest way would be make one request, allow the headers to be changed and include the change header information in the request. 02:17:07 q? 02:17:13 ack Bry 02:17:14 ack b 02:17:32 Bryan: Are we assuming that the head request is coming from the client? 02:17:40 Francois: No it's from the proxy. 02:18:04 Bryan: because HEAD requests sometimes do come from the client - should the CT proxy simply pass these through? 02:18:10 See 3. at http://groups.google.com/group/modwsgi/msg/289730b262df5bca 02:18:14 Jo: That's an open question. 02:18:22 Bryan: What's the intervention in the case of HEAD then? 02:18:54 Francois: CT proxy with a HEAD request - it should do nothing on a HEAD request - just add the VIA header. 02:19:09 Please read 3. on the link above. 02:19:28 q+ 02:19:35 Bryan: Typlically the HEAD request is sent becaus the client needs to know certain things - because it wants to determine if the response is too large for example. I'm not sure if turning the HEAD request into a GET request would be appropriate. 02:19:49 Francois: I don't think the CT proxy should do anything with a HEAD request. 02:20:04 Bryan: Other than potentially changing the user agent header - to maintain consistency. 02:20:06 q? 02:20:12 ack rob 02:21:03 Rob: the HEAD request is used from handsets a lot but tends to be used for cache management of images. We do have to be able to adapt the HEAD request - in OpenWave's case, we're tokenizing the URLs in order to save space so we have to de-tokenize the URL. 02:21:32 I agree. Have observed HEAD/GET equivalence in many Web servers. 02:21:55 Rob: A lot of web servers do exactly the same for a HEAD as well as a GET. Confirmation strings that are sent in Email messages need to be GETs because they're sent in Email - although they should be POST. 02:22:13 Rob: I think the two-phase approach - tasting the content - is beneficial. 02:22:28 Francois: The cool thing about about that is we wouldn't need to change the user agent. 02:22:42 q? 02:22:50 Rob: There's still the business about tokenizing URLs so you might change requests just not user agents. 02:22:53 ack m 02:23:03 Martin: I'd like to echo what Rob said about the two-phase approach [content tasting]. 02:23:47 sylee_ has joined #bpwg 02:24:21 Martin: 2ndly on turning a HEAD request into a GET request - a device might be issuing a HEAD request in order to find out how large the response is - so servers must execute the code in order to know this - but PROXYs would need to issue a GET request as well so it can get the content and attempt to transform it. 02:24:34 Martin: So there's a valid use case for converting a HEAD into a GET in the proxy. 02:24:35 q+ 02:24:49 ack Br 02:25:27 Bryan: Most cases where the user agent would use a HEAD, you wouldn't expect the transforming proxy to signifigantly altter the size (eg media). 02:25:43 Bryan: Are you saying it would be the optimized form the user agent would store? 02:25:46 Martin: yes. 02:26:20 Bryan: so the CT proxy should modify the content size in the HEAD response to the optimized size but unless it actually got the content it wouldn't know that. 02:26:23 Martin: right. 02:26:42 Bryan: But the statefulness effect of issuing a GET could be signifigant. 02:27:07 Martin: the CT proxy could help do this by not issuing another GET request when the user agent actually did GET the content. 02:27:52 Francois: 2 discussions here: one is how it should behave with a GET request and one on how it should behave with a HEAD request from the client - which we hadn't considered before. 02:28:18 Francois: This should be in scope - we need to do something about such a comon case. 02:29:23 DKA: Let's try to bottom out the first discussion and action someone to write a proposal on the HEAD issue. 02:29:34 http://osdir.com/ml/apache.mod-perl/2003-01/msg00192.html 02:29:35 ACTION: Martin to write a proposal on the HEAD request handling. 02:29:35 Sorry, amibiguous username (more than one match) - Martin 02:29:35 Try using a different identifier, such as family name or username (eg. mharris2, mjones4) 02:29:44 ACTION: Martinj to write a proposal on the HEAD request handling. 02:29:44 Sorry, couldn't find user - Martinj 02:29:51 ACTION: Martin Jones to write a proposal on the HEAD request handling. 02:29:51 Sorry, amibiguous username (more than one match) - Martin 02:29:51 Try using a different identifier, such as family name or username (eg. mharris2, mjones4) 02:30:21 q+ 02:30:57 q+ to add wondering if the two approaches can work in parallel 02:32:08 ACTION: Jones to write a proposal on the HEAD request handling. 02:32:08 Created ACTION-682 - Write a proposal on the HEAD request handling. [on Martin Jones - due 2008-03-10]. 02:33:03 q+ 02:33:06 Francois: the real question is: how can the CT proxy know when it needs to re-issue a request with an altered header. If the server returns a 406, it's easy. If it doesn't, you can't. 02:34:39 DKA: I suggest we say the server can issue a 406 and that's great but the CT proxy could also use its own heuristics to determine if it's an unacceptable response - because this is percisely the point on which CT proxy vendors differentiate. 02:34:52 Francois: Yes if that's what we agree. 02:34:57 ack rob 02:35:12 q+ 02:35:57 Rob: I agree with Dan. There's a lot fo complexity in tasting content and figuring out what kind of content it is is complex. Usually 406 is only ever returned if you do a POST instead of a GET and vice-versa. In terms of the two-phase approach and in terms of how you taste the content, it should be left up to the vendors. 02:36:24 Francois: I don't want to write the method - and it's the added value for the CT vendor. Sean would you be pleased with that/ 02:36:46 You can force a 406 on Apache with a particular pattern in POSTed HTML when mod_security is present in its default config. 02:37:21 Sean: Maybe - I wanted to bring up two things - one it can be difficult to determine if the reponse is a reasonable response, the other is the case where the user wants the desktop content - then it doesn't make sense to request the mobile content first if that's not what you want. 02:37:25 q+ 02:37:39 Jo: I think that this case is carved out above [in the Note above] 02:37:41 q? 02:38:30 Jo: this is going on to say - unless these carveouts apply - you should do this [tasting]. This will give content providers guidance on how tasting will occur. 02:38:46 ack jo 02:38:47 jo, you wanted to add wondering if the two approaches can work in parallel 02:38:50 ack martin 02:39:09 q+ you wanted to add wondering if the two approaches can work in parallel 02:39:43 q+ to wonder if the two approaches can work in parallel 02:39:43 +1 to Martin 02:40:07 Martin: Agree with Dan and Rob - the approach to allow CT vendors to have their own methods to determine if response is acceptable. But we should try to discourage 2nd requests unless necessary. We should discourage people from making 2 requests automatically and comparing the two responses, for example. 02:41:07 Martin: Caching the knowledge of responsiveness of the site to different header types - if it's know that the site is adapting - then it could start making requests using the altered headers the first time once it knows the non-altered response doesn't work. 02:41:29 q- 02:41:30 s/besice/beside/ 02:42:12 Jo: We need to come back to a point - about the a priori knowledge it has of server preferences. 02:42:46 q? 02:43:08 ack jo 02:43:08 jo, you wanted to wonder if the two approaches can work in parallel 02:44:22 Jo: it seems that we could do something - submit the request with the genuine original headers by default but maybe introduce an optimization that you could provide alternative headers that say "if you're smart enough, I could be this if you want me to be." There doesn't seem to be a signifigant disadvantage tho there may not be an advantage. 02:45:03 Francois: This would only target new implementations that would know about the guidelines. I don't think we want servers in the future to know about multiple requests. It's agains the "one Web" approach. 02:45:14 Jo: Just because it's one web doesn't mean you don't have varrying representations. 02:46:02 Francois: I agree, but this is not a flexible enough mechanism to be useful in the future. What would be interesting would be for a client to define more percisely what it can be - possibly using labeling instead. It can't be easily extended. 02:46:10 Jo: It could be easily extended. 02:46:22 Jo: I don't think it's harmful but I don't know if it would be useful. 02:46:44 Jo: send the alternative user agent as the alternative... 02:46:51 q+ 02:46:53 ack dka 02:48:21 DKA: [speaks in support of sending the dual headers] 02:48:59 q+ 02:49:01 q+ 02:49:14 Jo: If you have a primary, secondary and teriary it may not be clear what the server has picked - if we said that there could be multiple user agent headers, we should write how the server should make that decision and how it should indicate what header it used back up the stream. 02:49:26 Sean: Why is it necessary to know how the decision was made. 02:50:26 Jo: On the basis of the input from Rob and Martin - once you've had a response from a particular origin server - which would determine your future behavior - so if you've put mutliple UA headers in and you don't know what the response was based on then you wouldn't have the knowledge. 02:50:32 Sean: you could always put them in though. 02:50:35 Jo: good point. 02:50:36 q? 02:50:38 ack se 02:50:44 ack br 02:52:19 Bryan: it's good to stick as much with existing technology, existing methodology. I'm not sure whether content providers will appriacte us complicating their lives to support this use case. The overhead of submitting 1 request vs. 2 reqeusts (the first time) is fairly minimal. I think it's a fairly complicated thing from a content provider perspective meeting a relative short term requirement. 02:52:25 Francois: I agree with Bryan. 02:52:26 PROPOSED RESOLUTION: Under 3.1.2 drop the HEAD request 02:52:26 +1 to Bryan 02:53:09 Francois: We agree with what is written here except for the HEAD request. 02:53:36 Jo: We should probably still have a justification for having removed it [but I suggest we remove it anyway.] 02:54:00 +1 02:54:02 + 02:54:05 +1 02:54:05 +1 02:54:07 +1 02:54:18 RESOLUTION: Under 3.1.2 drop the HEAD request 02:54:21 (Just observing, but I also agree) 02:54:41 Francois: 2 remaining points - emphasis on a priori knowledge 02:55:16 Francois: should we say something about a request to a URI may mean something about a request of a document "close to" that URI. 02:55:29 What does "close to" mean? 02:55:37 URIs are supposed to be opaque. 02:55:38 q+ 02:55:39 Jo: We should move on to that - what inference could be made... 02:55:40 q+ 02:55:46 ack rob 02:55:50 www.example.com/?id=12345 02:56:08 I could build a whole set of sites all using that example URI. 02:56:18 You have NO WAY to know what is or is not close. 02:56:41 You cannot assume that a URI has a "path" in it. 02:56:43 jo points out the authentication model which contradicts Rotan 02:56:48 Rob: You can't do it in the way you do authentication - once you're in a gateway mode, changing the content, handling cookies and javascript, you can find yourself jumping from domain to domain (for example for a sign-in) you have to keep on adapting in the same way. You have to have consistency during a session. 02:57:35 Respectfully disagree. 02:57:37 q? 02:57:46 ack d 02:58:17 DKA: I think the concept of user session comes into it. 02:58:18 q? 02:58:29 Jo: Um 02:58:37 q+ 03:00:23 Jo: As I understand what Rob is saying : in a page which is a composite of many different object you need to have consistency for how you deal with each item. But you need to have a priori knowledge of how servers handle requests. The fact that a particular page has references to other pages sure means you have to have the a priori knowledge from those other places as well... 03:00:27 q+ 03:00:39 ack rob 03:01:00 ack Br 03:01:01 Rob: If you're following a page and links off that page you should maintain consistency. But if you go to a new website starting from scratch you should taste content again. 03:01:51 Bryan: the basic concern I have over the notion of content tasting is that it's likely to break some services. It'll be very important for CT proxies to be intelligent enough to discover when things are breaking or at least to have a configuration of "don't do this for certain sites." 03:02:40 Bryan: Just because you get redirected from one place to another doesn't necesarilly mean you need to go taste the service from the new server. That presumption could break the operation of the overall data flow. The notion of content tasting has to be used very carefully. 03:03:01 Bryan: the service provider should know what sites are sensitive - for example regexp-specified URIs. 03:03:46 q+ 03:03:49 Jo: both Rob and Martin said thought that inferences of a sort could be made - the question remains open what are those inferences. 03:03:52 ack rob 03:04:13 Rob: They are - that there either is a mobile edition suitable for the user agent or there isn't. 03:04:55 Jo: what can we put in the document about under what circumstances they can be an inference made? What is the algorithm we could suggest or what are some clues we can give? 03:05:28 q+ 03:05:37 ack s 03:05:37 Jo: A CT proxy - if it visits landing page x and then it visits y, if the following relationship is true of x and y then it will assume that x and y have the same characteristics given no a priori information. 03:06:06 Sean: we're talking about 2 things - 1. what can we tell content providers 2. what can we do about servers that are out there. 03:06:19 s/no a/no other a/ 03:06:30 Bryan: I agree - the non CT-aware servers are the richest use case. 03:06:51 Jo: From the POV of the guidelines to CT proxies, what inferences are reasonable to make? 03:07:07 Scribe: Rob 03:07:15 ScribeNick: rob 03:08:05 Francois: I've no answer and we definitely need one... 03:08:56 ACTION: Finean to raise an issue on inferencing from the structure of the URI what assumptions to make about another from the point of view of the CT Proxy 03:08:56 Created ACTION-683 - Raise an issue on inferencing from the structure of the URI what assumptions to make about another from the point of view of the CT Proxy [on Robert Finean - due 2008-03-10]. 03:09:02 Bryan: eg if I request content in 2 forms and my hand gets slapped in 2nd form, what should I infer? 03:09:51 Francois: eg example.com/x and then example.com/x/y -- are they really connected? 03:10:12 (Has anyone ever considered the HTTP 1.1 "OPTIONS" request? It was designed to be extensible.) 03:10:15 q+ 03:10:44 ack SeanP 03:10:45 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2 03:11:09 q+ 03:11:18 Sean: it's possible a solution works for all - but it's more likely vendors will come up with different solutions 03:12:07 Jo: if we wnat to tell CT-aware content something then perhaps POWDER is the answer 03:12:17 s/wnat/want 03:12:44 Bryan: what's the advantage of inferring future behaviour? 03:13:26 ... minimising n of hits? making it work at all? 03:14:17 Jo: specifically it's bullet "any a priori knowledge"... in sec 3.1.2 03:15:03 q+ 03:15:04 q? 03:15:06 ack bry 03:15:06 Bryan: and might we note the a priori knowledge is user-specific 03:15:06 ack bry 03:15:08 ack dka 03:15:35 q+ 03:15:45 q? 03:15:50 ack seanp 03:15:54 q+ seanp 03:15:55 Dan: and note it could be vendor-specific and needn't be detailed too much here 03:15:59 q+ 03:16:19 ack Bryan_Sullivan 03:16:42 Bryan: most valuable a priori knowledge will be pre-configured by operators and vendors 03:16:45 q- 03:16:53 q+ 03:17:06 ... and by content authors with POWDER 03:17:50 q? 03:18:22 Sean: I don't see a particular way to describe this other than say it's up to vendors 03:18:27 q+ 03:18:45 Dan: 2 specific use-cases come to mind: 03:19:14 ... one is you think you know about a website then a different User-Agent works differently 03:19:18 +1 to Dan (we're seeing demand for iPhone-specific responses) 03:19:23 [The server should have a vary:* in that case, Dan] 03:19:34 ... (eg iPhone-aware site) 03:20:13 q+ to sya that surely this is a general caching problem 03:20:28 ack d 03:20:29 ... the other one is where the user has a "mobile/desktop edition preference" that the origin server has no knowledge of 03:20:49 q? 03:21:30 s/has no knowledge of/knows about but the CT proxy doesnt 03:21:34 The "vary" should indicate all the headers upon which it made its response decisions. 03:21:44 or * 03:21:45 s/that the origin server has no knowledge of/with the ORIGIN website 03:21:57 q? 03:22:16 But user prefs might be outside of the HTTP interaction. E.g. customer-specific knowledge held in an Operator's database. 03:22:16 q+ 03:22:18 ack martinj 03:22:58 ... a user preference with the origin website that the CT-proxy has no knowledge of 03:23:30 ack jo 03:23:30 jo, you wanted to sya that surely this is a general caching problem 03:23:33 ack jo 03:23:41 Martin: we should conentrate on a set of warning notes instead of a description of how it works 03:24:39 Jo: how about either an informational point about this is what you can expect a CT-proxy to do 03:26:05 ack Bryan_Sullivan 03:26:08 ... and note the issue of cachability is generally appliccable 03:26:21 s/either an/an/ 03:26:59 Bryan: at the very least this is inferred on a User-Agent by User-Agent basis 03:27:08 q+ 03:28:25 [summary of my response to Martin: that informational notes would help CPs understand what CTs are doing but giving warnings to CT providers may not be as useful, and there are very large number of possible warning areas that we would have to note] 03:29:03 Martin: it's appropriate other CT-vendors outside this WG will be interested in these guidelines 03:29:16 q+ 03:29:20 ack m 03:29:23 ack j 03:30:17 Jo: agree with Martin, the level of discussion indicates it isn't obvious 03:31:29 [notes that if we put some warning notes in and not others then incorrect inferences may be made about the importance of those notes] 03:31:42 Topic: CT - Proxy indication of its presence to server (3.1.3) 03:31:43 Francois: on to sec 3.1.3 03:32:00 ... and talking about POWDER 03:32:29 I wanted to highlight a newly-lauched mobile web site - m.linkedin.com - which does a particularly good job of following the best practices (not MobileOK - fails 3 tests - but passes 23 - impressive) - and also provides a iPhone-optimized version on the same URI - alternate representations. Just to underscore that these guidelines are addressing real use cases that headline websites are implementing TODAY. 03:32:37 ... according to HTTP the CT-proxy must add a Via header 03:33:09 ... and we can reference a URI to describe CT capabilities in the Via string 03:33:52 ... POWDER is only a 1st working draft at present 03:34:47 ... but sounds like it will be an ideal format to use 03:35:31 ... Question is does anyone know enogh to define this guideline yet? 03:35:59 q+ 03:36:08 Dan: does it make sense to wait until POWDER is more gorund? 03:36:22 s/gorund/ground/ 03:37:04 ack s 03:37:11 q+ 03:37:46 Sean: it seems to make the Via information useful you need to go into some detail about capabilities 03:37:58 ... so fact it is a moving target is a problem 03:38:08 q+ to say that we should avoid repeating UA PROF 03:38:23 Bryan: isn't it helpful just to know there is a CT-proxy in the 1st place? 03:39:26 ... even with no additional knowledge of its exact capabilities? 03:40:41 ... maybe we're getting ahead of ourselves trying to define a capabilities specification yet 03:40:45 A URI in a response from a server could be flexible, and could even refer to itself, so it doesn't have the downsides of UAProf, 03:41:01 q+ 03:41:22 ack b 03:41:26 ack j 03:41:26 jo, you wanted to say that we should avoid repeating UA PROF 03:41:50 Jo: we shouldn't repeat the UAprof style of specifying a URI and saying "go figure" 03:42:09 The "here be dragons" flag. 03:43:50 [adjourn for lunch] 04:43:01 MartinJ has joined #bpwg 04:49:35 jcantera has joined #bpwg 04:50:30 rrsagent, make minutes 04:50:30 I have made the request to generate http://www.w3.org/2008/03/03-bpwg-minutes.html jo 04:51:36 rrsagent, make logs public 04:57:46 wonsuk has joined #bpwg 04:59:23 soonho has joined #bpwg 05:04:33 scribenick: SeanP 05:04:42 scribe: SeanP 05:06:24 DKA: m.linkedin.com does a lot of the MobileOK stuff 05:06:57 DKA: m.linkedin.com does a lot of the MobileOK stuff 05:07:31 sylee has joined #bpwg 05:08:39 Francois: Before lunch we said that maybe only a flag that CT was taking place was necessary. 05:08:53 q+ 05:09:02 ...I tend to think that a URI is kind of harmless and would be a good thing. 05:09:15 ack b 05:09:26 ack m 05:09:31 Bryan: The parameter would represent a flag. 05:10:38 Francois: The question about Powder still exists but we'll come back to that. The POWDER description may not be needed for now. 05:11:55 q+ 05:12:40 Topic: CT - Altering header values (3.1.4) 05:12:41 ...In section 3.1.4, if we go with the two requests then there is no need to put the original headers in the second request. 05:12:53 q? 05:13:38 Rob: That my be too far. Mandating that the first request has the original UA is too much. 05:14:21 Francois: That's what we said earlier. I don't see the reason to provide the original headers in the second request. 05:14:24 q+ 05:14:29 ack r 05:14:50 Rob: I don't see why we should prohibit sending the original headers. 05:15:42 Jo: There may be administrative arrangement between user and operator--the content provider still needs to get the original header values. 05:17:00 Jo: In some cases it will have sent the original headers but not all cases. 05:17:26 Francois: In that case we need to find a way to provide the original headers. 05:17:40 q+ 05:17:56 ack j 05:18:33 ...The main point is the UA header. Not too many possible ways to do that. Need to use a new header. 05:18:52 Bryan: Are we just talking about the Accept headers. 05:19:04 Francois: Talking about UA and Accept. 05:20:12 Bryan: Sometimes UA Profile header is changed. Going down the path of providing original headers gets into the new technology territory. 05:20:52 q+ 05:20:56 ack Bryan_Sullivan 05:21:07 ack jo 05:21:08 q+ 05:21:18 ...That is a significant bar to set for content providers. Another level of complexity if content provider needs to handle two different types of responses. 05:22:10 ack MartinJ 05:22:11 ack m 05:22:18 q+ 05:22:57 Jo: A chicken and egg situation. Not providing original headers removes incentive to make mobile sites. 05:23:03 It would be counter to what we're trying to do with the DDR Simple API, which will need to find the device evidence in the headers. 05:23:16 ack Bryan_Sullivan 05:23:53 Martin: Mobile content providers use headers for statistics, etc. Seems like a good idea to provide original headers. 05:25:08 Bryan: Simply suffixing the original UA header to the end of the new UA is common technique for WAP gateways. 05:25:30 q+ 05:25:37 ...Saying a request comes from 2 different user agents will confuse content providers. 05:26:52 Bryan: 1) need to specify that a CT server is in the path and 2) need to give the original server a different UA--the second one is the problem. 05:27:20 Rob: Agree. Two UAs in a request could confuse Content servers. 05:27:58 Francois: Hard to append original headers to end of existing headers. Need to create new header. 05:28:04 q+ 05:28:27 ack rob 05:29:22 Jo: Could include a URI in request where the original headers could be found. Wrap up original headers and put them in the request body. 05:30:03 Francois: Could add a new header that has all of the original information that we need. 05:31:08 Jo: There are no good answers. Need the least bad answer. A possibility is to include a URI to the original headers. 05:32:15 Bryan: Put a content-type in the message body. That's lighter weight. 05:32:42 q+ 05:33:14 Jo: What headers should be provided? All of them, some of them, the ones we have identified (UA and Accept). Content providers may look at more headers than just the UA. 05:33:37 q+ 05:34:02 ...Could look at things that are added downstream from CT proxy. 05:34:13 q? 05:34:33 ack seanp 05:35:51 Sean: Could put original headers in Via header. 05:36:05 Francois: That sounds dirty. 05:36:14 ack rob 05:36:32 ACTION: Jo to include a note that we think it is bad practice to strip the comment from downstream via header fields 05:36:33 Created ACTION-684 - Include a note that we think it is bad practice to strip the comment from downstream via header fields [on Jo Rabin - due 2008-03-10]. 05:36:43 q+ 05:36:56 ack MartinJ 05:37:11 Rob: If you change the header provide the original, otherwise don't worry about it. Provide the original header in Original-xxx. 05:37:27 Martin: Use the Warning header--can be used in requests. 05:37:29 q+ 05:38:44 ack j 05:38:56 Jo: We're doing variations on a theme. The problem with the X-Original-xxx headers is what if the headers are modified further. The problem with the Warning header is it is not a structured field. 05:39:02 Are CT chains in scope? Could be a very tricky issue, as hinted at by Jo. 05:39:25 Bryan: Are we addressing efficiency here? 05:40:32 Jo: No we are not talking about efficiency. We're trying to help the content providers to provide the right content and tabulate mobile statistics. 05:41:50 chaals has joined #bpwg 05:42:02 Bryan: We're going to have trouble embedding multiple headers in a single line. Something along the lines of a pointer to the headers makes more sense. Using Application External Body would work. 05:42:35 Present+ chaals 05:42:53 rrsagent, draft minutes 05:42:53 I have made the request to generate http://www.w3.org/2008/03/03-bpwg-minutes.html chaals 05:43:26 -> http://tools.ietf.org/html/rfc2616#section-19.1 HTTP mime types 05:44:47 Francois: Using references to external URI seems to be too complicated. Would have to use a link to get original request. Seems too complex in practice. 05:45:08 Jo: Should have investigatory actions on this topic. 05:45:45 Francois: Need everyone to look into this. 05:45:59 Could also introduce a security threat if the headers were available at a location external to the path between client and server. 05:46:31 good point Rotan 05:47:05 Francois: Methods: 1. Embed headers in another header. 2. Provide a pointer to headers in a separate location. 3. Warning header 4. Additional HTTP headers 05:47:17 Adding more bulk to the headers is also a problem because some systems (e.q. squid and load balancers) limit total header size to counter DoS attacks. 05:47:18 brb 05:50:16 Jo: In HTTP spec the content type I was referring to is message/HTTP. 05:50:36 ACTION: Daoust to investigate embedded original headers in altered requests (message/http), external ref to original headers (application/external-body) and/or use of WARNING headers for 3.1.4 05:50:36 Created ACTION-685 - Investigate embedded original headers in altered requests (message/http), external ref to original headers (application/external-body) and/or use of WARNING headers for 3.1.4 [on François Daoust - due 2008-03-10]. 05:50:55 Bryan: I was talking about message/External-Body. 05:51:15 s/message/application 05:51:45 Jo: Warning would at least provide an indication that headers have been modified. 05:52:04 Francois: Warning is a general header--can be used in request. 05:53:31 Francois: Can't take any resolutions yet. Need to settle the use of POWDER in the response from the server. 05:54:45 ...Do we want to use it? Need details for it to be useful. For now we should just mention that POWDER could be used. 05:55:09 q+ 05:55:15 ack b 05:55:15 ack Bryan_Sullivan 05:55:40 Bryan: The POWDER reference is fine if we say that further work on this is done in the context of POWDER or the Delivery Context. 05:56:06 Jo: We can't leave it to POWDER since they aren't chartered for that. 05:56:30 ...Not really part of the Delivery Context either. 05:57:28 Jo: Would like to see us create the POWDER vocabulary. Phil says that POWDER will be done real soon now. Given that we have more work on CT, we can afford to wait. 05:57:54 Francois: We're not ready to publish a first public working draft. 05:57:54 zzz 05:57:58 s/.../server preferences /# 05:58:36 Jo: We can publish a FPWD with a dangling reference to POWDER. 05:58:48 Francois: I think that is OK. 06:00:14 PROPOSED RESOLUTION: AS far as we have reviewed of CT will not alter other than agreed changes and editorial notes; there will be no changes up to 3.1.4 other than these, therefore we can focus on 3.1.4 onwards and then move to fpwd. 06:00:35 +1 06:00:48 +1 06:00:50 RESOLUTION: AS far as we have reviewed of CT will not alter other than agreed changes and editorial notes; there will be no changes up to 3.1.4 other than these, therefore we can focus on 3.1.4 onwards and then move to fpwd. 06:00:50 +1 06:05:53 Seungyun_ has joined #bpwg 06:32:24 MartinJ has joined #bpwg 06:32:56 scribe: MartinJ 06:33:05 scribenick: MartinJ 06:34:02 Seungyun_ has joined #bpwg 06:35:08 Seungyun__ has joined #bpwg 06:37:50 jcantera has joined #bpwg 06:38:00 Topic: CT - editor's meeting/wrapup 06:38:00 Chaals: Opera will implement the recommendations. Will investigate hosting a CTTF meeting in Prague 06:38:25 ... (Opera has an office there) 06:38:40 Jo: It would be an editor's meeting 06:38:56 ... so would not need 8 weeks' notice 06:39:26 ... thinking of a couple of weeks 06:39:55 Dan: There will be a MobileOK Pro editors's meeting in London about that time 06:40:11 s/s's/s'/ 06:41:14 s/Dan/DKA/ 06:41:50 Dan: will try to find out when 06:42:21 Dan: is there anythinh happening in the Korean Market that would help to inform the work of the CT Task Force? 06:42:36 ... e.g. are any Korean operators implementing CT proxies? 06:44:17 Soonho: Yes SK implemented one last year. It is in-house software. 06:44:55 DKA: It would be very intersting to get some feedback on the CT document 06:45:11 s/intersting/interesting/ 06:45:23 ACTION: Soonho to provide feedback on CT document 06:45:23 Sorry, couldn't find user - Soonho 06:45:33 q+ to note that W3C/ERCIM could host the editor's meeting if needed 06:45:48 ACTION: Soonho Lee to provide feedback on CT document 06:45:48 Sorry, couldn't find user - Soonho 06:45:59 trackbot, list 06:46:09 trackbot-ng, list 06:46:30 trackbot-ng, list users 06:47:11 ACTION: soonho to provide feedback on CT document 06:47:11 Sorry, couldn't find user - soonho 06:47:41 trackbot, status 06:47:50 trackbot-ng, status 06:48:24 trackbot-ng, reload 06:48:37 trackbot-ng, status 06:49:01 q? 06:49:09 ack j 06:49:31 Francois: If necessary ERCIM could host the editor's meeting 06:50:30 ack f 06:50:30 francois, you wanted to note that W3C/ERCIM could host the editor's meeting if needed 06:50:55 ACTION: Francois will organise the next CTTF Editors' meeting 06:50:55 Sorry, couldn't find user - Francois 06:51:16 Topic: BP2.0 - Scope 06:51:16 > ACTION: daoust will organise the next CTTF Editors' meeting 06:51:35 ACTION: daoust will organise the next CTTF Editors' meeting 06:51:35 Created ACTION-686 - Will organise the next CTTF Editors' meeting [on François Daoust - due 2008-03-10]. 06:52:07 DKA: We should have a discussion to nail down the scope of the document 06:52:25 ... this wil help to inform the review of the other documents 06:52:31 s/wil/will/ 06:52:51 ... including input from the Mobile Web 2.0 Forum (Korea) 06:53:15 ... Bryan please take us through the current document including scope and sticking points 06:53:30 Jo: Let's do scoping first 06:55:08 -> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080303 BP 2 Draft 06:55:42 Bryan: ref section 1.4 Scope.. 06:55:58 ... doesn't attempt to recreate the same focus as BP1.0 06:56:26 ... focuses on mobile web *applications* 06:56:45 q+ 06:56:52 ... not the client type or the specific content types 06:57:09 ... keeping in the overall framework of web technologies 06:57:34 ... focus on the browser as the main example of a web application "engine" 06:58:22 ... there is ongoing discussion about the accessibility part (WCAG) 06:59:21 q? 06:59:23 ack jo 06:59:28 ack me 06:59:29 ... the mobile environment hasn't changed dramatically but BP2 goes further to encompass more advanced technologies including both browser and non-browser based interaction. 06:59:48 q? 07:00:02 Jo: should we spend more time talking about scope or just throw ideas around to find the appropriate ones 07:00:24 q+ 07:00:28 q? 07:00:37 ... problem is to define the basis on which we decide which to leave in or throw out 07:01:45 ... what I think is that we should look at the Sondheim 7 points. 07:02:06 ack me 07:02:41 -> http://lists.w3.org/Archives/Public/public-bpwg/2008Feb/0116.html Scope discussion 07:03:33 chaals: mostly agree with Jo, in that we should not spend too much time defining scope, but the term "web applications" is problematic. Should talk about more advanced technology rather than "web applications" 07:03:39 q+ 07:04:10 s/advanced technology rather than/advanced technology as used to develop richer/ 07:04:22 Dan: strongly agrees - there is a statement about "advanced web technologies" already in the document 07:04:35 q? 07:04:37 ack bry 07:04:46 ... so should we just describe what they are 07:04:50 q+ to comment on the word advanced, which is time limited 07:05:09 Bryan: the current definition is deliberately non-prescriptive 07:05:48 ack jo 07:05:48 jo, you wanted to comment on the word advanced, which is time limited 07:05:49 ... it is an evolving thing.. not sure we can define too rigidly what an advanced web technology is 07:06:14 Jo: I agree but we are chartered only to look at certain things 07:07:36 ... so we should make the point that some recommendations may apply to other types of technology. We should be reasonably comprehensive but not try to be comprehensive in areas that are out of scope 07:07:55 ... e.g. Flash Lite would not be in scope 07:08:22 Bryan: But let's be careful not to be too prescriptive 07:08:33 Are there criteria for deciding what is in scope? Apart from being a "Web technology", which is quite a lot these days. 07:08:51 Jo: we should be careful about the word "advanced" 07:09:10 DKA: looking for suggested non-controversial text.. 07:09:35 1. uses the Internet and the Web to access data, 07:09:37 generally provided in XML form 07:09:38 2. models the data on the client device in the form of a 07:09:40 Document Object Model 07:09:41 3. uses Cascading Style Sheets to presesent the data 07:09:43 on the client device 07:09:45 4. uses a scripting language (often ECMAScript or a 07:09:47 derivative) to control the data and view on the client 07:09:48 device 07:09:50 5. can operate successfully on client devices which may move 07:09:51 6. can be presented successfully on handheld client devices 07:09:53 7. can operate successfully in a networking environment 07:09:54 which may involve intermittent, relatively slow, and relatively 07:09:56 expensive connectivity 07:10:54 Jo: Point 1 is obvious but should say "XML form or HTML form" 07:11:25 ... or the other way around 07:12:13 chaals: a web technology may have its front end in XML or HTML but might be accessing its data in some other form. Would say "uses the web to access data". 07:12:30 "can operate successfully on client devices that are designed primarily for use while moving or being carried" 07:12:56 ... would say a "web application typically have many of the following characteristics" rather than "has to have 5 or more" 07:13:30 Jo: Let's put "(or any other format)" with an editor's note that it is still under discussion 07:14:19 ... Point 2: it is significant that a web application is primarily declarative in form, which relates to the DOM 07:15:02 DKA: a common practice is a procedural application that creates a DOM 07:15:45 chaals: centrality of the DOM is key, not declarative/procedural form 07:16:27 Jo: Point 3. May or may not use CSS per se but uses the same model to manipulate the DOM 07:16:40 chaals: Use of CSS is a common feature 07:17:00 jo: don't want to excude apps that don't use CSS 07:17:31 chaals: typical web applications use CSS, DOM, HTTP, etc. These are indicative characteristics 07:17:51 DKA: would go with "uses CSS for styling" 07:18:32 As opposed to "using CSS for security" perhaps? ;) 07:18:39 wonsuk has joined #bpwg 07:19:19 Jo: Point 4 - seems pretty central. Only worry is that we are talking in general about offering autonomous control to the client - should be talk about ECMAscript in particular 07:19:39 chaals: so "uses a client-side scripting language" 07:20:19 Jo: so what the ECMAscript achieves is autonomous user interaction and autonomous network communication 07:21:06 DKA: could use "generally uses ECMAscript", etc. 07:21:32 s/language"/language, typically ECMAscript for autonomous behaviour in the client"/ 07:21:56 5. "can operate successfully on client devices that are designed primarily for use while moving or being carried" 07:22:09 5. can operate successfully on client devices which may move 07:22:23 offers autonomous interaction with the user and network, typically by use of a scripting language (often ECMAScript or a derivative) 07:22:42 [/me suggests "can operate successfully on mobile devices"] 07:22:43 previous one was edited as "uses Cascading Style Sheets properties for styling" 07:22:44 I can move my server. It's not really a mobile device though, is it? 07:23:22 Something that is designed primarily for use while moving would generally have a small screen. It's a natural inference. 07:23:31 You don't need to say it. 07:23:36 :) 07:23:44 Yes, Jo, from the charter. 07:24:16 Yes, I agree Jo. 07:24:33 Jo: the bit that is missing is that a user's context may be significantly different from time to time 07:25:25 "can operate successfully on client devices that are designed primarily for use while moving or being carried" 07:25:38 Bryan: is the point "contextual variance"? 07:26:01 "for use while moving" says a little about contextual variance. 07:26:11 can operate successfully on client devices that are designed primarily for use while moving or being carried and where the user can be expected to be in a range of different contexts 07:26:25 That looks like good text to me. 07:26:28 +1 07:26:40 OK, replaced that one 07:27:04 (You don't really need the "a range of") 07:27:31 DKA: Point 6 is redundant 07:27:54 Automotive Web device is not handheld. 07:28:06 7. can operate successfully in a networking environment 07:28:08 which may involve intermittent, relatively slow, and relatively 07:28:09 expensive connectivity 07:28:40 The point is that the device moves around. Either it just moves (i.e. you move with it) or you carry it (i.e. it moves with you). 07:28:56 DKA: Point 7 - important to cover the network issues specifically as these issues are important 07:29:04 No. 6 is redundant. 07:29:36 If it is designed for use while moving, you can infer that the i/o is limited. 07:29:50 Unless you like carrying your plasma TV. 07:30:03 q? 07:30:20 Let's not worry about the edge cases. 07:30:42 DKA: Point 7, want to change "networking" to "networked" 07:30:52 "relatively expensive" means relative to what exactly? 07:31:44 Could just say "expensive". 07:31:52 DKA: relative to desktop broadband access 07:32:05 join has joined #bpwg 07:32:13 The expense could be cost, or could be use of scarce resources (e.g. bandwidth). 07:32:15 Bryan: Key point is "limited resources" 07:32:42 q? 07:33:27 DKA: likes the "limited resources" term 07:33:28 wonsuk has joined #bpwg 07:33:47 q? 07:34:14 I'd like to suggest this sentence: "can be supported the best mobile web user experience" - phone OEM function call, Touch web interface, Gesture web interface 07:34:54 Jo: how about "resource constrained environment with consequent impact on the user" 07:36:08 DKA: I think "expensive" is an appropriate word for this 07:37:03 q? 07:37:20 can operate successfully in a resource constrained networked environment with consequent impact on user experience, delay and cost 07:38:25 can operate successfully in a intermittently connected resource constrained networked environment with consequent impact on user experience, delay and cost 07:40:06 Jo: Jonathan can we broaden your statement to include making use of mobile features, eg. touch screen 07:44:28 Seungyun__ has joined #bpwg 07:55:45 Scribe: Francois 07:55:49 ScribeNick: francois 07:57:39 Seungyun__ has joined #bpwg 07:58:17 Jo: Let's take up Jonathan's suggestion and take a look at it 07:58:22 I'd like to suggest this sentence: "can be supported the best mobile web user experience" - phone OEM function call, Touch web interface, Gesture web interface 07:58:29 Watch out for the backgound music! 07:58:31 ^^ from Jonathan 07:58:40 s/backgound/background/ 07:59:16 Bryan: the use of mobile features. 07:59:52 DKA: I think something about mobile device "capabilities" would be good 08:00:34 Can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces 08:00:38 Bryan: so... the web applications that are designed to exploit mobile device capabilities? 08:00:39 The unique and specific features associated with mobile devices. 08:00:46 Prefix to the list "Web applications considered in scope for BP2 typically have many of the following characteristics:" 08:01:29 abel has joined #bpwg 08:01:53 Seungyun__ has joined #bpwg 08:01:55 DKA: to have something consistent with that heading, something that uses mobile device capabilities 08:02:26 Can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces and has a camera 08:03:15 "various modes of input and data gathering" 08:03:21 DKA: I would go for "use of a camera", comma, etc etc 08:03:47 Can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces and has a camera 08:03:59 and yada yada yada 08:04:16 Jo: [yada-ing] 08:04:58 q? 08:05:34 DKA: OK, that concludes our discussion 08:05:48 RRSAgent, draft minutes 08:05:48 I have made the request to generate http://www.w3.org/2008/03/03-bpwg-minutes.html francois 08:06:27 Bryan: next paragraph in the Scope section is mostly taken from BP1 08:07:47 ... I thought it was an important clarification of the focus 08:08:00 ... Focus is on the content and the applications themselves 08:08:32 DKA: We should also say we're not telling "use Java, HTTP, ...". 08:08:47 Jo: I think we should remove the ref to WCAG 08:09:10 ... First sentence is important. The rest should go. 08:09:55 ... but at some point we'll probably have to put ref to WCAG, internationalization rec and the like 08:11:12 Bryan: I left the ref to the Scope document 08:11:29 ... A more detailed consistency revue would be good 08:12:08 ACTION: rabin to raise issue on currency of the Scope document ref whether it should be reference drom BP2 08:12:08 Created ACTION-687 - Raise issue on currency of the Scope document ref whether it should be reference drom BP2 [on Jo Rabin - due 2008-03-10]. 08:12:35 Topic: BP2.0 - Criteria for BP recommendations 08:12:36 Bryan: Then, 1.4.1 lists a set of practical criteria which may not be that practical 08:12:36 q+ 08:12:53 ... Here's the list: 08:13:13 - recommendations that are considered essential for successful deployment of web applications in common delivery contexts 08:13:28 - recommendations are considered of fundamental importance to growth in the mobile web application market 08:13:36 ... which is a bit more fluffy 08:13:43 ack me 08:13:49 - recommendations that can be readily verified through compliance testing, either automated (preferred) or manual 08:14:02 ... Are we going to make recommendations that cannot be testable? 08:14:29 Jo: We did have that discussion before, and decided testability was not a necessary criterium for the best practices 08:14:58 ... It would be consistent with BP1 to continue like this 08:15:17 Thinking out loud: would it be useful to reference the recent work on the relationship between MW and Accessibility? 08:15:44 ... About the previous 2 points... 08:15:49 q+ 08:15:59 ... first, maybe not essential, rather good practice 08:16:15 ... I think the statements are both overstated 08:16:48 Bryan: my point was there are probably many things we could write about 08:16:58 q+ to comment on the work "great" 08:17:13 ... we need to be careful to draw a line between what would be useful and what is useful 08:17:16 ack cha 08:17:22 q? 08:17:47 chaals: I agree with Jo, not "essential", rather "are going to improve" 08:18:10 ... some best practices should be something like "It's always worth doing this" 08:19:02 ... Second point, I was trying to understand what it really really means. 08:19:26 a) its common practice that is harmful in our scope 08:19:27 b) it would improve the experience in our scope but is rarely practices 08:19:28 ... A BP leads in an improvement in user experience 08:19:29 c) it is in scope 08:19:46 s/in an/to an 08:20:25 Actually, an overall improvement. Some best practices (such as the hoops we have to go through to protect sensitive info) can be a nuisance in the experience, but overall are beneficial. 08:21:55 DKA: I would qualify b) by saying it would improve user experience in our scope, but we need to find some quantified way to measure that such as "is implemented in a certain number of sites" 08:22:00 Jo: Yes, it must exist 08:22:03 DKA: right 08:22:18 Thinks Dan's idea sounds nice, but could be open to challenge for being too subjective. 08:22:52 Subjectivity is objective. 08:23:24 Bryan: I'll paste the 3 points I'm getting 08:23:30 will improve chances of successful deployment for web applications in common delivery contexts 08:23:35 -Woody Allen 08:23:45 if they address a specific mobile aspect 08:24:32 Jo: On wording, I would prefer "refer to the mobile context" 08:24:50 Bryan: yes, but it seems too generic 08:25:12 if they are relevant but not limited to the mobile context 08:25:34 if they are relevant to the mobile context 08:25:43 +1 08:25:45 is implemented and recommended as a best practice 08:26:41 DKA: do we want to precise the number of implementations? 08:26:55 chaals: 2-3, that's nothing on the Web, so no 08:26:57 And "enduring", meaning that where implemented, it tends to stay there and continue to be used. 08:27:40 is implemented and recommended for broader use 08:27:49 Jo: 2 things, one to include: if we find something not commonly implemented but useful 08:28:39 1) will improve chances of successful deployment for web applications in common delivery contexts 08:28:47 2) if they are relevant to the mobile context 08:28:55 3) is implemented and recommended for broader use 08:29:08 ... One thing that seems to be missing is we're not saying anything about what people do today that is harmful 08:30:19 Could be many reasons for something good not to be commonly implemented: it's hard to do, it's patented up to its eyeballs, it's very very new, it only works on certain platforms, the expert hasn't written the O'Reilly book yet, etc. 08:31:23 ..or it hasn't had the stamp of approval from the W3C Mobile Web Best Practices working group. 08:31:23 chaals: if we say "don't do something", then it meets our criteria and there's no need to create another use case 08:32:27 promote avoidance of techniques considered harmful 08:33:01 chaals: let's say you have a BP that says "don't write bad apps" (just an example). 08:33:07 ... it meets our criteria 08:33:13 ... so no need to add that criterium 08:33:18 In some cases, doc.w can be faster than parsing a load of markup. generating complex tables for data, for example. But *in general* it might not be a good idea. Needs more testing to get hard data. 08:33:46 Jo: I take your point, but still consider it useful. 08:34:15 Bryan: alright, I'll make a note with that. 08:34:20 Updated agenda here: * Review Apple document 08:34:20 * Review Univ of Helsinki masters thesis on Mobile Ajax performance 08:34:20 * tel: URI (and other URI schemes) 08:34:20 * Review Frost Ajax library 08:34:21 * Korean input on BP 2.0 document (1 hr) 08:34:27 Gah! 08:34:34 will improve chances of successful deployment for web applications in common delivery contexts, by promoting adoption of good techniques and avoidance of techniques considered harmful 08:34:43 Trying again: Updated agenda here: http://docs.google.com/Doc?docid=dd3jk8v_89f6vrqk9w&hl=en 08:35:03 Jo: Yes, that captures it nicely for me 08:35:08 Bryan: OK 08:35:10 +1 08:35:16 +1 08:35:25 +1 to Dan's +1 08:35:41 chaals: successful deployment? 08:35:54 Bryan: yes, softening of my previous "essential" statement 08:36:09 For many these days, successful simply means it makes you lots of profit. 08:36:17 +2 to JO'S +1 of my +1 08:36:41 will improve web applications in common delivery contexts, by promoting adoption of good techniques and avoidance of techniques considered harmful 08:36:42 making a profit is important to the ecosystem 08:36:56 Plenty of rubbish apps out there making a load of money. Lack of decent competition in many cases. 08:36:59 chaals: yes, that actually looks good to me 08:37:26 Bryan: 1.5 and 1.6 are templates 08:37:57 ... Follow in the steps of BP1, period. OK? 08:38:22 Jo: I think we can continue to have this note on DIWG, except we have to rename it to UWA 08:38:43 s/DIWG/DIP 08:39:30 s/DIP/DIWG/ 08:41:42 Bryan: 20mn left, let's go through the requirements 08:42:11 ... What I have in the requirements is I got requirements structures around a number of aspects. 08:42:40 ... There was this whole list we came up with in an email. So I took it and broke it up in sections 08:43:17 ... Now the list is down at the end of the document 08:44:06 Jo: Are we skipping Requirements? 08:44:28 Bryan: no, but Dan wanted to go the Tel Uri thing 08:45:01 Jo: OK, I think the requirements need some more work 08:45:16 ... Personalization, Security and privacy are not mobile-specific 08:45:40 DKA: I think the most valuable to spend our time is to take a look at BPs 08:46:18 ... so I would start with tel URI because I had the feeling it was not controversial 08:46:47 Topic: BP2.0 - Best Practices 08:46:48 Bryan: OK, so about section 5 08:47:33 q+ 08:47:41 ... the BP is to use URI schemes (tel, sms, wtai, mailto) 08:47:59 DKA: I don't think we can give all of these things equal weight 08:48:04 ack dka 08:48:20 ... Is sms: implemented, sip: implemented? 08:48:40 ... I know tel: is implemented, more than the rest at least 08:49:17 Jo: Use Uri schemes when they are known to be supported 08:49:29 DKA: that gets a bit wishy washy, doesn't it? 08:49:37 q+ 08:50:07 Jo: The advice's got to be: find what schemes are supported and use them 08:50:56 q? 08:50:59 \ack jo 08:51:00 ack jo 08:51:00 jo, you wanted to comment on the work "great" 08:51:26 q+ to suggest we need specific best practices addressing each of tel:, wtai:, -- specific BPs are more useful to developers. 08:51:33 ack jc 08:51:37 Jo: We should include wtai, sms, tel... even if they are not properly standardized 08:52:06 SMS URI scheme draft http://www.tools.ietf.org/html/draft-wilde-sms-uri-14 08:52:35 Jose: the point is not recommending the use of URI schemes but when. 08:53:02 q? 08:53:04 DKA: when you're presenting a number that you want the user to call, use tel: 08:53:05 ack brya 08:53:35 Bryan: to capture this... when you intend to specifically have the user make a phone call, use this 08:53:44 Where possible use formal hyperlinks for non-Web actions. 08:55:11 Jo: we should not restrict to "tel:" as Bryan says 08:55:31 q+ 08:55:33 DKA: from the developer's point of view, use schemes is a completely useless statement 08:56:08 ... I think we got a lot of feedback on BP1 saying that BPWG knew what they mean but not the person that reads the doc 08:56:31 ... I would like us to err on the side of these statements be simple 08:56:33 Where possible use hyperlinks to indicate actions such as initiating a phone call 08:56:54 q+ 08:56:58 q? 08:57:01 ack d 08:57:01 DKA, you wanted to suggest we need specific best practices addressing each of tel:, wtai:, -- specific BPs are more useful to developers. 08:57:14 ack bry 08:57:18 Bryan: I added to Jo's statement a prefix. 08:57:54 q+ 08:57:55 Where possible use formal hyperlinks for non-Web actions. Given that the device is often also a telephone, use of such URI schemes help the user to use non-web capabilities in a range of applications such as listings, contact and so on. 08:58:01 q? 08:58:25 ack cha 08:58:27 DKA: I don't think techie is the problem 08:58:36 chaals: I'm with Dan 08:58:59 ... Basically, if we say "use formal hyperlinks for non-Web actions", the guys would just say "whatever..." 08:59:02 Where possible use hyperlinks to indicate actions such as initiating a phone call 08:59:17 ... BPs should be a short simple sentence that makes sense 08:59:37 ... Use tel: wtai: for phone calls. Period. 08:59:48 ... and refine it in "What it means?" 09:00:38 Jo: I take all the points on board, but I also think they need to be accurate 09:01:10 ... if we say use tel: wtai: brackets whatever other URI schemes you know the phone supports, then we haven't done much 09:01:32 ... The point is about what the user wants to do 09:01:54 ... mention something such as wtai: or tel: in the short description line is too specific 09:01:59 DKA: I disagree. 09:02:05 Jo: you'll want to add sms: 09:02:11 q+ 09:02:12 DKA: we'll have another BP! 09:02:35 q? 09:02:55 Jo: Our motivation is "if you want the user to perform an action, then hyperlink it for god's sake!" 09:02:59 ack jo 09:03:10 ack bry 09:03:10 ack me 09:05:35 DKA: why don't we leave it to Bryan to work on this and call it a day? 09:06:51 RRSAgent, draft minutes 09:06:51 I have made the request to generate http://www.w3.org/2008/03/03-bpwg-minutes.html francois 09:08:26 rob has left #bpwg 09:09:29 soonho has left #bpwg 09:11:06 [adjourned] 09:11:20 Seungyun__ has joined #bpwg 09:11:23 Rotan has left #bpwg 09:15:01 Seungyun__ has joined #bpwg 09:33:12 francois has joined #bpwg 10:32:13 abel has left #bpwg