- From: Francois Daoust <fd@w3.org>
- Date: Tue, 01 Jul 2008 17:54:51 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
The minutes of today's call are available at:
http://www.w3.org/2008/07/01-bpwg-minutes.html
... and copied as text below.
Resolutions taken during the call on remaining issue:
- 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.
- Move first bullet list in section 3.2.1 "Transformation proxies SHOULD
provide to their users" to section 4.4.
- drop section 3.2.2, since it's already explicitly explained in section 4
I'll send an update later this week of the discussion we had.
Feel free to continue the discussion on the mailing-list as well!
Francois.
01 Jul 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0000.html
See also: [3]IRC log
[3] http://www.w3.org/2008/07/01-bpwg-irc
Attendees
Present
Francois, Bryan_Sullivan, andrews, hgerlach, SeanP
Regrets
Jo
Chair
francois
Scribe
andrews
Contents
* [4]Topics
1. [5]Re-chartering process
2. [6]Issue 242
* [7]Summary of Action Items
_________________________________________________________
<trackbot> Date: 01 July 2008
<hgerlach> Hey isn't it Vodafone?????
scribe andrews
Re-chartering process
francois: Switch from informative to normative status of guidelines
<francois> [8]rechartering questionnaire
[8] http://www.w3.org/2002/09/wbs/33280/MWBP-CT-rechartering/
francois: Please remind AC reps of questionnaire. Ends 28 July.
Issue 242
francois: Remaining issue. Views sent last Friday
<francois> [9]fd's email
[9]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0042.html
<francois> [10]Sean's reply
[10]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0044.html
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.
Summary of Action Items
[End of minutes]
Received on Tuesday, 1 July 2008 15:55:25 UTC