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