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