IRC log of bpwg on 2008-04-01

Timestamps are in UTC.

13:57:00 [RRSAgent]

RRSAgent has joined #bpwg

13:57:00 [RRSAgent]

logging to http://www.w3.org/2008/04/01-bpwg-irc

13:57:02 [trackbot-ng]

RRSAgent, make logs public

13:57:02 [Zakim]

Zakim has joined #bpwg

13:57:04 [trackbot-ng]

Zakim, this will be BPWG

13:57:04 [Zakim]

ok, trackbot-ng; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 3 minutes

13:57:05 [trackbot-ng]

Meeting: Mobile Web Best Practices Working Group Teleconference

13:57:05 [trackbot-ng]

Date: 01 April 2008

13:57:12 [francois]

Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0038.html

13:57:17 [francois]

Chair: francois

13:57:24 [francois]

Regrets: Bryan, kemp

13:57:33 [francois]

Regrets+ MartinJ

13:58:05 [francois]

RRSAgent, draft minutes

13:58:05 [RRSAgent]

I have made the request to generate http://www.w3.org/2008/04/01-bpwg-minutes.html francois

13:58:39 [francois]

zakim, code?

13:58:39 [Zakim]

the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), francois

13:59:04 [Zakim]

MWI_BPWG(CTTF)10:00AM has now started

13:59:11 [Zakim]

+francois

13:59:35 [rob]

rob has joined #bpwg

14:00:46 [SeanP]

SeanP has joined #bpwg

14:01:03 [Zakim]

+rob

14:02:03 [Zakim]

+ +0049211aaaa

14:02:08 [Magnus]

Magnus has joined #bpwg

14:02:29 [Magnus]

zakim, code?

14:02:30 [Zakim]

the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Magnus

14:03:06 [hgerlach]

hgerlach has joined #bpwg

14:03:11 [andrews]

andrews has joined #bpwg

14:03:20 [Zakim]

+SeanP

14:03:23 [matt]

matt has joined #bpwg

14:03:28 [Zakim]

+??P15

14:03:30 [francois]

zakim, aaaa is hgerlach

14:03:30 [Zakim]

+hgerlach; got it

14:03:49 [jo]

jo has joined #bpwg

14:03:53 [francois]

zakim, ??P15 is Magnus

14:03:53 [Zakim]

+Magnus; got it

14:03:59 [jo]

zakim, code?

