IRC log of bpwg on 2008-07-01

Timestamps are in UTC.

13:56:48 [RRSAgent]
RRSAgent has joined #bpwg
13:56:48 [RRSAgent]
logging to http://www.w3.org/2008/07/01-bpwg-irc
13:56:50 [trackbot]
RRSAgent, make logs public
13:56:50 [Zakim]
Zakim has joined #bpwg
13:56:52 [trackbot]
Zakim, this will be BPWG
13:56:52 [Zakim]
ok, trackbot; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 4 minutes
13:56:53 [trackbot]
Meeting: Mobile Web Best Practices Working Group Teleconference
13:56:53 [trackbot]
Date: 01 July 2008
13:56:56 [francois]
Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0000.html
13:57:12 [francois]
Chair: francois
13:57:52 [francois]
Regrets: Jo
14:01:37 [Zakim]
MWI_BPWG(CTTF)10:00AM has now started
14:01:45 [Zakim]
+Francois
14:01:49 [Bryan]
Bryan has joined #bpwg
14:03:52 [Zakim]
+ +0793201aaaa
14:03:56 [Zakim]
+Bryan_Sullivan
14:04:18 [Bryan]
Bryan has joined #bpwg
14:04:41 [Zakim]
+andrews
14:04:53 [Zakim]
- +0793201aaaa
14:05:39 [hgerlach]
hgerlach has joined #bpwg
14:06:12 [Zakim]
+[Vodaphone]
14:06:31 [hgerlach]
Hey isn't it Vodafone?????
14:06:34 [francois]
zakim, who is on the phone?
14:06:34 [Zakim]
On the phone I see Francois, Bryan_Sullivan, andrews, [Vodaphone]
14:06:36 [dom]
dom has joined #bpwg
14:06:53 [francois]
zakim, [vodaphone] is really hgerlach
14:06:53 [Zakim]
+hgerlach; got it
14:10:52 [andrews]
scribe andrews
14:11:21 [andrews]
topic: chartering process
14:11:52 [andrews]
francois: Switch from informative to normative status of guidelines
14:12:10 [francois]
-> http://www.w3.org/2002/09/wbs/33280/MWBP-CT-rechartering/ rechartering questionnaire
14:12:42 [andrews]
...Please remind AC reps of questionnaire. Ends 28 July.
14:12:54 [andrews]
Topic: Issue 242
14:13:19 [andrews]
francois: Remaining issue. Views sent last Friday
14:13:24 [francois]
-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0042.html fd's email
14:13:35 [francois]
-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0044.html Sean's reply
14:14:40 [SeanP]
SeanP has joined #bpwg
14:15:31 [andrews]
...Overview of issue 242: About section 3.2. About control of proxy behaviour.
14:15:39 [Zakim]
+SeanP
14:16:13 [andrews]
...Document is not clear whether there are controls for this part of guidelines.
14:17:13 [andrews]
...Need to move section 3.2 into section 4.
14:17:53 [andrews]
...Jo says we should not put policies into guidelines.
14:20:00 [andrews]
...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.
14:20:36 [andrews]
...We should not try to reslove now but wait fo the updated draft.
14:21:11 [andrews]
...I propose that we remove section 3.2 and state controls in section 4.
14:21:37 [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.
14:22:16 [Bryan]
q+
14:22:20 [andrews]
+1
14:22:21 [francois]
ack Bryan
14:23:42 [andrews]
Bryan: Previously made some proposals. [clarifying proposal]
14:25:00 [andrews]
francois: Risk is that guidelines could be too loose and anyone could claim compliance.
14:25:23 [andrews]
...Don't want to be too normative, too strict.
14:27:08 [andrews]
...Bryan: People have different perspectives. Practice sometimes demands secondary mechanisms.
14:27:39 [andrews]
s/...Bryan/Bryan/
14:28:51 [andrews]
francois: We need to leave room for impementations to allow vendors room to deploy practically.
14:29:43 [andrews]
Bryan: CT is one component in proxy layer. In practice roles cannot be easily separated.
14:31:14 [andrews]
francois: Difficult to move all 3.2 into section 4.
14:31:31 [andrews]
...may result in a more obscure document.
14:32:02 [andrews]
But we should move as much as we can and be explicit when we can.
14:32:31 [andrews]
Bryan: We should use "should" whenever possible rather than "shall".
14:33:12 [andrews]
francois: In fact there are not many "must"s in the document so we don't force behaviour too much.
14:33:28 [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.
14:33:51 [andrews]
+1
14:34:14 [Bryan]
+1
14:34:16 [SeanP]
+1
14:34:19 [francois]
+1
14:34:23 [andrews]
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.
14:34:40 [francois]
PROPOSED RESOLUTION: Move first bullet list in section 3.2.1 "Transformation proxies SHOULD provide to their users" to section 4.4.
14:35:43 [SeanP]
+1
14:35:48 [francois]
+1
14:35:57 [andrews]
RESOLUTION: Move first bullet list in section 3.2.1 "Transformation proxies SHOULD provide to their users" to section 4.4.
14:36:08 [francois]
PROPOSED RESOLUTION: drop section 3.2.2, since it's already explicitly explained in section 4
14:36:42 [andrews]
+1
14:36:54 [SeanP]
+1
14:36:56 [francois]
+1
14:37:07 [andrews]
RESOLUTION: drop section 3.2.2, since it's already explicitly explained in section 4
14:37:27 [andrews]
francois: Now for the tricky part...
14:38:19 [andrews]
...Drop terms and conditions of service. These are out of scope of the document.
14:38:35 [SeanP]
q+
14:38:42 [francois]
ack SeanP
14:39:32 [andrews]
Sean: We should leave mention in document. Part of specifying user's choices is a practical matter.
14:40:39 [andrews]
francois: Allow list. This could be put into section 4 as an algortihm
14:41:28 [andrews]
hgerlach: Recommend an allow list for different user agent
14:42:09 [andrews]
...maybe the problem is the name "allow list". Maybe it should be called a "taylor list".
14:43:38 [Bryan]
q+
14:43:52 [andrews]
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.
14:45:13 [francois]
ack Bryan
14:45:23 [andrews]
...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.
14:46:17 [andrews]
Bryan: Current wording is OK. Danger in softening wording and making it too general.
14:47:26 [andrews]
...Some content providers may not have the ability or means to put correct semantics into site so a list is a practical approach.
14:48:23 [andrews]
...1st part of section is clear. Last sentence is probably too strict.
14:49:20 [andrews]
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.
14:50:06 [SeanP]
q+
14:50:43 [andrews]
...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.
14:51:09 [Bryan]
q+
14:52:07 [andrews]
...Better to have use of lists in scope and state when they apply.
14:52:15 [francois]
ack SeanP
14:53:06 [andrews]
SeanP: Agree with Bryan - language is a little too strong. Just need to state that in general lists can be impractical.
14:54:21 [andrews]
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.
14:54:40 [francois]
ack Bryan
14:55:37 [andrews]
Bryan: If we move the statements into the normative part of the document, it makes sense.
14:57:06 [andrews]
...Global allow list with specific exceptions should enable easy deployment.
15:00:00 [andrews]
hgerlach: No issue in updating bypass list, not sure that they will be changed regularly.
15:00:37 [andrews]
Bryan: 3.2.3 statements OK but not clear how these can be included in section 4
15:01:45 [andrews]
francois: There are problems for content providers when they do not know that they are on a list.
15:02:02 [andrews]
...Move lists to section 4?
15:03:44 [andrews]
Bryan: Does 3.2.3 add anything?
15:04:19 [francois]
Request resource with original headers
15:04:19 [francois]
- If the response is a 406 response, re-request with altered headers (unless the 406 response contains no-transform).
15:04:19 [francois]
- If the response is a 200 response,
15:04:19 [francois]
-- if the response contains vary: User-Agent, an appropriate link element or header, or no-transform, forward it
15:04:20 [francois]
-- otherwise assess (by unspecified means) whether the 200 response is a bogus one
15:04:22 [francois]
--- if it is not, forward it
15:04:24 [francois]
--- if it is, re-request with altered headers
15:05:46 [Bryan]
q+
15:05:50 [francois]
ack Bryan
15:05:55 [andrews]
francois: Intention is to rewrite so that there is room for interpretation. In this case an allow list could be used.
15:07:57 [andrews]
francois: Give content transformation vendors freedom to implement
15:08:47 [andrews]
Bryan: Would change reference to bogus 200 response - this is not clear.
15:11:44 [andrews]
francois: Will summarise discussion in mailing list.
15:12:56 [Zakim]
-hgerlach
15:13:07 [Zakim]
-Bryan_Sullivan
15:13:13 [Zakim]
-Francois
15:13:16 [Zakim]
-SeanP
15:13:24 [francois]
RRSAgent, draft minutes
15:13:24 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/07/01-bpwg-minutes.html francois
15:13:43 [Zakim]
-andrews
15:13:44 [Zakim]
MWI_BPWG(CTTF)10:00AM has ended
15:13:45 [Zakim]
Attendees were Francois, +0793201aaaa, Bryan_Sullivan, andrews, hgerlach, SeanP
15:13:57 [francois]
RRSAgent, draft minutes
15:13:57 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/07/01-bpwg-minutes.html francois
17:24:46 [Zakim]
Zakim has left #bpwg