13:58:26 RRSAgent has joined #bpwg 13:58:26 logging to http://www.w3.org/2008/06/03-bpwg-irc 13:58:28 RRSAgent, make logs public 13:58:28 Zakim has joined #bpwg 13:58:30 Zakim, this will be BPWG 13:58:30 ok, trackbot-ng; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 2 minutes 13:58:31 Meeting: Mobile Web Best Practices Working Group Teleconference 13:58:31 Date: 03 June 2008 13:58:45 Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0003.html 13:58:53 Chair: francois 14:01:04 Regrets: Murari, rob, Pontus 14:01:29 MWI_BPWG(CTTF)10:00AM has now started 14:01:36 +francois 14:03:53 + +0789972aaaa 14:04:15 zakim, aaaa is andrews 14:04:15 +andrews; got it 14:06:35 SeanP has joined #bpwg 14:07:53 +SeanP 14:11:32 Scribe: andrews 14:11:35 ScribeNick: andrews 14:11:58 topic: via header formate 14:12:18 -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0036.html discussion on via header format 14:13:02 francois: Is there an easy way to identify CT proxy capabilities in the via header? 14:13:42 ...Suggest we keep it simple. Nothing to prevent anyone putting anything in the header. 14:14:31 http://www.w3.org/2008/04/ct#active 14:14:54 http://www.w3.org/2008/04/ct#active&intend_to_transform 14:15:04 ...Suggested URLs above 14:16:14 q+ 14:16:39 ack SeanP 14:16:41 ...so either have uri that says "I am a proxy" 14:16:56 ...or a uri that relates to POWDER or similar. 14:18:09 SeanP: We have not defined what the values after the "#" should be. Maybe we should limit to say 4 values? 14:18:24 ...but agree - keep it simple 14:18:58 francois: It is useful to have the flag that there is a CT proxy 14:19:42 PROPOSED RESOLUTION: keep it simple for the VIA header comment format: http://[ct namespace] and no mention of properties 14:20:37 q+ 14:20:41 PROPOSED RESOLUTION: keep it simple for the VIA header comment format: http://[ct namespace] and no mention of properties + the possibility to replace the URI with a link to a POWDER-like resource 14:20:48 -SeanP 14:20:56 ack andrews 14:21:48 andrews: Is this to be mandatory? 14:22:30 +SeanP 14:22:42 me I'm back 14:22:52 francois: don't think so - it is a "should". Could be stripped by other proxies. 14:23:09 +1 14:23:11 +1 14:23:15 RESOLUTION: keep it simple for the VIA header comment format: http://[ct namespace] and no mention of properties + the possibility to replace the URI with a link to a POWDER-like resource 14:23:27 Close ACTION-750 14:23:27 ACTION-750 Investigate how to add multiple property/values to the URI closed 14:25:34 Topic: Link element 14:25:53 -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0021.html link element 14:26:36 francois: No clear support for use of link element to indicate handheld content 14:28:47 ...i.e. to indicate that a page *is* handheld content. 14:29:03 SeanP: There are other ways to do this. 14:30:51 francois: But we can still have guidline that CT proxy will redirect user to a handheld version of the page 14:31:07 ...that is indicated in the link element 14:31:15 PROPOSED RESOLUTION: if an HTML response includes a tag, the CT-proxy SHOULD request and return the resource pointed to by [uri] instead of the current one. 14:31:22 +1 14:31:37 +1 14:31:48 +1 14:31:54 RESOLUTION: if an HTML response includes a tag, the CT-proxy SHOULD request and return the resource pointed to by [uri] instead of the current one. 14:32:15 Topic: Vary, cache efficiency and Content-Location 14:32:48 francois: Would like Jo's contribution for this so move to next topic 14:33:02 Topic: Warning header in requests 14:33:41 francois: CT proxy could add warning header if it alters an HTTP request 14:34:19 ...to show that request has changed 14:34:40 ...But changes could be shown in other ways 14:35:56 ...We would have to register a different code for warning (214 is used for responses) 14:36:33 ...I don't see added value in using warning. 14:37:09 SeanP: Agree, doesn't seem worth doing. 14:37:47 francois: Intent was to use warning instead of the x-device headers 14:38:00 PROPOSED RESOLUTION: don't recommend the addition of a "Warning" HTTP header to the request 14:38:09 +1 14:38:14 +1 14:38:20 andrews: Keep it simple - don't adopt it 14:38:22 +1 14:38:30 RESOLUTION: don't recommend the addition of a "Warning" HTTP header to the request 14:39:11 Topic: X-Device- header: final name 14:40:02 francois: 2nd problem, what should a CT proxy do if it receives such a header 14:40:42 ...this would indicate that a CT has already happened so CT proxy should not perform another CT 14:40:49 PROPOSED RESOLUTION: If the HTTP request defines a "X-Device" header, the proxy MUST NOT apply further transformation. 14:41:10 +1 14:43:58 jo has joined #bpwg 14:44:20 zakim, code? 14:44:20 the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), jo 14:44:51 +jo 14:46:50 francois: Could produce asymetry in priority between requests and responses 14:50:05 francois: Downstream (nearer handset) CT proxy will add x-device header, upstream CT proxy sees this header 14:50:39 ...upstream CT proxy should not change header and should not change response 14:52:07 jo: Presence of which x-device headers indicates that a CT proxy is there? 14:52:47 ...answer is probably that we can not say precisely 14:53:44 ...If network has a CT proxy but user is talking to an upstream proxy, which should be transforming? 14:56:08 ...Maybe this needs to be moved to an informative appendix as known future work 14:57:30 q+ 14:57:36 ack SeanP 14:58:51 SeanP: Agree that this is a complex issue. Some cases are out of scope of Guidlines. Example, operator had CT proxy and request is to a search engine which has a CT proxy 15:00:34 PROPOSED RESOLUTION: leave the "2 CT-proxy on the line" tricky issue out of scope and reference it the "Scope for Future Work" appendix 15:00:45 jo: x- headers are experimental. This is probably an area of heuristics. 15:01:12 ...Can imagine an upsteam proxy "undoing" x- headers. 15:01:40 +1 15:01:43 +1 15:01:47 +! 15:01:50 +1 15:02:00 RESOLUTION: leave the "2 CT-proxy on the line" tricky issue out of scope and reference it the "Scope for Future Work" appendix 15:02:59 Topic: name of x-device header 15:03:15 francois: No preference. 15:04:27 jo: Argument for x-device is that it is currently used. Argument against is that we do not necessarily understand the exact context of the use today. 15:05:11 ...Stricly, a proxy does not know what the device is. 15:05:45 ...Favours x-received as being more precise 15:06:26 francois: Agrees that x-received is more precise. 15:06:31 +1 15:08:47 +q 15:08:59 ack SeanP 15:09:04 andrews: Favour x-device because it is used today. Guidlines can be used to better define meaning of x-device. 15:09:42 SeanP: Agrees with Jo's point but does not feel that it is worth changing from x-device headers. 15:10:11 jo: Maybe other vendors with other headers. 15:11:54 PROPOSED RESOLUTION: Final name for the "X-Device" header is "X-Device" 15:12:01 +1 15:12:06 +1 15:12:10 +1 15:12:27 0 15:12:47 RESOLUTION: Final name for the "X-Device" header is "X-Device" 15:13:17 francois: Add note that this name was kept since it is used in practice. 15:14:36 ACTION: Jo to add note describing the circumstances of choosing the X-Device prefix and explaining that it's not necessarily the actual device headers and other weasel words, yada yada 15:14:36 Created ACTION-766 - Add note describing the circumstances of choosing the X-Device prefix and explaining that it's not necessarily the actual device headers and other weasel words, yada yada [on Jo Rabin - due 2008-06-10]. 15:15:07 Topic: Vary, cache efficiency and Content-Location 15:15:19 francois: Comment on mailing list 15:15:24 -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0022.html Vary and Content-Location 15:16:15 ...If content providers use vary: user-agent this would create many cache entries 15:16:56 ...so not cache friendly. Usually there are a limited number of representations. 15:18:06 ...CT proxies will typically generate content dynamically so probably not a problem. 15:18:15 PROPOSED RESOLUTION: to promote the use of the Content-Location header, complete the part on the "vary" HTTP header in 4.2 with a note along the lines of: "When varying representations based on received HTTP headers, cache-efficient techniques should be used. For example, if the total number of representations is limited whereas the number of values for a HTTP header used for varying representation is high [typically the case when varying representations based on 15:18:15 the User-Agent string], the different representations should be made available at specific URIs and the request to the generic resource should return the specific representation along with a Content-Location header that identifies the representation being served." 15:18:37 q+ 15:18:42 ack Seanp 15:20:52 Future requests MAY specify the Content-Location URI as the request- URI if the desire is to identify the source of that particular entity 15:22:10 jo: Not clear how this relate to vary header or caching? 15:25:09 .../I am a little bit lost in this discussion 15:25:43 q+ 15:25:51 ack SeanP 15:27:45 PROPOSED RESOLUTION: do not say anything on "Content-Location" and other generic caching techniques 15:27:49 francois: Suggest that this could potentially confuse the Guidline's readers so we should not add anything. 15:27:51 +1 15:27:59 +1 15:28:01 +1 15:28:04 +1 15:28:07 RESOLUTION: do not say anything on "Content-Location" and other generic caching techniques 15:28:32 Topic: What's next 15:29:29 francois: Please look at remaining actions. All topics and issues have been addressed. Please raise any more topics now. 15:30:03 jo: Will update draft document by next Tuesday. 15:31:47 francois: Target is to update draft and review next Tuesday. Next Thursday, present draft to working group. Pubilish at next face-to-face in Sofia. 15:32:27 -francois 15:32:28 -andrews 15:32:30 -SeanP 15:36:05 Present: andrews, SeanP, Jo, francois 15:36:10 RRSAgent, draft minutes 15:36:10 I have made the request to generate http://www.w3.org/2008/06/03-bpwg-minutes.html francois 15:37:30 disconnecting the lone participant, jo, in MWI_BPWG(CTTF)10:00AM 15:37:33 MWI_BPWG(CTTF)10:00AM has ended 15:37:34 Attendees were francois, +0789972aaaa, andrews, SeanP, jo 17:35:26 Zakim has left #bpwg