W3C

Mobile Web Best Practices Working Group Teleconference

23 Sep 2008

Agenda

See also: IRC log

Attendees

Present
Francois, Bryan_Sullivan, hgerlach, rob, AndrewS, tomhume
Regrets
SeanP, jo
Chair
francois
Scribe
Bryan

Contents


New comments received

-> http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0154.html fd's no-comment comment

<hgerlach> http://cgi.w3.org/member-bin/irc/irc.cgi works

<francois> IAB message

Francois: may be some comments coming from W3C internal review of the CT guidelines.

Francois: these offer W3C staff the chance to comment given they are very busy

LC-2018: on the title

<francois> - Content Transformation Proxies: Guidelines

<francois> - Guidelines for Mobile Web Content Transformation Proxies

Francois: on the doc name, we can narrow the choice between two

<hgerlach> b) +1

Francois: we are more about web browsing than web, but browsing may be a confusing term to include; mobile web seems fine

<andrews> I favour the second

<francois> PROPOSED RESOLUTION: The title of the spec will be "Guidelines for Mobile Web Content Transformation Proxies"

<andrews> +1

Bryan: recommend to leave out mobile as this is whole web content

<andrews> Good point - I agree

<hgerlach> Guidelines for Content Transformation Proxies in Mobile Networks

<tomhume> +1

<andrews> +1

<hgerlach> -1

Heiko: proposes "in Mobile Networks"

<francois> PROPOSED RESOLUTION: The title of the spec will be "Guidelines for Web Content Transformation Proxies"

<francois> +1

Bryan: we are not limiting this to mobile networks; limited capability devices in general

+1

<andrews> +1

<hgerlach> +1

<tomhume> +1

<rob> +1

Francois: suggests we come to agreement to close this item as we could spend a lot of time on it

RESOLUTION: The title of the spec will be "Guidelines for Web Content Transformation Proxies"

Heiko: for new people, it may be hard to know that a key use case is in the mobile network context

Francois: the abstract of the title could include mobile and a proposal can be sent to the mailing list for that

LC-2025: On the quality and purpose of the doc

<francois> close ACTION-831

<trackbot> ACTION-831 Continue discussion of the title on the list closed

<francois> heiko's comments

Francois: what can we resolve to do on this?

Heiko: this will come out of the whole comment resolution process; dont want to question the whole objective, this just provides general guidelines on how to improve the doc

Francois: we can include better examples and will come back to this in the end

<francois> Close ACTION-829

<trackbot> ACTION-829 Detail his thoughts arising from discussion of LC-2025 closed

LC-2012: clarification of the introduction

<francois> Tom's proposal

