See also: IRC log
<trackbot> Date: 01 July 2008
<hgerlach> Hey isn't it Vodafone?????
scribe andrews
francois: Switch from informative to normative status of guidelines
<francois> rechartering questionnaire
francois: Please remind AC reps of questionnaire. Ends 28 July.
francois: Remaining issue. Views sent last Friday
<francois> fd's email
<francois> Sean's reply
francois: Overview of issue 242:
About section 3.2. About control of proxy behaviour.
... Document is not clear whether there are controls for this
part of guidelines.
... Need to move section 3.2 into section 4.
... Jo says we should not put policies into guidelines.
... Jo has pointed out that guidelines suggest that content
servers should allow user selection of mobile or desktop
versions but CT proxy would not know this choice is
available.
... We should not try to reslove now but wait fo the updated
draft.
... I propose that we remove section 3.2 and state controls in
section 4.
<francois> PROPOSED RESOLUTION: goal is to integrate bits of current section 3.2 explicitly into current section 4, where ever they apply, for clarification purpose.
+1
Bryan: Previously made some proposals. [clarifying proposal]
francois: Risk is that guidelines
could be too loose and anyone could claim compliance.
... Don't want to be too normative, too strict.
Bryan: People have different perspectives. Practice sometimes demands secondary mechanisms.
francois: We need to leave room for impementations to allow vendors room to deploy practically.
Bryan: CT is one component in proxy layer. In practice roles cannot be easily separated.
francois: Difficult to move all
3.2 into section 4.
... may result in a more obscure document.
But we should move as much as we can and be explicit when we can.
Bryan: We should use "should" whenever possible rather than "shall".
francois: In fact there are not many "must"s in the document so we don't force behaviour too much.
<francois> PROPOSED RESOLUTION: goal is to integrate as much of current section 3.2 as is practical to current section 4, where ever they apply, for clarification purpose.
+1
<Bryan> +1
<SeanP> +1
<francois> +1
RESOLUTION: goal is to integrate as much of current section 3.2 as is practical to current section 4, where ever they apply, for clarification purpose.
<francois> PROPOSED RESOLUTION: Move first bullet list in section 3.2.1 "Transformation proxies SHOULD provide to their users" to section 4.4.
<SeanP> +1
<francois> +1
RESOLUTION: Move first bullet list in section 3.2.1 "Transformation proxies SHOULD provide to their users" to section 4.4.
<francois> PROPOSED RESOLUTION: drop section 3.2.2, since it's already explicitly explained in section 4
+1
<SeanP> +1
<francois> +1
RESOLUTION: drop section 3.2.2, since it's already explicitly explained in section 4
francois: Now for the tricky
part...
... Drop terms and conditions of service. These are out of
scope of the document.
Sean: We should leave mention in document. Part of specifying user's choices is a practical matter.
francois: Allow list. This could be put into section 4 as an algortihm
hgerlach: Recommend an allow list
for different user agent
... maybe the problem is the name "allow list". Maybe it should
be called a "taylor list".
francois: Don't think the name is
too important. Allow list is to enable sites to register on
such a list but content providers would have to register on
many lists and this would not be practical.
... We should allow an "allow list" but indicate that the list
is refreshed from time to time so that the list evolves. This
would allow evolving sites to be accommodated.
Bryan: Current wording is OK.
Danger in softening wording and making it too general.
... Some content providers may not have the ability or means to
put correct semantics into site so a list is a practical
approach.
... 1st part of section is clear. Last sentence is probably too
strict.
francois: If both parties agree
how to handle content the guidelines do not need to be applied.
This was agreed in the face-to-face meeting.
... In generic case, where there is no dialogue between CT
provider and content provider, it would be difficult to have to
apply to join lists for each operator.
... Better to have use of lists in scope and state when they
apply.
SeanP: Agree with Bryan - language is a little too strong. Just need to state that in general lists can be impractical.
hgerlach: Different lists... bypass list is used today, likely to be small in future. But need an allow list to allow different user-agents for specific pages or URL or site.
Bryan: If we move the statements
into the normative part of the document, it makes sense.
... Global allow list with specific exceptions should enable
easy deployment.
hgerlach: No issue in updating bypass list, not sure that they will be changed regularly.
Bryan: 3.2.3 statements OK but not clear how these can be included in section 4
francois: There are problems for
content providers when they do not know that they are on a
list.
... Move lists to section 4?
Bryan: Does 3.2.3 add anything?
<francois> Request resource with original headers
<francois> - If the response is a 406 response, re-request with altered headers (unless the 406 response contains no-transform).
<francois> - If the response is a 200 response,
<francois> -- if the response contains vary: User-Agent, an appropriate link element or header, or no-transform, forward it
<francois> -- otherwise assess (by unspecified means) whether the 200 response is a bogus one
<francois> --- if it is not, forward it
<francois> --- if it is, re-request with altered headers
francois: Intention is to rewrite
so that there is room for interpretation. In this case an allow
list could be used.
... Give content transformation vendors freedom to
implement
Bryan: Would change reference to bogus 200 response - this is not clear.
francois: Will summarise discussion in mailing list.