See also: IRC log
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
<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.
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].
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
<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.
<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.
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
<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