Mobile Web Best Practices Working Group Teleconference

Test the effect of HEAD Requests on Various Servers

francois: we were wondering whether our advice to convert HEAD to GET might produce real problems

<francois> PROPOSED RESOLUTION: No identified problem associated with switching a HEAD request to a GET request, other than the fact that server statistics are impacted. No text change in 4.1.1 on that regard.

francois: did tests to ensure that when one sends a HEAD to a CGI/JSP/etc page, then the code gets executed as if it were a GET - which makes sense IMHO because server needs to know Content-Length of response it will return, and therefore needs to run any code to produce this

<EdC> +1

<rob> +1

+1

RESOLUTION: No identified problem associated with switching a HEAD request to a GET request, other than the fact that server statistics are impacted. No text change in 4.1.1 on that regard.

<francois> ACTION-710?

<trackbot> ACTION-710 -- François Daoust to test the Effect of HEAD Requests on Various Servers -- due 2008-07-16 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/710

<francois> close ACTION-710

<trackbot> ACTION-710 Test the Effect of HEAD Requests on Various Servers closed

LC-2097 - Review of OPES work

<francois> Jo's review of OPES work

<francois> PROPOSED RESOLUTION: Ref-2097 resolve yes and add a section under 1.3 scope noting that OPES RFC 3238 is relevant to this work and has been reviewed.

francoise: review triggered by LC comment from the IAB. Jo couldn't identify any problem.

edC: if OPES is relevant, what's its impact?

francois: OPES is an offshoot of RFC. It describes high-level non-transparent proxies and services. Transcoding could be described as an OPES service.
... it doesn't have any strong binding to what we're doing now.
... the IAB sent us a LC comment saying it looks like OPES. It's a set of guidelines to be followed by non-transparent proxies, to be respectful of the environment.
... purpose of Jo's review was to determine whether these had any impact on CTG.

<EdC> +1

+1

<rob> +1

<francois> +1

RESOLUTION: Ref-2097 resolve yes and add a section under 1.3 scope noting that OPES RFC 3238 is relevant to this work and has been reviewed.

Editorial comments from Eduardo

francois: Most of these are editorial comments not requiring discussion, suggest we action Jo to do them in his absence

<EdC> +1

+1 to anything that keeps Jo busy