14:03:59 [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:04:33 [Zakim]

+ +0789972aabb

14:04:35 [Zakim]

+jo

14:04:49 [andrews]

Zakim, aabb is andrews

14:04:49 [Zakim]

+andrews; got it

14:05:54 [francois]

Scribe: rob

14:05:59 [francois]

ScribeNick: rob

14:06:10 [jo]

zakim, who is making noise?

14:06:10 [francois]

Topic: Targeted schedule

14:06:20 [Zakim]

jo, listening for 10 seconds I heard sound from the following: francois (75%), hgerlach (5%)

14:06:37 [jo]

zakim, mute hgerlach

14:06:37 [Zakim]

hgerlach should now be muted

14:06:56 [jo]

Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0038.html

14:07:08 [matt]

Present- Matt

14:07:15 [rob]

francois: apart from a few issues probably settled today we're ready to publish a "First Working Draft"

14:08:02 [rob]

... aim to resolve during today's call the outstanding issues and arrange an Editor's Meeting

14:08:18 [francois]

q?

14:08:37 [francois]

Topic: ACTION-685: how to embed original headers (§3.1.4)

14:08:48 [rob]

... could publish First Working Draft in the week after next

14:08:53 [francois]

-> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#d0e528 3.1.4

14:10:00 [francois]

-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0030.html fd's action

14:10:07 [rob]

francois: couldn't find a way to echo original header values without breaking things

14:10:47 [jo]

+1 to sending X-headers and to adding an editorial note stating we'd prefer not to use this mechanisnm but can't think of any other way

14:11:40 [rob]

q+ to say we already have precedent for X-headers in live systems

14:11:40 [jo]

q+ to suggest that the app at the server would probably not have access to Warning headers ...

14:11:49 [francois]

ack rob

14:11:52 [Zakim]

rob, you wanted to say we already have precedent for X-headers in live systems

14:12:50 [francois]

ack jo

14:12:50 [Zakim]

jo, you wanted to suggest that the app at the server would probably not have access to Warning headers ...

14:13:01 [andrews]

q+

14:13:48 [rob]

rob: X-headers are deployed live by Novarra and Openwave and their presence is known to the developer community

14:14:19 [francois]

ack andrews

14:15:00 [rob]

jo: It is a pity we couldn't find a better solution but suggest we accept it as undesirable but still worth recommending

14:15:46 [rob]

andrews: supports the X-headers for echoing changed headers

14:16:07 [jo]

q+ to say we should stop wringing our hands about this

14:16:16 [francois]

ack jo

14:16:16 [Zakim]

jo, you wanted to say we should stop wringing our hands about this

14:16:17 [rob]

francois: so this means multiple X-headers if multiple headers have been changed?

14:16:27 [hgerlach]

q+

14:17:36 [rob]

jo: you can't have new HTTP headers without an experimental period, so recommend proceed with X-headers

14:17:48 [francois]

ack hgerlach

14:18:18 [rob]

hgerlach: need to understand what headers can change and what headers should never change

14:18:44 [rob]

francois: in practice it's only User-Agent and Accept

14:19:52 [francois]

PROPOSED RESOLUTION: for 3.1.4, "the proxy must add a X-Original-[original HTTP header name]" and put an editorial note about the fact we'd love to recommend something else but don't see how.

14:20:21 [andrews]

andrews has joined #bpwg

14:20:25 [jo]

+1

14:20:52 [jo]

scribe: jo

14:21:26 [Magnus]

+1

14:21:44 [jo]

PROPOSED RESOLUTION: for 3.1.4, "the proxy must add a X-Original-[original HTTP header name]" and put an editorial note about the fact we'd love to recommend something else but don't see how.

14:22:16 [SeanP]

q+

14:22:22 [francois]

ack SeanP

14:22:51 [jo]

andrew: should it be X-Device like Novarra has it?

14:23:08 [jo]

seanP: Either way seems reasonable to me

14:23:25 [jo]

rob: maybe developers will expect X-Device as it is already in use

14:24:10 [jo]

jo: i'd prefer something like X-received

14:24:27 [jo]

francois: we have a number to choose from

14:24:41 [jo]

... I don't like device but don't really care

14:24:55 [jo]

... would prefer original or received?

14:24:57 [francois]

x-device?

14:24:57 [SeanP]

+1

14:25:04 [jo]

[straw poll]

14:25:08 [rob]

rob has joined #bpwg

14:25:31 [jo]

rob and andrew also prefer x-device (fallen off IRC)

14:25:56 [jo]

andrew: take jo's point x-received might be truer

14:26:40 [francois]

PROPOSED RESOLUTION: for 3.1.4, "the proxy must add a X-Device-[original HTTP header name]" and put an editorial note about the fact we'd love to recommend something else but don't see how and a note about the choice of "device".

14:26:44 [jo]

francois: can you live with that Jo

14:27:06 [jo]

jo: really doesn't matter just lets add a ntoe saying it is a provisional choice

14:27:17 [SeanP]

+1

14:27:22 [rob]

+1

14:27:32 [andrews]

+1

14:28:09 [jo]

hgerlach: we asked that we did not define our own headers so we should make sure that these headers are unique like containing CT or some other label

14:28:28 [jo]

... so they are not used by other applications for different purposes

14:28:46 [jo]

francois: take your point but they use could be more generally applicable

14:29:43 [jo]

jo: suggest taht we take resolution and move on as headers shouldn't be bounded by a presumed application

14:29:56 [SeanP]

q+

14:30:02 [jo]

fd: well these ones are already in use so why don't we just do this

14:30:30 [jo]

hg: we have lots of X- headers in the vodafone network

14:31:33 [jo]

... not a major issue to change headers think the headers need only to be used for the single purpose

14:31:35 [francois]

ack SeanP

14:32:03 [jo]

seanp: didn't come across any collisions with the X-Device headers

14:32:34 [jo]

... to the point about which other headers might be changed: Accept-Charset and Accept-Encoding for example

14:32:58 [francois]

RESOLUTION: for 3.1.4, "the proxy must add a X-Device-[original HTTP header name]" and put an editorial note about the fact we'd love to recommend something else but don't see how and a note about the choice of "device"

14:33:02 [jo]

fd: right let's make a note about the name and take the resolution

14:33:13 [francois]

Topic: Proxy response to User Agent (§3.4)

14:33:18 [francois]

-> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080313#sec-Proxy-Response 3.4

14:33:21 [jo]

Topic: Proxy response to User Agent

14:33:40 [jo]

s/Topic: Proxy response to User Agent//

14:34:17 [jo]

fd: suggest we leave this list alone for nwo and come back to it in a later step

14:34:22 [francois]

PROPOSED RESOLUTION: 3.4 list of heuristics - leave it as it is for the time being

14:34:27 [jo]

s/nwo/now/

14:34:33 [jo]

+1

14:34:37 [rob]

+1

14:34:39 [hgerlach]

+1

14:34:58 [SeanP]

+1

14:35:01 [andrews]

+1

14:35:05 [francois]

RESOLUTION: 3.4 list of heuristics - leave it as it is for the time being

14:35:15 [jo]

zakim, mute hgerlach

14:35:15 [Zakim]

hgerlach should now be muted

14:35:31 [francois]

-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0033.html Martin's text for ACTION-717

14:35:52 [jo]

fd: Martin sent some text under ACTION-717

14:35:52 [andrews]

+1

14:36:24 [hgerlach]

hgerlach has joined #bpwg

14:36:25 [jo]

... clarifying that it is not allowed to break the end to end security

14:36:35 [francois]

PROPOSED RESOLUTION: accept Martin's text for ACTION-717

14:36:41 [andrews]

+1

14:36:42 [jo]

+1

14:36:51 [SeanP]

+1

14:37:01 [francois]

RESOLUTION: accept Martin's text for ACTION-717

14:37:08 [francois]

Close ACTION-717

14:37:08 [trackbot-ng]

ACTION-717 Propose some alternate text for HTTPs rewrite and "must provide the option to avoid transformation" closed

14:37:18 [jo]

scribe: rob

14:37:23 [francois]

ScribeNick: rob

14:38:10 [rob]

francois: remaining topic on dangerous content is a bit outdated

14:39:27 [francois]

PROPOSED RESOLUTION: for dangerous content, something along the lines of:

14:39:27 [francois]

"[when dangerous] the proxy MAY warn the user, and give the user the choice to see a transformed version of the resource"?

14:39:29 [rob]

... suggest if there is a Cache-Control: no-transform but CT-proxy determines content won't work on the handset that the CT-proxy should ask the user?

14:39:38 [SeanP]

q+

14:39:42 [francois]

ack SeanP

14:40:25 [hgerlach]

q+

14:41:05 [francois]

ack hgerlach

14:41:10 [jo]

... instead of forwarding the dangerous content MAY send a page with links to both transformed and non-tranformed versions ...

14:41:25 [rob]

q+ to say sending a "do you or don't you?" interstitial is definitely *not* a no-transform

14:41:38 [rob]

hgerlach: what is dangerous content?

14:42:26 [rob]

francois: eg a page that is too big and will cause out-of-memory in the phone browser

14:42:42 [jo]

[ref HGerlach's comments, virus scanning is surely not in scope?]

14:43:02 [rob]

hgerlach: does a virus-scanner do this?

14:43:57 [rob]

francois: I think it's out of scope unless there is a clear incompatibility

14:44:03 [francois]

ack rob

14:44:03 [Zakim]

rob, you wanted to say sending a "do you or don't you?" interstitial is definitely *not* a no-transform

14:46:01 [rob]

rob: sending a "do you or don't you?" interstitial is definitely *not* a no-transform and this could break an application if the content is saved to memory

14:46:04 [francois]

q?

14:46:09 [jo]

+1 to "no transform" means "no-transform"

14:46:15 [SeanP]

q+

14:46:21 [francois]

ack SeanP

14:46:36 [rob]

francois: yes, the CT-proxy needs to be cautious about this

14:48:00 [jo]

q+ if one could tell what was dangerous content then I'd agree with SeanP, the problems seems to be that one can't tell well enough in general

14:48:01 [rob]

seanp: if it is dangerous content then something must be done to fix it, obviously the CT-proxy needs to be cautious about altering it

14:48:08 [francois]

PROPOSED RESOLUTION: for dangerous content, something along the lines of:

14:48:08 [francois]

"[when dangerous] the proxy MAY warn the user, and give the user the choice to see a transformed version of the resource", with emphasis on the MAY to say that it may be "dangerous"

14:48:19 [jo]

q+to say if one could tell what was dangerous content then I'd agree with SeanP, the problems seems to be that one can't tell well enough in general

14:48:35 [francois]

ack jo

14:48:35 [Zakim]

jo, you wanted to say if one could tell what was dangerous content then I'd agree with SeanP, the problems seems to be that one can't tell well enough in general

14:49:23 [rob]

jo: should be absolutely only if the user wants the CT-proxy to correct dnagerous content

14:49:56 [rob]

... and as usual the users' preferences can be persistent

14:51:20 [rob]

... even the interstitial wil break an application if there is no user to see the page

14:51:47 [rob]

... so the user's decision needs to be "prior consent"

14:52:49 [jo]

"with the users explicit prior consent [when dangerous] instead of forwarding the dangerous content MAY warn the user and send a page with links to both transformed and non-tranformed versions"

14:53:41 [jo]

PROPOSED RESOLUTION: with the users explicit prior consent, when dangerous content is detected, and when using a browser, instead of forwarding the dangerous content MAY warn the user and send a page with links to both transformed and non-tranformed versions

14:54:28 [jo]

dangerous that may cause mal-operation of the users device

14:55:08 [jo]

s/dangerous that may cause mal-operation of the users device//

14:55:08 [rob]

hgerlach: should we use the word "dangerous"?

14:55:17 [SeanP]

I'm OK with the term "dangerous"

14:55:31 [francois]

+1

14:55:35 [rob]

francois: the term is defined clearly

14:55:36 [andrews]

+1

14:55:38 [hgerlach]

+1

14:55:52 [SeanP]

+1

14:55:53 [Magnus]

+1

14:55:58 [jo]

+1

14:56:25 [francois]

RESOLUTION: with the users explicit prior consent, when dangerous content is detected, and when using a browser, instead of forwarding the dangerous content MAY warn the user and send a page with links to both transformed and non-tranformed versions dangerous that may cause mal-operation of the users device

14:56:53 [francois]

Topic: Proxy Receipt and Forwarding of Response from Server (§3.3)

14:59:22 [rob]

francois: 3.1.4 says if the headers are altered the CT-proxy must be prepared to vary the headers

14:59:24 [SeanP]

q+

15:00:01 [rob]

jo: this isn't clear

15:00:39 [rob]

... if you don't get a Vary in the response you don't know to reissue the request differently

15:01:30 [rob]

... the point of sending a Vary is to avoid caching in situations where it is inappropriate to cache

15:02:14 [Zakim]

-Magnus

15:05:35 [francois]

Topic: Publication as FPWD

15:05:58 [francois]

PROPOSED RESOLUTION: editors' meeting tomorrow, resolutions on Thursday's call, reviewing and then publication

15:07:38 [francois]

RESOLUTION: let's try: editors' meeting tomorrow, resolutions on Thursday's call, reviewing and then publication

15:07:49 [Zakim]

-andrews

15:07:49 [hgerlach]

bye:-)

15:07:51 [Zakim]

-hgerlach

15:07:55 [Zakim]

-jo

15:07:57 [Zakim]

-francois

15:08:02 [Zakim]

-rob

15:08:02 [Zakim]

-SeanP

15:08:02 [Zakim]

MWI_BPWG(CTTF)10:00AM has ended

15:08:03 [francois]

Zakim, list attendees

15:08:03 [Zakim]

Attendees were francois, rob, +0049211aaaa, SeanP, hgerlach, Magnus, +0789972aabb, jo, andrews

15:08:07 [Zakim]

sorry, francois, I don't know what conference this is

15:08:08 [francois]

RRSAgent, draft minutes

15:08:08 [RRSAgent]

I have made the request to generate http://www.w3.org/2008/04/01-bpwg-minutes.html francois

15:08:09 [andrews]

quit bye

15:08:15 [francois]

francois has joined #bpwg

15:18:37 [matt]

matt has joined #bpwg

16:34:05 [francois]

RRSAgent, bye

16:34:05 [RRSAgent]

I see no action items