IRC log of bpwgct on 2008-02-05

Timestamps are in UTC.

14:57:07 [RRSAgent]
RRSAgent has joined #bpwgct
14:57:07 [RRSAgent]
logging to http://www.w3.org/2008/02/05-bpwgct-irc
14:57:26 [francois]
zakim, this will be BPWG
14:57:26 [Zakim]
ok, francois; I see MWI_BPWG(BCTF)10:00AM scheduled to start in 3 minutes
14:58:19 [francois]
Meeting: Mobile Web BPWG Content Transformation Teleconference
14:58:24 [francois]
Date: 5 February 2008
14:58:34 [francois]
Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Feb/0010.html
14:58:41 [francois]
Regrets: Jo, Kemp
14:58:51 [francois]
Chair: francois
14:58:56 [francois]
RRSAgent, make logs public
14:59:02 [francois]
RRSAgent, draft minutes
14:59:02 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/02/05-bpwgct-minutes.html francois
14:59:17 [francois]
zakim, code?
14:59:17 [Zakim]
the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), francois
15:00:21 [Zakim]
MWI_BPWG(BCTF)10:00AM has now started
15:00:28 [Zakim]
+francois
15:00:37 [Zakim]
+rob
15:01:23 [Magnus]
Magnus has joined #bpwgct
15:01:46 [Magnus]
zakim, code?
15:01:48 [Zakim]
the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Magnus
15:02:19 [Zakim]
+ +46.3.17.4.aaaa
15:02:32 [Magnus]
zakim, +46 is me
15:02:32 [Zakim]
+Magnus; got it
15:03:32 [Zakim]
+Bryan_Sullivan
15:04:13 [Magnus]
http://en.wikipedia.org/wiki/Semla
15:04:15 [Zakim]
+??P12
15:04:50 [Zakim]
+[Vodaphone]
15:05:29 [Zakim]
+SeanP
15:07:17 [SeanP]
SeanP has joined #bpwgct
15:07:37 [hgerlach]
hgerlach has joined #bpwgct
15:07:43 [AndrewS]
AndrewS has joined #bpwgct
15:07:44 [hgerlach]
hi Guys
15:07:52 [Bryan]
Bryan has joined #bpwgct
15:08:04 [francois]
zakim, who's on the phone
15:08:04 [Zakim]
I don't understand 'who's on the phone', francois
15:08:07 [francois]
zakim, who's on the phone?
15:08:07 [Zakim]
On the phone I see francois, rob, Magnus, Bryan_Sullivan, ??P12, [Vodaphone], SeanP
15:08:57 [francois]
zakim, ??P12 is probably hgerlach
15:08:57 [Zakim]
+hgerlach?; got it
15:09:26 [francois]
zakim, [Vodaphone] is probably AndrewS
15:09:26 [Zakim]
+AndrewS?; got it
15:10:04 [francois]
ScribeNick: AndrewS
15:10:29 [francois]
Topic: Next call
15:10:35 [AndrewS]
francois:
15:11:02 [AndrewS]
francois: not available for next call
15:11:16 [AndrewS]
Magnus: not available also
15:11:42 [Magnus]
+1
15:11:45 [AndrewS]
Andrew: We will skip one week
15:11:49 [francois]
+1
15:12:16 [francois]
Topic: CT-proxy vs CT-gateway
15:12:39 [AndrewS]
francois: Re. discussion on mailing list
15:13:24 [AndrewS]
...Yves Lafon recommends that we use gateway since user-agent is being changed
15:13:45 [Magnus]
q+
15:14:08 [francois]
ack Magnus
15:14:20 [Magnus]
http://www.w3.org/TR/ct-landscape/
15:14:26 [AndrewS]
...using gateways could be confusing - we should continue to use proxy but define the term in the start
15:15:05 [Bryan]
q+
15:15:17 [AndrewS]
Magnus: This is mentioned in the terminology section and this is accepted terminology
15:15:19 [francois]
-> http://www.w3.org/TR/2007/WD-ct-landscape-20071025/#terminologyNote CT landscape
15:16:19 [AndrewS]
Rob: A CT- node can behave as either proxy of gateway. We could just call it a "proxy/gateway"
15:17:23 [AndrewS]
francois: Wanted to draw this to the attention of the task force. We need to use terminology carefully when working with IETF.
15:18:11 [Magnus]
q+
15:18:32 [francois]
ack magnus
15:18:39 [AndrewS]
Bryan: Understands terminology but in reality most proxies do more than the strict IETF definition. We should use CT-proxy.
15:18:48 [AndrewS]
+1
15:19:47 [AndrewS]
Magnus: Could distinguish between a conventional proxy and an intercepting proxy (transparent)
15:19:59 [SeanP]
SeanP has joined #bpwgct
15:20:23 [AndrewS]
francois: Isn't a transparent proxy one that does not do anything?
15:21:02 [AndrewS]
Magnus: An intercepting proxy typically does something to the data flow
15:21:15 [francois]
Topic: HTTP Cache-Control extensions
15:22:33 [AndrewS]
francois: Yves Lafon advised that there is no process to register HTTP header extensions and suggests that we use a draft IETF RFC
15:22:54 [AndrewS]
...But this has long time scales
15:23:00 [AndrewS]
q+
15:23:07 [SeanP]
q+
15:23:12 [francois]
ack AndrewS
15:24:23 [francois]
AndrewS: yes, I agree, it's not in the TF's charter. I'm a bit worried too on new HTTP headers as it doesn't address legacy browsers
15:27:00 [francois]
... use of HTTP headers is fine with future browsers, but we have to address the legacy base
15:27:03 [Bryan]
q+
15:27:07 [francois]
ack bryan
15:29:06 [Zakim]
-SeanP
15:29:06 [francois]
ack SeanP
15:29:13 [AndrewS]
Bryan: We are focused on mobile use case. Focusing on this area will help us achieve our time lines. But it is useful to remember the broarder case of any browser content access.
15:29:14 [Zakim]
-rob
15:30:01 [Zakim]
+SeanP
15:30:57 [AndrewS]
francois: A draft IETF RFC for all content adaptation is more likely to have traction than one for just mobile access.
15:31:16 [Zakim]
+rob
15:31:46 [AndrewS]
SeanP: We should remember legacy handsets but se could consider IETF draft as well.
15:32:42 [AndrewS]
francois: Writing a draft is not a problem but it would be difficult to present it to the HTTPBis working group.
15:33:41 [AndrewS]
...Validating the draft could take a long time since HTTP RFC is for a bigger picture than just the mobile world
15:34:21 [AndrewS]
...we need to take a decision: include IETF draft or not in our scope of work
15:34:32 [Zakim]
-rob
15:35:14 [AndrewS]
...we will have to focus on what we can do without changing headers
15:36:19 [Bryan]
q+
15:36:27 [francois]
ack bryan
15:36:34 [AndrewS]
...propose that we drop new cache-control headers.
15:37:17 [AndrewS]
Bryan: We must be careful not to exclude custom headers which are already used in many cases.
15:38:12 [francois]
AndrewS: my understanding of HTTP RFC is that you can add some X- experimental headers
15:39:26 [AndrewS]
AndrewS: We use "x-<header name>" already
15:39:54 [AndrewS]
francois: What are these types of header used for?
15:40:24 [AndrewS]
hgerlach: For example to get correct wallpaper for mobile device.
15:41:14 [SeanP]
q+
15:41:50 [AndrewS]
AndrewS: We now need to decide whether we are going to include custom headers or not.
15:42:24 [francois]
ack SeanP
15:42:26 [Zakim]
+??P9
15:43:28 [AndrewS]
SeanP: Custom headers or modified headers are similar.
15:44:04 [AndrewS]
francois: Problem is with extending cache-control headers rather than with using x- headers
15:44:23 [AndrewS]
...we should try to restrict the use of x- headers.
15:45:18 [AndrewS]
hgerlach: CT is normally used for non mobile aware sites so these sites are unlikely to understand custom headers.
15:46:05 [AndrewS]
francois: Use of custom headers will only be understood by a few content servers.
15:46:45 [AndrewS]
hgerlach: We should always use original user-agent and try to always use original headers.
15:47:54 [AndrewS]
francois: We could use just x- headers which will not require us to register any extensions to existing headers.
15:48:27 [Bryan]
q+
15:48:35 [francois]
ack bryan
15:48:40 [AndrewS]
hgerlach: New headers could be useful for new content servers.
15:49:24 [Zakim]
-??P9
15:50:39 [AndrewS]
Bryan: What is the market for CT-proxies which will use custom headers between the browser and the CT-proxy.
15:51:03 [Bryan]
q+
15:51:18 [francois]
ack bryan
15:51:24 [SeanP]
q+
15:51:47 [AndrewS]
francois: Headers are really needed between the CT-proxy and content servers.
15:52:31 [AndrewS]
Bryan: Could we take a resolution to limit our scope to non-CT-aware browsers?
15:52:52 [francois]
ack SeanP
15:53:22 [AndrewS]
francois: We should consider the interaction between the CT-proxy and the user rather than the browser.
15:54:06 [Bryan]
q+
15:54:17 [francois]
ack bryan
15:54:22 [AndrewS]
SeanP: We should stick to headers between the server and the proxy, not between the browser and the proxy.
15:57:12 [francois]
Regarding HTTP new headers use, this is what I think:
15:57:12 [francois]
- between the CT-proxy and the *browser*: no real interaction needed I would say
15:57:12 [francois]
- between the CT-proxy and the user: doesn't have to be HTTP-based, using some other magic such as web-based format should be enough
15:57:12 [francois]
- between the server and the CT-proxy: HTTP headers are the only way.
16:00:52 [hgerlach]
at least we should define a mobile OK header which can be "Mobile OK", "made for Mobile" or something else
16:03:52 [Zakim]
-Bryan_Sullivan
16:04:57 [AndrewS]
francois: This could be done in other ways, on the page or using POWDER.
16:05:39 [AndrewS]
hgerlach: But POWDER always requires an additional fetch.
16:05:55 [AndrewS]
...We need a kind of "mini POWDER".
16:06:50 [AndrewS]
francois: We will have to stop.
16:07:17 [hgerlach]
bye
16:07:32 [Zakim]
-AndrewS?
16:07:34 [AndrewS]
...We need to summarise this on the mail list. I will try to do so.
16:07:59 [Zakim]
-Magnus
16:08:01 [Zakim]
-francois
16:08:11 [Zakim]
-SeanP
16:08:12 [francois]
zakim, list attendees
16:08:28 [Zakim]
-hgerlach?
16:08:30 [Zakim]
MWI_BPWG(BCTF)10:00AM has ended
16:08:34 [Zakim]
Attendees were francois, rob, +46.3.17.4.aaaa, Magnus, Bryan_Sullivan, SeanP, hgerlach?, AndrewS?
16:08:42 [Zakim]
sorry, francois, I don't know what conference this is
16:08:47 [francois]
RRSAgent, draft minutes
16:08:47 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/02/05-bpwgct-minutes.html francois
16:35:27 [francois]
RRSAgent, bye
16:35:27 [RRSAgent]
I see no action items