<francois> ACTION: Jo to take the editorial comments in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.html into account for next version of the draft [recorded in http://www.w3.org/2008/12/02-bpwg-minutes.html#action01]

<trackbot> Created ACTION-889 - Take the editorial comments in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.html into account for next version of the draft [on Jo Rabin - due 2008-12-09].

LC-2050 - Restructuring, recoding, optimizing

francois: we had resolved we would keep the definition, even though they're vague, and that we'll say that we're only talking about restructuring.
... whilst preparing the new draft, Jo said it didn't make sense any more. I tend to agree with him in that we're not doing much with these definitions right now
... but we're not restricting ourselves to restructuring in the guidelines

edC: to be very logical, if those differences aren't meaningful in the document, they shouldn't be set as definitions. We should just give examples in the intro.

francois: we use the terms restructuring and recoding are used in the "decision to transform" section.
... if they're not used, we don't need to list them as definitions. But they still make sense in an introductory section.
... what Jo referred to here was the resolution we took saying we would only refer to restructuring does not make sense.
... suggest we leave things as they are now and come back to this later.

<francois> PROPOSED RESOLUTION: ref. definitions of restructuring, recoding, optimizing, leave things as they stand and get back to it in the end. If the definitions are not used in the guidelines, then lessen the wording (not need to use "definitions" if we don't make use of the term)

<rob> +1

+1

<EdC> +1

<francois> +1

RESOLUTION: ref. definitions of restructuring, recoding, optimizing, leave things as they stand and get back to it in the end. If the definitions are not used in the guidelines, then lessen the wording (not need to use "definitions" if we don't make use of the term)

<francois> ACTION-832?

<trackbot> ACTION-832 -- Sean Patterson to look at what the impact on the document would be if we removed the definitions referred to in LC-2050 -- due 2008-09-07 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/832

<francois> Close ACTION-832

<trackbot> ACTION-832 Look at what the impact on the document would be if we removed the definitions referred to in LC-2050 closed

Cached responses and pagination

<francois> "SHOULD provide a simple means of retrieving a fresh copy"

rob: if we respect the cache-control: no-cache (or revalidate, or whatever) that happens when you do a refresh from the handset menu, there's no need to do anything specific re what you put on the screen

francois: is this not the case where a CT proxy paginates the response and sends the paginated response to the user, and the user clicks next a couple of times. In this case the interaction with the proxy doesn't normally go back to the origin server
... if the response has expired the proxy should tell the user and provide a means to retrieve a fresh copy of the resource, to see if it has changed.
... It was a feature considered "at risk", that didn't receive a lot of comments.

francois: If it's a blog, for instance, and the response is paginated it will be confusing to tell the user "there may be a new version available, but maybe not".
... so the question is, there is a SHOULD. Is there any reason why it's not a MUST?

EdC: has the issue of why the caching properties associated within the originating content don't propagate to the fragments been discussed?

francois: if you start paginating the response and you send the first page to the user, he'll click on NEXT and the proxy will have to refetch the newest version of the page.
... if the message changes in the meantime, what's the CT proxy to serve?
... should it return to p1 or p2 in a new version

rob: the origin server should probably only see 1 request for a page

francois: we have this section remaining because it goes against caching directives.
... this is why we have the second part of the guideliens
... from a UE POV this doesn't make sense, from a technological POV it does

EdC: until we see a reason for this not to be the case, should it not be a MUST?

rob: this would be on lots of pages where large pieces of content are split, as many web sites send no caching directives, so you have to assume content is stale.

francois: this is why I don't think the guideline is useful at all.

rob: if the effect is that nearly every page contains the warning "this page may be out of date"...

francois: I think the notification saying "this page may be out of date" would be a bit of a burden on every page.
... one could still have a link to refresh the view.

rob: The latter doesn't need to be a link on the page, as long as cache-control: must-revalidate is observed then there is a simple means of retrieving a fresh copy.
... clicking on NEXT page for example, would serve me a second page of the page I got a couple of minutes ago. You can guide the user to refresh from the handset.
... in which case the handset can send a new header it wouldn't normally send, inviting the proxy to update the page.

francois: that's a bit of a "power user" feature... is it a "simple means"?

<EdC> The idea of (whomever spoke) is that the exact refresh may vary and does not need to be specified in the CTG.

francois: don't feel strongly one way or the other

rob: me neither, but if we're only talking about the second SHOULD then, this SHOULD should be a MUST
... the other part of Eduardo's message was that paginating responses isn't clear. Is it the first time it's mentioned?

edC: it's only mentioned in the two types of transformation.
... a short sentence to clarify would be nice.

rob: needs to leave, happy to have second SHOULD replaced by MUST

<francois> PROPOSED RESOLUTION: Add a short sentence on "pagination" first time it is mentioned to clarify what we mean

+1

<EdC> +1

<francois> +1

RESOLUTION: Add a short sentence on "pagination" first time it is mentioned to clarify what we mean

<francois> ACTION: Eduardo to provide a short definition of "pagination". [recorded in http://www.w3.org/2008/12/02-bpwg-minutes.html#action02]

<trackbot> Created ACTION-890 - Provide a short definition of \"pagination\". [on Eduardo Casais - due 2008-12-09].

<EdC> +1

+1

<francois> PROPOSED RESOLUTION: replace SHOULD by MUST in "and [proxies] SHOULD provide a simple means of retrieving a fresh copy"

<rob> +1

<francois> +1

francois: does the use case Rob mentioned (clicking refresh in the menu) fit the definition of "something provided by the proxy"?
... is this a question of its respecting the simple means provided by the browser.

yes

edC: Rob said that "the simple means" is "the user clicking a refresh on their browser triggers the proxy to refetch the content"

francois: yes
... does the guideline embrace this case? I think so

<EdC> +1

+1

<francois> +1

RESOLUTION: replace SHOULD by MUST in "and [proxies] SHOULD provide a simple means of retrieving a fresh copy"

francois: we shouldn't go too far today as there's only the three of us left
... otherwise we run the risk of resolving things without true consensus

francois: would like Jo to be here to experience the joy of "Validation against formal published grammar (4.2.8.1)"
... eduardo (+?) is strongly in favour of well-formedness. I don't strongly object, but it feels too strong.

Testing

<francois> ACTION: eduardo to provide some text to clarify the intent of the Testing section [recorded in http://www.w3.org/2008/12/02-bpwg-minutes.html#action03]

<trackbot> Created ACTION-891 - Provide some text to clarify the intent of the Testing section [on Eduardo Casais - due 2008-12-09].

francois: remaining topics need more participants.

Implementation Conformance Statement

francois: In the light of LC comments received, many commenters felt SHOULDs weren't strong enough
... the ICS is here to address this, which is why we add in this section "a conformant product must provide explanation when it doesn't follow SHOULD statements"

<francois> fd's email on ICS

francois: Eduardo, I've seen your comments and have the same questions.
... started by putting in all the normative statements from the guidelines. The MUSTs and MUST NOTs give us another guidelines doc (!)
... one suggestion is that we have some preliminary clause saying "I follow all the MUST and MUST NOTs" so we can focus on SHOULD/SHOULD NOTs
... an ICS document SHOULD contain all the normative statements

edC: I'm tempted to say the MUSTs should be there, but how can we put them there without a huge list?

francois: the doc is automatically generated by XSLT. I can try it out and you can see what you prefer?

edC: you will have statements mixing MUST and SHOULD though...?

francois: agree there should be 1 statement per line
... each para contains SHOULD or SHOULD NOT

+1

<EdC> +1

edC: I presume that you are trying to deal with some hierarchical statements. You SHOULD do X, which means you should do A, B, C. If you don't do X, A B and C don't apply.

francois: that's not quite what I have in mind, but I haven't checked the statements. But if e.g. a CT proxy doesn't change request headers, then the SHOULD NOT modify request headers doesn't apply, because it's already being respected (!)

edC: often there's a column listing other statements that must be fulfilled if this one is fulfilled - i.e. dependencies.

francois: not sure we have that many hierarchies

Review actions

<francois> ACTION-846?

<trackbot> ACTION-846 -- François Daoust to prepare an Implementation Conformance Statement -- due 2008-09-29 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/846

<francois> Close ACTION-846

<trackbot> ACTION-846 Prepare an Implementation Conformance Statement closed

<francois> ACTION: Prepare an ICS with MUST/MUST NOT (to view if that's a good idea), try to add a "depends on" column, explain "Not applicable" or remove it. [recorded in http://www.w3.org/2008/12/02-bpwg-minutes.html#action04]

<trackbot> Sorry, couldn't find user - Prepare

<francois> ACTION: daoust to prepare an ICS with MUST/MUST NOT (to view if that's a good idea), try to add a "depends on" column, explain "Not applicable" or remove it. [recorded in http://www.w3.org/2008/12/02-bpwg-minutes.html#action05]

<trackbot> Created ACTION-892 - Prepare an ICS with MUST/MUST NOT (to view if that's a good idea), try to add a \"depends on\" column, explain \"Not applicable\" or remove it. [on François Daoust - due 2008-12-09].

francois: let's close, the remaining topics ought to have others here

edC: actions to review?

<francois> Actions

francois: action-730 has been postponed
... 830 is on bryan
... he's done it
... 833 is on Jo

<francois> ACTION-833?

<trackbot> ACTION-833 -- Jo Rabin to propose text against LC-2003 referring to the TF's earlier discussions about not referring to a Proxy's internal operation -- due 2008-09-09 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/833

<francois> Close ACTION-833

<trackbot> ACTION-833 Propose text against LC-2003 referring to the TF's earlier discussions about not referring to a Proxy's internal operation closed

francois: 834 is already taken into account in the latest version of the draft

<francois> ACTION-834?

<trackbot> ACTION-834 -- Robert Finean to draft a response to LC-2034 noting that the scope of CT as we mean it is limited to those methods -- due 2008-09-08 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/834

<francois> Close ACTION-834

<trackbot> ACTION-834 Draft a response to LC-2034 noting that the scope of CT as we mean it is limited to those methods closed

francois: action 843 refers to 4.1.5 where we have an open issue/discussion
... let's leave for now.
... 850 is on Bryan, re whitelists, he'd proposed to provide some text and hasn't so we're not mentioning them yet, but have an introductory text saying we're deliberately not mentioning them

<francois> ACTION-859?

<trackbot> ACTION-859 -- François Daoust to contact IETF TLS group and advise them of what we are thinking and ask for guidance on what to recommend to Content Provider about detecting the presence of a man-in-the-middle proxy -- due 2008-10-13 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/859

francois: 859 is done, but I haven't had replies other than "there's no real way to detect such a thing"

<francois> Close ACTION-859

<trackbot> ACTION-859 Contact IETF TLS group and advise them of what we are thinking and ask for guidance on what to recommend to Content Provider about detecting the presence of a man-in-the-middle proxy closed

francois: we have an open discussion on link rewriting as a whole

<francois> ACTION-860?

<trackbot> ACTION-860 -- Jo Rabin to add clarification to HTTPS rewriting to make it clear that the via header MUST be added -- due 2008-10-12 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/860

<francois> Close ACTION-860

<trackbot> ACTION-860 Add clarification to HTTPS rewriting to make it clear that the via header MUST be added closed

<francois> ACTION-864?

<trackbot> ACTION-864 -- Jo Rabin to redraft HTTPS section for discussion on list -- due 2008-10-21 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/864

<francois> Close ACTION-864

<trackbot> ACTION-864 Redraft HTTPS section for discussion on list closed

<francois> ACTION-865

<francois> ACTION-865?

<trackbot> ACTION-865 -- Jo Rabin to word smith resolution on LC-2069 in line with its spirit and come up with something a bit cleaner andmore comprehensible -- due 2008-10-27 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/865

<francois> LC-2069

francois: 2069 has been dealt with, we changed normative to non-normatively because we couldn't think of a normative way to word "regular web browsing"

<francois> Close ACTION-865

<trackbot> ACTION-865 Word smith resolution on LC-2069 in line with its spirit and come up with something a bit cleaner andmore comprehensible closed

<francois> ACTION-866?

<trackbot> ACTION-866 -- Jo Rabin to include text referencing resolution to LC-2003 -- due 2008-10-27 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/866

<francois> Close ACTION-866

<trackbot> ACTION-866 Include text referencing resolution to LC-2003 closed

francois: suggest we close now