W3C

Mobile Web Best Practices Working Group Teleconference

01 Apr 2008

Agenda

See also: IRC log

Attendees

Present
Magnus, SeanP, andrews, francois, hgerlach, jo, rob
Regrets
Bryan, kemp, MartinJ
Chair
francois
Scribe
rob, jo

Contents


Targeted schedule

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

francois: apart from a few issues probably settled today we're ready to publish a "First Working Draft"
... aim to resolve during today's call the outstanding issues and arrange an Editor's Meeting

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

francois: could publish First Working Draft in the week after next

<francois> 3.1.4

<francois> fd's action

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

<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

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

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

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

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

andrews: supports the X-headers for echoing changed headers

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

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

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

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

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

<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.

<jo> +1

<jo> scribe: jo

<Magnus> +1

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.

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

seanP: Either way seems reasonable to me

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

jo: i'd prefer something like X-received

francois: we have a number to choose from
... I don't like device but don't really care
... would prefer original or received?

<francois> x-device?

<SeanP> +1

[straw poll]

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

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

<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".

francois: can you live with that Jo

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

<SeanP> +1

<rob> +1

<andrews> +1

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
... so they are not used by other applications for different purposes

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

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

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

hg: we have lots of X- headers in the vodafone network
... not a major issue to change headers think the headers need only to be used for the single purpose

seanp: didn't come across any collisions with the X-Device headers
... to the point about which other headers might be changed: Accept-Charset and Accept-Encoding for example

<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"

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

Proxy response to User Agent (§3.4)

<francois> 3.4

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

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

+1

<rob> +1

<hgerlach> +1

<SeanP> +1

<andrews> +1

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

<francois> Martin's text for ACTION-717

fd: Martin sent some text under ACTION-717

<andrews> +1

fd: clarifying that it is not allowed to break the end to end security

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

<andrews> +1

+1

<SeanP> +1

<francois> RESOLUTION: accept Martin's text for ACTION-717

<francois> Close ACTION-717

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

<scribe> scribe: rob

<francois> ScribeNick: rob

francois: remaining topic on dangerous content is a bit outdated

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

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

francois: 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?

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

hgerlach: what is dangerous content?

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

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

hgerlach: does a virus-scanner do this?

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

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

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

<jo> +1 to "no transform" means "no-transform"

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

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

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

<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"

<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

jo: should be absolutely only if the user wants the CT-proxy to correct dnagerous content
... and as usual the users' preferences can be persistent
... even the interstitial wil break an application if there is no user to see the page
... so the user's decision needs to be "prior consent"

<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"

<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

hgerlach: should we use the word "dangerous"?

<SeanP> I'm OK with the term "dangerous"

<francois> +1

francois: the term is defined clearly

<andrews> +1

<hgerlach> +1

<SeanP> +1

<Magnus> +1

<jo> +1

<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

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

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

jo: this isn't clear
... if you don't get a Vary in the response you don't know to reissue the request differently
... the point of sending a Vary is to avoid caching in situations where it is inappropriate to cache

Publication as FPWD

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

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

<hgerlach> bye:-)

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/04/01 15:27:32 $