<tomhume> Apologies all, I appear to have lost my telephone connection :(

<francois> "Within this document content transformation refers to the

<francois> manipulation of requests made to, and content delivered by, an origin

<francois> server. This manipulation is carried out by proxies with a view to

<francois> making content delivered more suitable for mobile presentation."

Francois: we should keep this for now, we do need to improve the intro, and can resolve to accept Tom's wording, about the 1st sentence of the intro

+1

<francois> PROPOSED RESOLUTION: re. LC-2012, use Tom's wording above, (and note we may have to further clarify the introduction for other reasons anyway)

+1

<francois> +1

<rob> +1

<hgerlach> +1

RESOLUTION: re. LC-2012, use Tom's wording above, (and note we may have to further clarify the introduction for other reasons anyway)
... re. LC-2012, use Tom's wording above, (and note we may have to further clarify the introduction for other reasons anyway)

LC-2064: duplicated IDs in the document

Francois: this one is a mistake; a bug in firefox

<francois> PROPOSED RESOLUTION: LC-2064 is a mistake. There are no duplicated IDs in the document.

+1

RESOLUTION: LC-2064 is a mistake. There are no duplicated IDs in the document.

LC-2003: no mention of whitelists

<francois> jo's proposal

<francois> PROPOSED RESOLUTION: re. LC-2003, stick to our position and use Jo's proposed response in public-bpwg-ct/2008Sep/0026.html

<hgerlach> -1

Francois: the essence is that this is an internal proxy issue

Heiko: don't agree, but can accept a team agreement

Bryan: we can consider content management interfaces through other specifications or fora, e.g. OMA
... OMA is working on content management interfaces for example

Francois: agree that new technologies may be needed, if there is some clear work going on, we can mention it in the appendix

<Zakim> rob, you wanted to support Heiko's point that whitelists do exist - and won't go away just because we don't mention them

Rob: there is talk of mechanisms, but CP's are aware of the need to be on whitelists, so it is strange that we don't mention it in more detail

Francois: the rationale is that it is not needed for our guidelines, and is just the internal processing of proxies; we could add a note mentioning whitelists

Rob: a note should tell CP to contact the network operator if they are having trouble

Bryan: should be called the "proxy operator"

Francois: we could note that whitelist require CPs to submit some request to manage their handling

Rob: it should be the proxy operator who takes the action

Heiko: the diverging views here indicate the need for clarity; the history of this is that the use of lists in the proxy were to prevent adaptation; the same concept can be applied to user-agents
... the only issue left is that 200 OK pages; for dedicated URL we see issues with 200 OK instead of 406; human launguage guidance of incompatibility cannot be used semantically and thus we need whiltelists

Francois: proposes someone take an action to propose text so we can try to get agreement on it

Bryan: we could just list the types of functions that could be controlled by whitelists in tyhe document and leave the details out
... we can just list the functions e.g. don't modify this user agent or that site

Francois: the listing of the functions is where the opinion divergence happens

Heiko: we had another item about the manipulation of other headers as well; we can expand the user-agent mod control whitelist text (if we had it) to include other headers as well

Francois: the relationship between whitelists and headers is unclear

Heiko: to control the changing of the user agent for specific pages

<Zakim> rob, you wanted to say we don't want to go into too much detail

Heiko: the decision on whether the UA is changed should be the site provider's

Rob: we should not go into too much detail about the purpose of the controls; just note that there may be functions that control the automatic behavior

Bryan: I can try to provide some more generic text that will hopefully be useful

<francois> ACTION: Bryan to provide some text on whitelists to see if we can include them somehow and come to an agreement re. LC-2003 [recorded in http://www.w3.org/2008/09/23-bpwg-minutes.html#action01]

<trackbot> Created ACTION-850 - Provide some text on whitelists to see if we can include them somehow and come to an agreement re. LC-2003 [on Bryan Sullivan - due 2008-09-30].

LC-2068: on requests that contain Cache-Control: no-transform directives

<francois> Jo's proposal

<francois> "If the request contains a Cache-Control:

<francois> no-transform directive proxies must follow HTTP sections 14.9.5 and

<francois> 13.5.2."

Francois: HTTP RFC talks about presence of the cache control header; we need to improve the clarity of the text and would like to hear proposals for that
... text in the CT guidelines of course...

<andrews> I think that we should leave the text unchanged.

<francois> "If the request contains a Cache-Control: no-transform

<francois> directive proxies must forward the request unaltered to the server,

<francois> other than to comply with transparent HTTP behaviour and as noted

<francois> below."

Francois: we could clarify the "as noted below" part.

<francois> "If the request contains a Cache-Control: no-transform directive proxies must forward the request unaltered to the server, other than to comply with transparent HTTP behavior and as noted below (see 4.1.6 Additional HTTP Headers)"

Andrew: would not suggest any changes; it would probably just make it less clear

Francois: we could ref the transparent HTTP behavior, but the whole spec is assumed to be on top of HTTP anyway

<francois> PROPOSED RESOLUTION: re. LC-2068, we think the text is as clear as possible. Stick to the text in the spec.

<andrews> +1

<francois> +1

+1

<hgerlach> +1

<rob> +1

RESOLUTION: re. LC-2068, we think the text is as clear as possible. Stick to the text in the spec.

LC-2008: on use of Vary header

<francois> Jo's proposal

<tomhume> Apologies to all, I'm unable to keep a mobile signal here and am about to lose net.connection :(

<francois> "If a server varies its representation according to examination of

<francois> received HTTP headers then it must include a Vary HTTP header indicating

<francois> the headers it examines in accordance with [ref].

<francois> "

Francois: The text is too long and thus obscure; Jo proposes to simplify the text

<francois> Current text: "If a server varies its representation according to examination of

<francois> received HTTP headers then it must include a Vary HTTP header indicating

<francois> this to be the case. If, in addition to, or instead of HTTP headers, a

<francois> server varies its representation based on other factors (e.g. source IP

<francois> Address) then it must, in accordance with [RFC 2616

<francois> HTTP]<http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/#ref-HTTP>,

<francois> include a Vary header containing the value '*'.

<francois> "

Francois: fine with Jo's proposal; we don't need to restate the RFC; readers can go there to get details

<andrews> Agree

<francois> PROPOSED RESOLUTION: re. LC-2008, update the text according to Jo's proposal, as pasted above

<andrews> +1

<rob> +1

<francois> +1

RESOLUTION: re. LC-2008, update the text according to Jo's proposal, as pasted above

LC-2090, LC-2091 on headers/footers

<francois> Heiko's proposal

Heiko: adpated pages could include headers/footers, for non-adapted pages we should not add these

Francois: these should be out ot scope of the document; there were comments on copyright issues

<Zakim> rob, you wanted to agree that just because it's possible does not mean it's recommended

Bryan: we should leave this off the table

<francois> PROPOSED RESOLUTION: re. LC-2090, leave headers/footers off the table. Out of scope of this document.

rob: agree that just because it's possible does not mean it's recommended

<hgerlach> -1

<francois> linked to http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0004.html

Heiko: with RC-2025, we discussed changes related to request for more details; now we are being less specific

<hgerlach> ok, bye

Francois: suggests that people think about this over the list in the meantime

Summary of Action Items

[NEW] ACTION: Bryan to provide some text on whitelists to see if we can include them somehow and come to an agreement re. LC-2003 [recorded in http://www.w3.org/2008/09/23-bpwg-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/09/23 15:37:40 $