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