IRC log of bpwg on 2008-10-20

Timestamps are in UTC.

06:40:31 [RRSAgent]: RRSAgent has joined #bpwg
06:40:31 [RRSAgent]: logging to http://www.w3.org/2008/10/20-bpwg-irc
06:40:33 [trackbot]: RRSAgent, make logs public
06:40:33 [Zakim]: Zakim has joined #bpwg
06:40:35 [trackbot]: Zakim, this will be BPWG
06:40:35 [Zakim]: ok, trackbot; I see MWI_BPWG()2:00AM scheduled to start 40 minutes ago
06:40:36 [trackbot]: Meeting: Mobile Web Best Practices Working Group Teleconference
06:40:36 [trackbot]: Date: 20 October 2008
06:40:48 [dom]: s/Teleconference/F2F Meeting Day 1/
06:40:57 [dom]: Chair: DKA, Jo
06:41:10 [dom]: Agenda: http://www.w3.org/2005/MWI/BPWG/Group/Meetings/Mandelieu/agenda.html
06:56:42 [jo]: jo has joined #bpwg
06:58:06 [SeanP]: SeanP has joined #bpwg
07:01:29 [rob]: rob has joined #bpwg
07:01:41 [dom]: -> http://www.w3.org/2002/09/wbs/35125/TPAC2008/registrants#bpwg Registrants for the F2F
07:02:01 [dom]: Present: Kai, Jeff, Francois, DKA, Dom, Jo, SeanP, Rob, Adam
07:02:25 [dom]: s/bpwg/mwbp/
07:02:37 [dom]: Present+ Nacho, Abel
07:03:55 [dom]: Regrets: Soonho
07:07:00 [francois]: Scribe: francois
07:07:03 [francois]: ScribeNick: rancois
07:07:08 [francois]: ScribeNick: francois
07:07:08 [dom]: ScribeNick: Dom
07:07:10 [dom]: ScribeNick: Dom
07:07:13 [dom]: Scribe: Dom
07:08:05 [dom]: DKA: Welcome to lovely Cannes-Mandelieu
07:09:03 [dom]: Observers: Brazilian office guys@@@
07:09:43 [dom]: s/@@@/ Vagner Diniz, @@@/
07:10:44 [dom]: Observers+ Manuel Serrano (INRIA)
07:11:10 [cgi-irc]: cgi-irc has joined #bpwg
07:11:17 [dom]: Topic: Logistics
07:12:09 [dom]: Scribes20am: Dom, Adam, Kai?
07:12:40 [dom]: Scribes20pm: Rob, SeanP, Jo, Francois
07:12:57 [cgi-irc]: zakim, cgi-irc is me
07:12:57 [Zakim]: sorry, cgi-irc, I do not recognize a party named 'cgi-irc'
07:14:54 [dom]: Present+ Jonathan, Seungyun
07:17:37 [dom]: Topic: Content Transformation Guidelines
07:17:57 [dom]: -> http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/0047.html detailed agenda for the review of last call comments
07:18:15 [dom]: Francois: our content transformation guidelines are in last call, and received quite a few comments
07:18:42 [dom]: ... we're at a stage where we're trying to agree on the resolutions to these comments
07:18:52 [dom]: ... we already took a couple of important resolutions in the task force
07:19:01 [dom]: ... first, we'll focus on content transformation proxies
07:19:24 [dom]: ... the current document gives guidance both to content providers and content transformation proxies vendors
07:19:28 [DKA]: DKA has joined #bpwg
07:19:45 [dom]: ... so we've decided to remove the normative statements for content providers, and we'll move them as informative only
07:20:02 [dom]: ... and keep the focus only on content transformation proxies
07:20:27 [dom]: ... the second resolution we've made was to soften the language used in HTTPs in the guidelines
07:20:45 [dom]: ... trying to make sure we do not endorse the rewriting of HTTPS links
07:21:06 [dom]: ... still trying to give guidance on how to do it correctly when you decide you want to do it
07:21:34 [dom]: Jo: We would like something even less acknowldeging as RFC2119-MAY
07:22:08 [dom]: ... as a presentational point, we're removing the MAY and will turn it into a conditional statement ("If you rewrite HTTPs links...")
07:22:29 [dom]: Francois: A certain number of comments we're received were based on a misinterpretation of our intent
07:22:51 [dom]: ... the rationales behind our normative statements were not always explicit, so we may need to add clarifications
07:22:59 [dom]: ... We won't discuss HTTPs today
07:23:18 [dom]: ... My goal today is to go through as many unresolved last call comments as possibly
07:24:40 [dom]: ... there are some comments that are re-raising tough issues on which we had difficulty finding consensus
07:25:06 [dom]: DKA: I think if there are no new elements brought on these issues, I think our default should be not to re-open the issue
07:25:40 [dom]: Jo: but we need to consider whether the comment introduce new information we hadn't seen before
07:25:41 [steph]: steph has joined #bpwg
07:26:07 [dom]: Francois: my message list comments roughly in the order of the document
07:26:24 [dom]: -> http://tinyurl.com/634lue Annotated view of the document with the lc comments
07:27:38 [dom]: ... starting with LC-2066, missing reference - proposing we accept it
07:28:18 [dom]: -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/ LC comments tracker on content transformation guidelines
07:28:35 [dom]: -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2066 LC-2066
07:29:05 [dom]: PROPOSED RESOLUTION: Accept LC-2066 and add the reference
07:29:16 [DKA]: +1
07:29:17 [francois]: +1
07:29:21 [dom]: RESOLUTION: Accept LC-2066 and add the reference
07:29:24 [jo]: +1
07:29:31 [SeanP]: +1
07:29:36 [rob]: +1
07:30:07 [dom]: Francois: next LC-2044 and 2069
07:30:13 [dom]: .. on section 4.1.3
07:30:50 [dom]: ... we want to restrict our guidelines to the "web browsing context"
07:31:19 [dom]: ... but we don't have a definition for that, and there is no way to technically distinguish those
07:31:37 [dom]: ... so putting normative statements on this is somewhat meaningless
07:33:25 [dom]: DKA: we could alter it to say "if you recognize it's not web browsing, you must not..."
07:33:39 [dom]: Rob: but how can you positively identify that?
07:34:10 [dom]: Francois: no existing proposed recommendation
07:34:28 [dom]: Jo: this text has been in for ages, proposed by Bryan
07:35:13 [dom]: ... maybe Bryan would have some additional input on that one?
07:36:02 [dom]: ... for 2044, I think we clarify that our intent was to target the values of the existing http headers, rather than their existence
07:36:09 [dom]: s/we cl/we can cl/
07:37:53 [jo]: PROPOSED RESOLUTION: Ref LC-2044 Resolve yes, and change the text to say "*values* of User Agent and Accecpt headers"
07:38:31 [dom]: s/Accec/Acce/
07:38:53 [jo]: PROPOSED RESOLUTION: Ref LC-2044 Resolve yes, and change the text to say "*values* of User Agent and Accecpt headers", and clarify that we do not propose guidance for new user agents' use of these headers, it is out of scop-e
07:39:15 [dom]: RESOLUTION: Ref LC-2044 Resolve yes, and change the text to say "*values* of User Agent and Accecpt headers", and clarify that we do not propose guidance for new user agents' use of these headers, it is out of scope
07:39:21 [rob]: +1
07:57:56 [DKA]: DKA has joined #bpwg
07:58:21 [aconnors]: aconnors has joined #bpwg
07:58:44 [SeanP]: SeanP has joined #bpwg
07:59:09 [rob]: rob has joined #bpwg
08:01:58 [dom]: RRSAgent, draft minutes
08:01:58 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html dom
08:03:28 [sylee]: sylee has joined #bpwg
08:03:47 [jo]: jo has joined #bpwg
08:04:31 [JonathanJ]: JonathanJ has joined #bpwg
08:19:02 [dom]: ScribeNick: aconnors
08:19:06 [dom]: Scribe: Adam
08:20:36 [dom]: current text: "Proxies must act as though a no-transform directive is present (see 4.1.2 no-transform directive in Request) unless they are able positively to determine that the user agent is a Web browser. The mechanism by which a proxy recognizes the user agent as a Web browser should use evidence from the HTTP request, in particular the User-Agent and Accept headers."
08:22:09 [francois]: francois has joined #bpwg
08:22:40 [rob]: q+ to suggest "...if they identify the client is a web browser"
08:23:01 [DKA]: ack rob
08:23:01 [Zakim]: rob, you wanted to suggest "...if they identify the client is a web browser"
08:24:18 [aconnors]: Francois: LC-2070, mostly editorial issue.
08:24:31 [hendry]: hendry has joined #bpwg
08:24:52 [jo]: PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the replacement text: "Proxies should act as though a no-transform directive is present (see 4.1.2 no-transform directive in Request) if they have determined that the request has not been made for direct human presentation."
08:26:40 [Kai]: Kai has joined #bpwg
08:27:14 [Kangchan]: Kangchan has joined #bpwg
08:27:42 [aconnors]: francois: [ discussion on appropriate tweaking of first para in 4.1.4 ]
08:28:17 [jo]: PROPOSED RESOLUTION: Ref LC-2070, change para 1 to say "Aside from the usual caching procedures defined in RFC 2616, in some circumstances ..."
08:28:35 [jo]: PROPOSED RESOLUTION: Ref LC-2070, resolve yes, and change para 1 to say "Aside from the usual caching procedures defined in RFC 2616, in some circumstances ..."
08:28:42 [rob]: +1
08:28:45 [DKA]: +1
08:28:49 [francois]: +1
08:28:50 [SeanP]: +1
08:28:59 [aconnors]: RESOLUTION: Ref LC-2070, resolve yes, and change para 1 to say "Aside from the usual caching procedures defined in RFC 2616, in some circumstances ..."
08:29:22 [jo]: Topic: LC-2069
08:29:30 [jo]: current text: "Proxies must act as though a no-transform directive is present (see 4.1.2 no-transform directive in Request) unless they are able positively to determine that the user agent is a Web browser. The mechanism by which a proxy recognizes the user agent as a Web browser should use evidence from the HTTP request, in particular the User-Agent and Accept headers."
08:29:41 [jo]: PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the replacement text: "Proxies should act as though a no-transform directive is present (see 4.1.2 no-transform directive in Request) if they have determined that the request has not been made for direct human presentation."
08:30:04 [steph]: steph has joined #bpwg
08:31:03 [aconnors]: SeanP: "Direct human presentation" -- is it really clearer?
08:31:12 [aconnors]: ... liked "web browser".
08:35:08 [jo]: PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the replacement text: Before altering aspects of an HTTP request a transforming proxy should take reasonable steps to determine that "*the request is intended for direct human representaion*"
08:35:57 [aconnors]: dka: should we get more specific ?
08:36:05 [jo]: PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the replacement text: Before altering aspects of an HTTP request a transforming proxy should take reasonable steps to determine that "*the request is intended for direct human representaion*" and remove the second sentence ref User Agent and accept headers.
08:36:49 [dom]: (this means we'll have to amend our response to LC-2044)
08:37:34 [aconnors]: jo: Hard to be normative on this without writing a product spec.
08:38:02 [aconnors]: dka: Not sure that this statement means much.
08:39:42 [aconnors]: SeanP: Original intent of this recommendation was to not transform application data, an XHR request from a (potentially) transcoded page is a poor example since it might need subsequent transcoding.
08:40:33 [aconnors]: dka: Should we go back to using the word "web-browser".
08:40:48 [aconnors]: jo: Okay, just define what you mean by the word Web...
08:43:39 [hendry]: q+
08:43:48 [jo]: PROPOSED RESOLUTION: PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the replacement text: Before altering aspects of an HTTP request proxies should take account of the fact that HTTP is used as a transport mechanism for many other applications than "Traditional Browsing" and that alteration of HTTP requests for those applications can cause serious misoperation.
08:44:12 [DKA]: ack hend
08:44:48 [DKA]: q?
08:45:07 [dom]: Observer+ Kai_Hendry
08:45:59 [jo]: PROPOSED RESOLUTION: ref LC-2069. Resolved yes, with the replacement text: Before altering aspects of an HTTP request proxies ought to take account of the fact that HTTP is used as a transport mechanism for many other applications than "Traditional Browsing" and that alteration of HTTP requests for those applications can cause serious misoperation.
08:46:11 [francois]: +1
08:46:11 [dom]: +1
08:46:14 [DKA]: +1
08:46:17 [SeanP]: +1
08:46:26 [rob]: +1
08:47:48 [aconnors]: adam: Not convinced that this really adds clarity.
08:48:04 [aconnors]: jo: Lets take this action and move on, on the understanding that this needs some wordsmithing.
08:49:03 [jo]: ACTION: Jo to word smith resolution on LC-2069 in line with its spirit and come up with something a bit cleaner andmore comprehensible
08:49:03 [trackbot]: Created ACTION-865 - Word smith resolution on LC-2069 in line with its spirit and come up with something a bit cleaner andmore comprehensible [on Jo Rabin - due 2008-10-27].
08:49:20 [DKA]: q?
08:49:42 [francois]: PROPOSED RESOLUTION: re LC-2044, resolution on LC-2069 removes the part that required clarification, resolve partial, we won't talk about "use of evidence"
08:50:03 [jo]: rrsagent, make minutes
08:50:03 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html jo
08:50:21 [jo]: +1
08:50:23 [DKA]: +1
08:50:25 [francois]: +1
08:50:31 [SeanP]: +1
08:50:44 [aconnors]: RESOLUTION: ref LC-2069. Resolved yes, with the replacement text: Before altering aspects of an HTTP request proxies ought to take account of the fact that HTTP is used as a transport mechanism for many other applications than "Traditional Browsing" and that alteration of HTTP requests for those applications can cause serious misoperation.
08:50:52 [aconnors]: RESOLUTION: re LC-2044, resolution on LC-2069 removes the part that required clarification, resolve partial, we won't talk about "use of evidence"
08:51:12 [aconnors]: Topic: LC-2003 No mention of whitelists
08:52:14 [aconnors]: francois: Do we want to have this conversation or postpone.
08:52:30 [aconnors]: jo: Couple of points: whitelist / blacklist aren't good words.
08:53:37 [aconnors]: jo: Important that we don't make supositions on the internal working of transforming proxies...
08:54:08 [aconnors]: jo: Make a note that we don't refer to whitelist / blacklist for the following reasons, etc.
08:55:03 [jo]: PROPOSED RESOLUTION: Make a note about the reasons for not referring to lists, of whatever hue, because the preumption about the internal operation of proxies is not in scope, as far as we are concenred these are "black boxes"
08:56:12 [DKA]: +1
08:56:17 [SeanP]: +1
08:56:22 [francois]: +1
08:56:24 [rob]: +1
08:57:29 [aconnors]: RESOLUTION: Make a note about the reasons for not referring to lists, of whatever hue, because the preumption about the internal operation of proxies is not in scope, as far as we are concenred these are "black boxes"
08:57:49 [jo]: ACTION: Jo to include text referencing resolution to LC-2003
08:57:49 [trackbot]: Created ACTION-866 - Include text referencing resolution to LC-2003 [on Jo Rabin - due 2008-10-27].
08:58:02 [francois]: Above resolution was for LC-2003, for which we resolve no.
08:58:33 [aconnors]: Topic: LC-1996 et al ... Alteration of HTTP Header Values
08:59:11 [NEWTON_VAGNER_DIN]: NEWTON_VAGNER_DIN has joined #bpwg
09:00:23 [dom]: Observer+ AnnBassetti
09:00:29 [aconnors]: francois: Discussing which headers the proxy may reasonably change. We have a list of such headers, and have found no need to remove any headers (except possibly UAProf). We haven't found significant problems with changing the accept-headers since not generally used to identify device...
09:00:46 [abel]: abel has joined #bpwg
09:02:03 [jo]: q+ to respond to francois's eloquent peroration
09:02:47 [aconnors]: francois: Need to change User-Agent / UAProf because of long-tail of legacy Web pages... Should we send original headers in X-Device-*? Is there a need? And are we allowed to define new headers in our document?
09:04:03 [DKA]: ack jo
09:04:03 [Zakim]: jo, you wanted to respond to francois's eloquent peroration
09:04:26 [aconnors]: jo: Whilst I almost agree with everything francois has said, two issues...
09:05:57 [aconnors]: jo: Don't believe we are inventing new headers (X-Device-*) since they are already in use, just not written down.
09:06:32 [aconnors]: jo: If a content provider was previously returning a 406 to mobile user-agents but changes to support them, it needs the original device headers so it can tell the proxy to stop transforming.
09:06:39 [nacho]: nacho has joined #bpwg
09:07:08 [jo]: q+ to give another good reasonwhy they should be there
09:07:20 [aconnors]: francois: Vary header could answer this need.
09:07:25 [DKA]: ack jo
09:07:25 [Zakim]: jo, you wanted to give another good reasonwhy they should be there
09:07:55 [SeanP]: q+
09:08:03 [aconnors]: dka: If we don't specify what the header is then we are not providing such a good service than if we define it.
09:08:19 [dom]: [at least one reason for having the X-Device-* headers is statistics gathering]
09:08:24 [aconnors]: francois: Sure, but all we need is a flag ("There was a transformation") that the content provider can respond to and request the original request.
09:09:00 [dom]: [jo's making my point; how smart of him]
09:09:08 [aconnors]: jo: If original device user-agent is not available then there will be no log data indicating a need for a mobile device.
09:09:47 [DKA]: ack seanp
09:09:52 [aconnors]: rob: Original headers may expedite engineers making quick fixes.
09:11:07 [aconnors]: francois: The statistics argument is pretty convincing.
09:11:36 [DKA]: PROPOSED RESOLUTION: WRT 4.1.5 Don't change anything and say "no" to all the LC comments on this point (Francois to determine wich).
09:16:00 [jcantera]: jcantera has joined #bpwg
09:17:18 [dom]: [hmm... but aren't they other headers that *need* to be modified? http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 ]
09:17:27 [aconnors]: francois: Some LC comments say that the current version makes it too easy for CT-proxy providers to find an excuse change headers... Should we split headers into two groups? Changing accept-headers being less serious than UAProf, etc.
09:17:58 [jo]: PROPOSED RESOLUTION: WRT 4.1.5 Text remains substantially as is but is reinforced by saying the only acceptable headers to change are User Agent and Accept and not to delete headers
09:17:59 [dom]: [ e.g. "From"]
09:18:24 [Kangchan]: Kangchan has left #bpwg
09:18:58 [aconnors]: francois: Find with this, but don't think it addresses concerns.
09:19:04 [aconnors]: s/Find/Fine
09:20:03 [aconnors]: jo: What people are concerned with is that headers be removed that a content-provider was relying from... Suggest that whatever the proxy does, it should be possible to reconstruct the original request.
09:20:22 [aconnors]: SeanP: But what about the case where an operator / gateway adds a header that gets removed?
09:21:23 [jo]: PROPOSED RESOLUTION: WRT 4.1.5 Text remains substantially as is but is reinforced by saying the only acceptable headers to change are User Agent and Accept and not to delete headers the point being that by using X-Device plus headers that are present all headers the were sent by the UA and their values can be reconstructed by the server
09:21:53 [francois]: -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2046 LC-2046 on HTTP header deletion
09:22:36 [jo]: PROPOSED RESOLUTION: WRT 4.1.5 Text remains substantially as is but is reinforced by saying the only acceptable headers to change are User Agent and Accept(-*) and not to delete headers the point being that by using X-Device plus headers that are present all headers the were sent by the UA and their values can be reconstructed by the server
09:24:50 [jo]: PROPOSED RESOLUTION: WRT 4.1.5 Text remains substantially as is but is reinforced by saying that the CT proxy SHOULD NOT change headers and values other than User Agent and Accept(-*), MUST NOT delete headers and it MUST be psosible for the server to reconstruct the original UA originated headers by using X-Device etc.
09:25:20 [rob]: +1
09:25:28 [Kai]: ScribeNick: Kai
09:25:42 [francois]: +1
09:25:49 [SeanP]: +1
09:25:52 [DKA]: +1
09:25:55 [Kai]: +1
09:26:19 [nacho]: concur (+0)
09:26:20 [Kai]: RESOLUTION: WRT 4.1.5 Text remains substantially as is but is reinforced by saying that the CT proxy SHOULD NOT change headers and values other than User Agent and Accept(-*), MUST NOT delete headers and it MUST be psosible for the server to reconstruct the original UA originated headers by using X-Device etc.
09:27:07 [Kai]: Topic: LC-2074
09:28:33 [Kai]: francois: not everyone knows about this. I am fine with the text. It is a BP that we advise to do.
09:29:33 [Kai]: dom: we are saying http is nice but people may not handle it correctly.
09:29:53 [Kai]: francois: We want to downgrade the normative statement to a note
09:30:33 [Kai]: jo: sometimes you have to issue a get request
09:30:50 [Kai]: ...then there should be an intermediary page
09:31:19 [Kai]: dom: it is nice advice to give, but it is something we want CT proxies to evaluate?
09:31:33 [Kai]: jo: some are doing this routinely
09:32:02 [Kai]: francois: why don't we switch it back to informative only..the whole document
09:32:11 [Kai]: dka: I am going to shoot myself
09:32:28 [Kai]: francois: it is not the core of the problem at stake
09:32:48 [Kai]: jo: I think it is important based on the adverse reactions
09:33:31 [Kai]: ...people are sensitive to this and we should acknowledge this
09:33:42 [Kai]: francois: any objections to leaving it as is?
09:34:12 [Kai]: dka: in essence that is what we should do
09:34:27 [francois]: PROPOSED RESOLUTION: re. LC-2074, resolve no, this is a best practice we recommend to CT-proxies.
09:35:34 [francois]: PROPOSED RESOLUTION: re. LC-2074, resolve no. Based on our experience and feedback from servers whose operators take strong exception to this practice, we think it's reasonable to advise CT-proxies operators of this situation
09:35:41 [jo]: +1
09:35:43 [francois]: +1
09:35:46 [SeanP]: +1
09:35:47 [rob]: +1
09:35:52 [Kai]: RESOLUTION: re. LC-2074, resolve no. Based on our experience and feedback from servers whose operators take strong exception to this practice, we think it's reasonable to advise CT-proxies operators of this situation
09:36:05 [Kai]: Topic: LC-2075
09:36:52 [Kai]: francois: this is about what is identified as unacceptable responses
09:37:22 [Kai]: ...a CT proxy cannot differentiate here
09:38:28 [Kai]: ...i think we should keep the text and explain why we cannot specify the heuristics
09:38:41 [jo]: PROPOSED RESOLUTION: ref LC-2037 yes, we have removed PUT partly in response to your comment
09:39:03 [francois]: +1
09:39:03 [rob]: +1
09:39:03 [DKA]: +1
09:39:06 [SeanP]: +1
09:39:08 [Kai]: RESOLUTION: ref LC-2037 yes, we have removed PUT partly in response to your comment
09:39:57 [Kai]: [this was two part comment....thus the two resolutions]
09:40:03 [jo]: PROPOSED RESOLUTION: ref LC-2037 ref retrying POSTs, no, we agree that it shouldnot be necessary to point this out, but sadly it is
09:40:18 [SeanP]: +1
09:40:25 [francois]: +1
09:40:45 [rob]: +1
09:41:11 [Kai]: s/Topic: LC-2075/Topic: LC-2037
09:42:28 [jo]: PROPOSED RESOLUTION: LC-2075 differences in behaviour: the internal operation of the proxy is not open to our specification, we need to point out to CT proxies that 406 responses are not the only way in which content proivders signal that they can't or won't handle a request
09:43:04 [jo]: PROPOSED RESOLUTION: LC-2075 differences in behaviour: the internal operation of the proxy is not open to our specification, we need to point out to CT proxies that in practice 406 responses are not the only way in which content proivders signal that they can't or won't handle a request, though we do say that this is the preferred way of them doing so
09:43:56 [SeanP]: +1
09:43:58 [jo]: +1
09:44:01 [francois]: +1
09:44:03 [Kai]: +1
09:44:19 [rob]: +1
09:44:40 [dom]: +0.1
09:44:47 [Kai]: RESOLUTION: LC-2075 differences in behaviour: the internal operation of the proxy is not open to our specification, we need to point out to CT proxies that in practice 406 responses are not the only way in which content proivders signal that they can't or won't handle a request, though we do say that this is the preferred way of them doing so
09:45:43 [Kai]: Topic: LC-2075
09:46:35 [jo]: PROPOSED RESOLUTION: ref LC-2075, we have changed the text to refer only to POST and we acknowledge that this should not need restatement from RFC 2616 but we are aware of this kind of misoperation "in the wild"
09:46:48 [SeanP]: +1
09:47:06 [francois]: +1
09:47:14 [jo]: +1
09:47:40 [Kai]: RESOLUTION: ref LC-2075, we have changed the text to refer only to POST and we acknowledge that this should not need restatement from RFC 2616 but we are aware of this kind of misoperation "in the wild"
09:49:07 [Kai]: break and discussing dinner arrangements
09:50:16 [JonathanJ]: JonathanJ has joined #bpwg
09:57:47 [tlr]: tlr has joined #bpwg
09:59:07 [Kai]: Kai has joined #bpwg
09:59:26 [Kai]: ScribeNick: Kai
09:59:48 [Kai]: Topic: LC-2039
10:00:47 [Kai]: francois: the purpose of the text is to say that CT proxies need to behave consistently and the text needs clarification
10:01:25 [jo]: q+
10:01:45 [Kai]: ...you don't have to send the same headers if you are requesting an embedded resource
10:02:40 [dom]: [I think "form part of a representation" is what makes the usage of the word "representation" confusing]
10:03:14 [Kai]: jo: i recall we received many comments on basic tests noting that the content negotiation depends on the headers
10:03:32 [dom]: [part of a representation is a sequence of bytes, not a stylesheet or an image]
10:03:39 [Kai]: ....you could specifiy specific headers for each resource
10:03:58 [Kai]: ....in practice that not what browser do or servers implement
10:04:13 [Kai]: dom: firefox actually does that
10:04:20 [Kai]: jo: relying on this is unwise
10:04:47 [Kai]: ....it is relatively common for adaptation solution to regard headers in the whole rather than in the part
10:05:13 [Kai]: ....we are observing an in practice best practice
10:05:27 [dom]: q?
10:05:30 [dom]: ack jo
10:06:02 [Kai]: dom: mark is saying that giving the advice on a per header basis than the partial header is better
10:06:05 [DKA]: q?
10:06:21 [Kai]: ....content adaptation solutions are likely to use that
10:06:54 [Kai]: jo: we not allowing changes to the UAProf header
10:07:00 [Kai]: francois: just the UA header
10:07:04 [dom]: q+ to note ambiguity of "part of a representation"
10:07:10 [DKA]: ack
10:07:15 [DKA]: ack dom
10:07:15 [Zakim]: dom, you wanted to note ambiguity of "part of a representation"
10:07:47 [Kai]: dom: use of the term representation is confusing, from Mark. we need to change that.
10:08:03 [Kai]: ....is used to render the represenation
10:09:03 [Kai]: francois: I think we removed that wording from the latest draft of Basic Tests
10:09:34 [Kai]: Sean: could we say something like embedded resources?
10:09:44 [Kai]: dom: we can reformulate this later
10:10:06 [Kai]: jo: we use "vital to the rendering of that resource"
10:10:25 [Kai]: ...i am happy we have not used represenation incorrectly
10:11:02 [jo]: use the term "included resources" per the definition mobileOK Basic Tests
10:11:10 [Kai]: SeanP: if you don't change the headers of the top leavel document you should not change them for the images...is what we are saying
10:11:27 [Kai]: s/leveal/level
10:12:19 [jo]: PROPOSED RESOLUTION: Ref LC-2076 - yes, we will change the sue of the word representation and use something like "included resources"
10:12:34 [jo]: PROPOSED RESOLUTION: Ref LC-2076 - yes, we will change the use of the word representation and use something like "included resources"
10:12:36 [Kai]: s/Topic: LC-2039/Topic: LC-2076
10:12:47 [SeanP]: +1
10:12:49 [francois]: +1
10:12:54 [DKA]: +1
10:12:56 [rob]: +1
10:12:58 [Kai]: RESOLUTION: Ref LC-2076 - yes, we will change the use of the word representation and use something like "included resources"
10:13:42 [Kai]: Topic: Second part of LC-2076 and LC-2039
10:13:55 [jo]: PROPOSED RESOLUTION: ref LC-2039 and LC-2076: Yes, we will clarify that we are talking about keeping the User Agent Header consistent
10:14:11 [SeanP]: +1
10:14:18 [francois]: +1
10:14:23 [dom]: +1
10:14:23 [rob]: +1
10:14:29 [Kai]: RESOLUTION: ref LC-2039 and LC-2076: Yes, we will clarify that we are talking about keeping the User Agent Header consistent
10:14:29 [DKA]: +1
10:14:39 [francois]: s/ RESOLUTION/RESOLUTION
10:15:50 [Kai]: Topic: LC-2079
10:16:57 [Kai]: francois: section 4.2 will be changed from normative to informative
10:17:36 [jcantera]: jcantera has joined #bpwg
10:18:04 [jo]: PROPOSED RESOLUTION: ref LC-2079, yes, we intend to move server behaviour into a non-normative section and point out that servers may wish to respond with no-transform as this respects the intention of the requester
10:21:07 [jo]: PROPOSED RESOLUTION: ref LC-2041, LC-2080 and LC-2079, yes, we intend to move server behaviour into a non-normative section and point out that servers may wish to respond with no-transform if they think that this respects the intention of the requester and that for the sake of clarity use of 406 is clearer than using a default representation using 200 and the text "your browser is not supported"
10:21:28 [rob]: +1
10:22:21 [Kai]: dom: I don't think this responds to LC-2080 or LC-2�41
10:22:27 [Kai]: jo: I think it does
10:23:23 [Kai]: dom: are we still mentioning cache control?
10:23:42 [Kai]: francois: we are talking about cache control in the request not to transform
10:24:12 [nacho]: nacho has joined #bpwg
10:24:22 [SeanP]: +1
10:24:32 [Kai]: jo: I can't see a way around this. It is reasonable for us to say if there is a request not to transform the server can ...?
10:24:44 [Kai]: francois: we moving to non normative...
10:25:05 [francois]: +1
10:25:18 [DKA]: +1
10:25:19 [Kai]: RESOLUTION: ref LC-2041, LC-2080 and LC-2079, yes, we intend to move server behaviour into a non-normative section and point out that servers may wish to respond with no-transform if they think that this respects the intention of the requester and that for the sake of clarity use of 406 is clearer than using a default representation using 200 and the text "your browser is not supported"
10:25:35 [Kai]: Topic: LC-2045
10:25:52 [Kai]: francois: it is about restating RFC HTTP
10:26:05 [Kai]: ...we should not. we could use a link
10:26:10 [Kai]: jo: we repeat for emphasis
10:26:28 [Kai]: ...in cases for violation happens
10:26:44 [Kai]: francois: but why do we repeat here and not in other sections?
10:26:53 [Kai]: SeanP: he asks if we really mean it
10:27:22 [Kai]: jo: then this is in the wrong section. This is about server behavior.
10:28:08 [Kai]: francois: into which section should it go?
10:28:26 [Kai]: ...4.1.2 or 4.3.1
10:29:01 [dom]: (I updated the comment to reflect that it really is about 4.3.1)
10:29:04 [Kai]: ...we already have some text then....we may have to clarify this as we has some comment on it
10:29:18 [Kai]: SeanP: we are saying it twice already..
10:29:28 [Kai]: jo: we could insert a note for emphasis
10:29:37 [Kai]: francois: or put down a link
10:30:04 [Kai]: jo: to 13.5.2
10:30:36 [Kai]: dka: why don't you want to put in text to emphasize?
10:30:47 [Kai]: jo: it can't get much clearer than what we have
10:31:17 [Kai]: dka: why is it wrong to repeat?
10:31:25 [Kai]: jo: we don't want to restate http
10:31:43 [Kai]: dka: you are making an assumption that somebody would read http spec
10:31:47 [francois]: PROPOSED RESOLUTION: re. LC-2045, resolve partial, comment actually applies to 4.3.1 where it is emphasized that proxies MUST behave "transparently" with a link to the definition that contains links to sections 13.5.2 and 14.9.5 of RFC2616
10:31:52 [Kai]: jo: you would have to be
10:32:24 [dom]: (should we actually provide as an appendix with all the conformance requirements of http that would be relevant to a content transformation proxy?)
10:33:04 [jo]: [dom is welcome to make a contribution along those lines]
10:33:39 [SeanP]: +1
10:33:40 [DKA]: +1
10:33:41 [francois]: +1
10:34:15 [Kai]: RESOLUTION: re. LC-2045, resolve partial, comment actually applies to 4.3.1 where it is emphasized that proxies MUST behave "transparently" with a link to the definition that contains links to sections 13.5.2 and 14.9.5 of RFC2616
10:35:56 [Kai]: break for lunch reconvene 1:30
10:35:58 [francois]: ACTION: daoust to look into an appendix with relevant normative statements of RFC2616 and report back to the group.
10:35:58 [trackbot]: Created ACTION-867 - Look into an appendix with relevant normative statements of RFC2616 and report back to the group. [on François Daoust - due 2008-10-27].
10:36:23 [jo]: [break for lunch]
11:36:43 [dom]: zakim, this is bpwg
11:36:43 [Zakim]: dom, I see MWI_BPWG()2:00AM in the schedule but not yet started. Perhaps you mean "this will be bpwg".
11:36:53 [dom]: zakim, dial out room_riviera_a
11:36:53 [Zakim]: I don't understand 'dial out room_riviera_a', dom
11:37:00 [dom]: zakim, call room_riviera_a
11:37:00 [Zakim]: I am sorry, dom; I do not know a number for room_riviera_a
11:37:57 [DKA]: Topic: BP2
11:38:52 [francois]: RRSAgent, draft minutes
11:38:52 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html francois
11:39:02 [rob]: ScribeNick: rob
11:40:19 [DKA]: Topic: CT (Continued)
11:40:24 [dom]: zakim, call room_riviera-a
11:40:24 [Zakim]: I am sorry, dom; I do not know a number for room_riviera-a
11:41:32 [jeffs]: jeffs has joined #bpwg
11:43:48 [dom]: Observers+ Kangchan, DavidThevenin
11:43:55 [rob]: Topic: LC-2081
11:44:19 [Kangchan]: Kangchan has joined #bpwg
11:44:26 [rob]: francois: text is not clear enough
11:46:07 [DKA]: Jo: "If your content isn't consistent with the header that you're sending then you shouldn't send it"
11:46:11 [SeanP]: q+
11:47:08 [DKA]: ack seanp
11:47:35 [rob]: seanP: it's only informative
11:48:13 [rob]: dom: we agreed to remove normative burdens on origin servers
11:48:42 [rob]: DKA: so do we need this at all?
11:49:06 [aconnors]: aconnors has joined #bpwg
11:49:29 [rob]: jeffs: but if I need to ask someone what this means then it's not useful
11:50:54 [Kangchan]: rrsagent, make minutes
11:50:54 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html Kangchan
11:51:19 [rob]: dka: what's the other comment on this section?
11:51:59 [rob]: francois: LC-2008 is already resolved
11:52:43 [rob]: ... and that's not the problem here with LC-2081
11:54:21 [rob]: dka: as part of this informationizationing is the proposal to remove the second para of 4.2.3.1?
11:54:42 [rob]: jo: no
11:55:16 [rob]: ... say "don't misrepresent your content"
11:55:47 [jo]: PROPOSED RESOLUTION: Change second second para of 4.2.3.1 to say "don't misrepresent your content, even if you think that will avoid it being transformed"
11:57:00 [jo]: PROPOSED RESOLUTION: Change second second para of 4.2.3.1 to say "don't systematically misrepresent your content, even if you think that will avoid it being transformed"
11:57:08 [SeanP]: +1
11:57:11 [rob]: +1
11:57:11 [jeffs]: +1
11:58:16 [francois]: +1
11:58:23 [rob]: RESOLUTION: Change second second para of 4.2.3.1 to say "don't systematically misrepresent your content, even if you think that will avoid it being transformed"
11:58:45 [dom]: re TAG response to our request for comments, http://www.w3.org/2001/tag/2008/10/09-minutes#item03 " Norm was to review this and see if it was something we needed to take a look at. [...] Dan moved it to be due next week, I'll endeavor to review it before then"
11:59:16 [DKA]: q?
11:59:44 [rob]: francois: we should postpone this discussion until we get a response from TAG
11:59:50 [dom]: [this also was on the agenda for Oct 16, but haven't found the minutes of that meeting http://lists.w3.org/Archives/Public/www-tag/2008Oct/0088.html ]
12:00:21 [rob]: ... what is clear is that the current text is based on an incorrect assertion
12:01:08 [dom]: http://www.w3.org/2008/10/16-tagmem-minutes.html doesn't have any mention of CT guidelines afaict
12:01:51 [dom]: [and no update on http://www.w3.org/2001/tag/group/track/actions/173 , TAG's relation action item ]
12:01:58 [rob]: ... and the text will need to change when we have TAG's advice
12:02:46 [Kai]: Kai has joined #bpwg
12:03:41 [rob]: dom: Personally I don't think we should wait for TAG's response - we can close the issue now
12:04:13 [rob]: jo: let's go back to the LC-2010 in question
12:04:27 [jo]: i/francois: we should/Topic: LC-2010
12:05:26 [DKA]: PROPOSED RESOLUTION: LC-2010 is void and thereby will be ignored.
12:06:08 [seungyun]: seungyun has joined #bpwg
12:06:11 [DKA]: PROPOSED RESOLUTION: LC-2010 is a reasonable comment but is now overtaken by events.
12:06:48 [DKA]: PROPOSED RESOLUTION: LC-2010 is a reasonable comment but is now overtaken by events - namely that we don't propose to use fragment identifiers as a method to achieve this anymore. yada yada
12:07:01 [francois]: +1
12:07:10 [rob]: +1
12:07:15 [SeanP]: +1
12:07:23 [jeffs]: +1 (esp the yadayada part)
12:07:30 [rob]: RESOLUTION: LC-2010 is a reasonable comment but is now overtaken by events - namely that we don't propose to use fragment identifiers as a method to achieve this anymore.
12:07:54 [rob]: Topic: LC-2011
12:09:23 [rob]: jo: this is saying "if you have a non-local reference you may or may not be referring to this instance"
12:11:37 [dom]: " When a URI reference refers to a URI that is, aside from its fragment component (if any), identical to the base URI (Section 5.1), that reference is called a "same-document" reference. The most frequent
12:11:37 [dom]: examples of same-document references are relative references that are empty or include only the number sign ("#") separator followed by a fragment identifier"
12:11:38 [rob]: francois: the RFC explains how to construct a local reference
12:11:50 [dom]: section 4.4, rfc 3986
12:12:31 [dom]: (available e.g. http://www.faqs.org/rfcs/rfc3986.html )
12:13:25 [steph]: steph has joined #bpwg
12:13:28 [rob]: francois: even if you have an absolute URI to the same document you can determine that it is in fact a local URI
12:13:36 [dom]: The base URI of a reference can be established in one of four ways, discussed below in order of precedence: Base URI Embedded in Content, Base URI from the Encapsulating Entity, Base URI from the Retrieval URI, Default Base URI
12:13:41 [dom]: 5.1 in RFC 3986
12:13:52 [jo]: http://tools.ietf.org/html/rfc3986#section-4.4
12:14:04 [NEWTON_VAGNER_DIN]: NEWTON_VAGNER_DIN has joined #bpwg
12:14:07 [dom]: http://tools.ietf.org/html/rfc3986#section-5.1.3
12:14:15 [jo]: http://tools.ietf.org/html/rfc3986#section-5.1
12:14:22 [dom]: " If no base URI is embedded and the representation is not encapsulated
12:14:22 [dom]: within some other entity, then, if a URI was used to retrieve the
12:14:22 [dom]: representation, that URI shall be considered the base URI. Note that
12:14:22 [dom]: if the retrieval was the result of a redirected request, the last URI
12:14:22 [dom]: used (i.e., the URI that resulted in the actual retrieval of the
12:14:23 [dom]: representation) is the base URI.
12:14:25 [dom]: "
12:14:32 [dom]: zakim, mute jo
12:14:32 [Zakim]: sorry, dom, I don't know what conference this is
12:15:38 [dom]: " Normalization of the base and target URIs prior to their comparison,
12:15:38 [dom]: as described in Sections 6.2.2 and 6.2.3, is allowed but rarely
12:15:38 [dom]: performed in practice. Normalization may increase the set of same-
12:15:38 [dom]: document references, which may be of benefit to some caching
12:15:38 [dom]: applications."
12:15:42 [dom]: in 4.4
12:16:55 [rob]: jo: we are trying to say "this doccument is formatted for a mobile"
12:18:47 [rob]: ... we are also saying that content is available for media screen at this URI as well
12:19:21 [rob]: ... and that's not possible to do with the link mechanism
12:23:09 [jo]: PROPOSED RESOLUTION: Ref LC-2011 in 4.2.3.2 (and elsewhere as suits clarity and editorial convenience) at para 3 and the following note. Make it clear that wehre more than one representation is available from the same URI this ought to be represented by using a Vary header and can't be represented using <link>. In other cases the link header should be used to reference alternative representations
12:23:11 [jo]: (i.e. where the Base URI, ref RFC 3986 secs 5.5 and 5.1 does not indicate a same document reference)
12:23:27 [jeffs]: s/wehre/where
12:23:59 [francois]: +1
12:24:01 [dom]: +1
12:24:51 [DKA]: +1 to the sentiment but I don't like using the word "ought"
12:25:08 [SeanP]: +1 (although I think it is complicated enough that it will be rarely used)
12:25:10 [rob]: s/with the link mechanism/with the <link rel="alternate"> mechanism/
12:25:11 [jeffs]: + and agree w DKA
12:25:16 [jo]: ought = Should (non normative, no relation to RFC 2119)
12:25:17 [Kai]: +1
12:25:20 [rob]: +1
12:25:38 [dom]: [latest link header in http draft, to make sure to derail the discussion http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt ]
12:26:33 [rob]: RESOLUTION: Ref LC-2011 in 4.2.3.2 (and elsewhere as suits clarity and editorial convenience) at para 3 and the following note. Make it clear that where more than one representation is available from the same URI this ought to be represented by using a Vary header and can't be represented using <link rel="alternate">. In other cases the link header should be used to reference alternative representations (i.e. where the Base URI, ref RFC 3986 secs 5.5
12:26:34 [rob]: and 5.1 does not indicate a same document reference)
12:26:44 [dom]: [Jo notes that it doesn't feature the equivalent of the "media" attribute in html]
12:27:15 [jo]: [jo note that the draft-nottingham etc. does not provide a machanism to represent the equivant of media attribute]
12:27:18 [dom]: s/secs 5.5/secs 5.5 and 5.1 does not indicate a same document reference)/
12:27:35 [jeffs]: s/does/do
12:28:37 [rob]: francois: and we won't mention fragment identifiers because it's not relevant
12:29:38 [francois]: PROPOSED RESOLUTION: re. LC-2009, resolve yes, acknowledge RFC3986 section 4.4 and remove the part on fragment identifiers
12:29:48 [DKA]: +1
12:29:50 [francois]: +1
12:29:51 [SeanP]: +1
12:29:53 [rob]: +1
12:30:08 [rob]: RESOLUTION: re. LC-2009, resolve yes, acknowledge RFC3986 section 4.4 and remove the part on fragment identifiers
12:30:39 [jeffs]: +11
12:30:50 [jeffs]: s/11/1
12:30:59 [jcantera]: jcantera has joined #bpwg
12:31:41 [dom]: zakim, move into speed resolutions mode
12:31:41 [Zakim]: I don't understand 'move into speed resolutions mode', dom
12:31:52 [dom]: zakim, draft resolutions for us
12:31:52 [Zakim]: I don't understand 'draft resolutions for us', dom
12:31:57 [DKA]: PROPOSED RESOLUTION: re. LC-2020, resolve no, we do not want to step
12:32:12 [rob]: Topic: LC-2020
12:32:13 [DKA]: PROPOSED RESOLUTION: re. LC-2020, resolve no, we do not want to step into legal maters.
12:32:39 [jeffs]: s/maters/matters
12:32:45 [DKA]: ScribeNick: SeanP
12:32:48 [DKA]: Scribe: Sean
12:33:31 [SeanP]: Francois: If the meta Copyright tag, then the page must not be reformatted.
12:33:52 [SeanP]: DKA: Do we need to consider this since you are recommending that we resolve no.
12:34:28 [rob]: +1
12:34:37 [SeanP]: DOM: I think the comment is bogus.
12:35:25 [SeanP]: Jo: We need to say the copyright of the material is not affected by the copyright meta tag.
12:35:46 [SeanP]: Jo: Point is valid, however.
12:36:37 [SeanP]: DKA: This stuff is up to the lawyers do decide.
12:36:41 [francois]: PROPOSED RESOLUTION: re. LC-2020, resolve no, the presence or absence of a Copyright is not a clear indication of the rights associated with the page
12:36:55 [SeanP]: +1
12:37:06 [DKA]: +1
12:37:09 [SeanP]: RESOLUTION: re. LC-2020, resolve no, the presence or absence of a Copyright is not a clear indication of the rights associated with the page
12:37:35 [jeffs]: +1
12:38:07 [SeanP]: Topic: LC-2082
12:38:29 [DKA]: PROPOSED RESOLUTION: re. LC-2082, LC-2042, resolve no, cascading proxies are not as easy as they seem, and the "MUST NOT" only applies to "CT" proxies, not proxies in general.
12:38:33 [SeanP]: Topic: LC-2082, LC-2042
12:39:47 [SeanP]: Francois: What we say in 4.3.2, we say if there is a Warning header, then proxies should not perform transformation. We decided that having 2 cascading CT proxies was out of scope.
12:40:14 [SeanP]: Dom: But 4.3.2 doesn't say it is out of scope.
12:40:24 [SeanP]: Francois: Right.
12:41:42 [SeanP]: Jo: The point of this section is to say that if the content goes thru a CT proxy then goes through another one, it can be a problem.
12:42:01 [SeanP]: Dom: Doesn't that rule out server side transformation.
12:42:17 [SeanP]: Jo: No. Since server-side transformation is out of scope.
12:42:44 [SeanP]: Francois: But we are saying is that multiple CT proxies are out of scope, but we are addressing it.
12:43:04 [SeanP]: Jo: No we are saying server side transformation is out of scope, not multiple CT proxies.
12:43:41 [SeanP]: Francois: We say earlier in the document that we don't discuss multiple CT proxies in detail.
12:44:11 [SeanP]: Francois: These guide lines only apply to CT proxies, not all proxies.
12:45:59 [SeanP]: DKA: A real example from Vodafone. There was content that was transformed by Yahoo, then transformed again by Novarra. This caused a problem since they had no knowledge of each other.
12:46:32 [SeanP]: Kai: But aren't we just legislating that people shouldn't make mistakes.
12:47:21 [SeanP]: Dom: If a CT proxy transforms to mobile friendly state, why couldn't another proxy transform it again.
12:47:56 [SeanP]: DKA: We're trying to get CPs to add logic to make their content to work well on mobile devices.
12:48:52 [SeanP]: Kai: By saying this you are making it difficult to perform a two step process.
12:49:19 [SeanP]: Jo: Why not leave out the Warning header if you want to do that.
12:49:49 [SeanP]: Dom: We are adding a meaning to the Warning header that is not in the original specification.
12:49:57 [DKA]: PROPOSED RESOLUTION: WRT LC-2082, LC2042: resolve_yes and remove 4.3.2
12:51:07 [jo]: PROPOSED RESOLUTION: WRT LC-2082, LC2042: resolve_yes and remove 4.3.2 replace with a section noting that intermediate proxies should send no-transform if they want to inhibit further transformation
12:51:40 [francois]: +1
12:51:46 [jeffs]: +1
12:51:48 [SeanP]: +1
12:51:50 [Kai]: +1
12:51:50 [DKA]: +1
12:51:54 [rob]: +1
12:52:00 [SeanP]: RESOLUTION: WRT LC-2082, LC2042: resolve_yes and remove 4.3.2 replace with a section noting that intermediate proxies should send no-transform if they want to inhibit further transformation
12:52:12 [SeanP]: Topic: LC-2083
12:53:17 [DKA]: PROPOSED RESOLUTION: re. LC-2083, resolve partial, we are addressing legacy content, there is no way to be more precise. Remove the part on "servers that do not implement this Recommendation".
12:53:21 [SeanP]: Francois: We should resolve "No" since we can't be more precise because we are dealing with legacy content.
12:53:55 [SeanP]: DKA: We should make it clear that this kind thing is what differentiates CT proxies.
12:56:26 [jo]: PROPOSED RESOLUTION: ref LC-2083, no, it is an important part of the mechanism described in 4.1.5 so has to be here in some form. We don't mean to propose this as a fail safe mechanism, we merely mean to indicate that CT proxies may need to employ heuristics to provide an improved service for their users. Remove reference to conforming servers.
12:56:43 [francois]: +1
12:56:47 [DKA]: +1
12:56:57 [jeffs]: +1
12:56:58 [SeanP]: +1
12:57:08 [SeanP]: RESOLUTION: ref LC-2083, no, it is an important part of the mechanism described in 4.1.5 so has to be here in some form. We don't mean to propose this as a fail safe mechanism, we merely mean to indicate that CT proxies may need to employ heuristics to provide an improved service for their users. Remove reference to conforming servers.
12:57:15 [DKA]: Topic: LC-2084
12:57:33 [DKA]: PROPOSED RESOLUTION: re. LC-2084, resolve partial, and add a link back to 4.1.5.2 that explains the use case.
12:58:20 [SeanP]: Francois: Use case is in 4.1.5.2 which is already there.
12:59:02 [DKA]: PROPOSED RESOLUTION: re. LC-2084, resolve no since ample reasoning is provided.
12:59:13 [DKA]: PROPOSED RESOLUTION: re. LC-2084, resolve no since ample reasoning is provided (link to 4.1.5.2 that explains the use case).
12:59:28 [SeanP]: +1
12:59:37 [SeanP]: Jo: This is a failsafe mechanism.
13:00:08 [SeanP]: Francois: What I had in mind is that the reference to 4.1.5.2 should be at the beginning of the sentence.
13:00:53 [VagnerBrazil]: VagnerBrazil has joined #bpwg
13:01:43 [jo]: PROPOSED RESOLUTION: re. LC-2084, resolve partial since this is part of the fail safe mechanism defined in 4.1.5.2 that explains the use case. Move reference to 4.1.5.2 earlier int he sentence and simplify wording
13:02:17 [DKA]: +1
13:02:23 [DKA]: -1
13:02:23 [francois]: +1
13:02:39 [DKA]: �1
13:02:40 [jo]: PROPOSED RESOLUTION: re. LC-2084, resolve partial since this is part of the fail safe mechanism defined in 4.1.5.2 that explains the use case. Move reference to 4.1.5.2 earlier int he sentence and simplify wording, add reference to example kindly to be re-provided by Francois
13:02:51 [francois]: +1
13:02:56 [DKA]: +1
13:02:56 [rob]: +1
13:03:04 [dom]: +1
13:03:06 [jeffs]: +1
13:03:13 [SeanP]: RESOLUTION: re. LC-2084, resolve partial since this is part of the fail safe mechanism defined in 4.1.5.2 that explains the use case. Move reference to 4.1.5.2 earlier int he sentence and simplify wording, add reference to example kindly to be re-provided by Francois
13:03:58 [SeanP]: Topic: Many LC's on 4.3.6
13:04:20 [SeanP]: Francois: Most CP's misread this section.
13:05:34 [SeanP]: Francois: Most of the comments are to be comprehensive on the heuristics, but we can't do that.
13:05:52 [SeanP]: Topic: LC-2090
13:07:06 [DKA]: PROPOSED RESOLUTION: re. LC-1998, resolve no since lots of non-mobile web pages actually send xhtml+xml mime type.
13:07:15 [SeanP]: Francois: This may be true for the time being, but we can't really do this.
13:07:22 [DKA]: Topic: LC-1998
13:07:24 [DKA]: PROPOSED RESOLUTION: re. LC-1998, resolve no since lots of non-mobile web pages actually send xhtml+xml mime type.
13:08:01 [DKA]: PROPOSED RESOLUTIONS: Remove the examples of mobile-specifc doctypes in 4.3.6 and remain silent on this issue...
13:08:19 [SeanP]: Jo: We didn't put in content types for good reasons. We probably should remove the lists of doc types.
13:08:42 [SeanP]: Francois: I think it is good to have some examples, but to just say they are examples.
13:09:03 [SeanP]: Dom: Having examples of heuristics makes it seem like we are endorsing them.
13:09:11 [SeanP]: Jo: This is kind of my point.
13:09:27 [SeanP]: DKA: I think some examples are good.
13:09:51 [SeanP]: Jeff: I would really object to removing examples.
13:10:21 [SeanP]: DKA: You are limiting the scope of the document if you are limiting to implementors of CT proxies.
13:11:12 [SeanP]: Jo: Our job is to be clear, not disoursive (?).
13:11:39 [SeanP]: Jeff: I think the audience should also be people developing the content, so the examples are useful.
13:12:17 [SeanP]: s/disoursive/discoursive/
13:12:54 [SeanP]: DKA: We need to be clear that these are examples. We are trying to be responsive to the community that made these comments.
13:13:39 [SeanP]: Dom: By increasing the number of examples, we don't really do any service.
13:13:47 [jo]: PROPOSED RESOLUTION: Remove examples of heuristics from the main run of text and include Appendices to list in a *non-endorsed* way lists of stuff that other people have used but are No-endorsed by us, and did I mentionthat they are not endorsed
13:13:49 [SeanP]: Francois: Why don't we move the examples to an appendix?
13:14:07 [jeffs]: +1
13:14:09 [rob]: +1
13:14:15 [SeanP]: +1
13:14:18 [SeanP]: RESOLUTION: Remove examples of heuristics from the main run of text and include Appendices to list in a *non-endorsed* way lists of stuff that other people have used but are No-endorsed by us, and did I mentionthat they are not endorsed
13:14:33 [DKA]: +1 with the addition of some of the additional doctypes listed by the feedback...
13:14:39 [jeffs]: +1
13:14:43 [DKA]: (at editor's discression)
13:14:59 [SeanP]: Topic: LC-1998
13:15:27 [DKA]: PROPOSED RESOLUTION: re. LC-1998, resolve no since lots of non-mobile web pages actually send xhtml+xml mime type.
13:16:48 [jo]: PROPOSED RESOLUTION: re. LC-1998, resolve no and point out to commenter that this assumption is unsafe without other supporting evidence.
13:17:01 [SeanP]: +1
13:17:02 [francois]: +1
13:17:05 [rob]: +1
13:17:07 [SeanP]: RESOLUTION: re. LC-1998, resolve no and point out to commenter that this assumption is unsafe without other supporting evidence.
13:17:19 [jeffs]: +1
13:17:29 [SeanP]: Topic: LC-1999
13:18:19 [dom]: "increase your page size!"
13:18:35 [jo]: PROPOSED RESOLUTION: Resolve comenter and point out to commenter that size on its own is unsafe as an idicator of mobile friendlines e.gf. content with emdedded flash
13:18:44 [dom]: s/idi/indi/
13:18:53 [dom]: s/gf/g/
13:19:07 [SeanP]: +1
13:19:08 [francois]: +1
13:19:11 [rob]: +1
13:19:15 [SeanP]: RESOLUTION: Resolve comenter and point out to commenter that size on its own is unsafe as an idicator of mobile friendlines e.gf. content with emdedded flash
13:19:18 [jeffs]: +1 s/comenter/commenter
13:19:24 [jo]: PROPOSED RESOLUTION: Ref LC-1999 Resolve no commenter and point out to commenter that size on its own is unsafe as an indicator of mobile friendlines e.g content with embedded flash
13:19:33 [DKA]: +1
13:19:39 [dom]: s/<SeanP>/<SeanP> PROPOSED/
13:19:50 [SeanP]: RESOLUTION: Ref LC-1999 Resolve no commenter and point out to commenter that size on its own is unsafe as an indicator of mobile friendlines e.g content with embedded flash
13:20:05 [SeanP]: Topic: LC-2048
13:20:47 [dom]: RRSAgent, draft minutes
13:20:47 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html dom
13:21:36 [jo]: PROPOSED RESOLUTION: Ref LC-2048 and LC-2002, LC-2052 and LC-2021, resolve partial, and say that we include these examples as non-endorsed heuristics in the non endorsed heuristics appendi
13:21:39 [DKA]: +1
13:21:43 [francois]: +1
13:21:48 [SeanP]: +1
13:21:54 [SeanP]: RESOLUTION: Ref LC-2048 and LC-2002, LC-2052 and LC-2021, resolve partial, and say that we include these examples as non-endorsed heuristics in the non endorsed heuristics appendix
13:21:59 [jeffs]: +1
13:22:53 [SeanP]: Topic: LC-2022
13:23:54 [SeanP]: Francois: Put this one separate in case we missed something. I don't think we did.
13:24:15 [jo]: PROPOSED RESOLUTION: Ref LC-2022 resolve partial, we agree that this was not included and have added it as a non-endorsed heuristic in the relevant appendix
13:24:27 [SeanP]: +1
13:24:31 [francois]: +1
13:24:36 [DKA]: +1
13:24:44 [SeanP]: RESOLUTION: Ref LC-2022 resolve partial, we agree that this was not included and have added it as a non-endorsed heuristic in the relevant appendix
13:24:50 [jo]: x-zillon/tharg
13:26:02 [SeanP]: Topic: LC-2090, LC-2000
13:26:28 [SeanP]: Francois: I think this is out of scope. It's a legal matter
13:27:20 [jo]: PROPOSED RESOLUTION: Ref LC-2090 and LC-2000, resolve no, other than to note that adding extra content is forbidden where no-transform is present
13:27:34 [SeanP]: +1
13:27:37 [rob]: +1
13:28:09 [jeffs]: +1
13:28:17 [dom]: Present+ RigoWenning
13:30:22 [SeanP]: Rigo: There should be a way to keep CT proxies from transforming.
13:31:02 [SeanP]: Francois: There is another point in the comment where the CT proxy could add an add.
13:31:09 [SeanP]: s/add/ad/
13:32:28 [SeanP]: Jo: If I put a copyright notice on my content, but no no-transform, the commenters will say we are not doing our job. Should just copyright notice be necessary?
13:33:16 [SeanP]: Rigo: No. Copyright notice is American disease. Even in U.S. copyright notice is not necessary anymore.
13:34:02 [SeanP]: ...Even if you assert your copyright and put your content on the web, it is implicit statement that you want people to read my stuff. This means you need to live with what is socially adequate in the medium.
13:34:55 [SeanP]: ...The copyright holder needs to indicate that the he/she wants to opt out of this kind of thing.
13:35:26 [SeanP]: Rigo: <Introduces self>
13:35:28 [jo]: PROPOSED RESOLUTION: Ref LC-2090 and LC-2000, resolve no, other than to note that adding extra content is forbidden where no-transform is present and content providers should use this if they want to be sure their content is not added to
13:35:57 [francois]: +1
13:36:00 [rob]: +1
13:36:02 [DKA]: +1
13:36:07 [SeanP]: +1
13:36:11 [Kai]: +1
13:36:13 [jo]: rrsagent, draft minutes
13:36:13 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html jo
13:36:14 [jeffs]: +1
13:36:21 [VagnerBrazil]: VagnerBrazil has joined #bpwg
13:36:40 [VagnerBrazil]: VagnerBrazil has joined #bpwg
13:36:56 [SeanP]: RESOLUTION: Ref LC-2090 and LC-2000, resolve no, other than to note that adding extra content is forbidden where no-transform is present and content providers should use this if they want to be sure their content is not added to
13:37:09 [jeffs]: +1
13:37:22 [jo]: [break]
13:53:49 [DKA]: q?
14:00:39 [francois]: Scribe: jeffs
14:00:43 [francois]: ScribeNick: jeffs
14:01:11 [DKA]: DKA has joined #bpwg
14:01:43 [SeanP]: SeanP has joined #bpwg
14:02:23 [DKA]: q?
14:02:33 [DKA]: ScribeNick: jeffs
14:02:36 [abel]: abel has joined #bpwg
14:02:37 [DKA]: Scribe: Jeff
14:02:38 [rob]: rob has joined #bpwg
14:03:05 [jeffs]: next last-call comment: 2013
14:03:56 [francois]: PROPOSED RESOLUTION: re. LC-2013, resolve yes, and clarify that we mean
14:03:56 [francois]: "in the absence of a Vary HTTP header and in the absence of a
14:03:56 [francois]: no-transform directive defined at the HTTP level or using a meta
14:03:56 [francois]: http-equiv element containing Cache-Control: no-transform"
14:04:32 [jeffs]: re: meta http-equiv - 4.3.6 Proxy Decision to Transform
14:05:25 [Kai]: Kai has joined #bpwg
14:05:37 [jeffs]: francois: this applies to 4.3.1
14:06:31 [jeffs]: francois: servers may not take account of content-transformation headers
14:07:17 [jeffs]: francois: headers might have precedent
14:07:28 [jeffs]: s/francois/dom
14:08:00 [jo]: jo has joined #bpwg
14:08:13 [jeffs]: is the only reason we do this is for legacy converters? no, servers may not have access to content-transformation
14:08:24 [DKA]: q?
14:09:09 [jo]: PROPOSED RESOLUTION: Ref LC-2013 clarify in 4.3.1 and 4.3.6 and in other relevant sections that meta http-equiv should be consulted if the relevant actual HTTP header is not present
14:09:19 [jeffs]: dom: the only dependable indicator is cache-n-transform directory
14:09:36 [jeffs]: francois: move it to 4.3.1??
14:09:39 [jo]: PROPOSED RESOLUTION: Ref LC-2013, resolve yes, clarify in 4.3.1 and 4.3.6 and in other relevant sections that meta http-equiv should be consulted if the relevant actual HTTP header is not present
14:10:40 [francois]: +1
14:10:43 [dom]: +1
14:10:45 [jeffs]: +1
14:10:49 [DKA]: +1
14:10:57 [jeffs]: RESOLUTION: Ref LC-2013, resolve yes, clarify in 4.3.1 and 4.3.6 and in other relevant sections that meta http-equiv should be consulted if the relevant actual HTTP header is not present
14:11:00 [SeanP]: +1
14:11:03 [jeffs]: +1
14:11:22 [DKA]: Topic: LC-2051
14:11:58 [jeffs]: Topic: LC-2051 - Open Mobile Alliance Standard Transcoding Interface work - Appendix A and D
14:12:10 [dom]: http://www.openmobilealliance.org/technical/release_program/sti_v10.aspx
14:12:26 [dom]: -> http://www.openmobilealliance.org/technical/release_program/sti_v10.aspx Standard Transcoding Interface
14:13:24 [jeffs]: dka: let us not put dependencies behind this, so we can finalize the document
14:13:40 [jeffs]: francois: will review the document and propose edits
14:14:21 [dom]: http://www.openmobilealliance.org/technical/release_program/docs/CopyrightClick.aspx?pck=STI&file=V1_0-20050607-C/OMA-ERELD-STI-V1_0-20050607-C.pdf
14:14:44 [francois]: ACTION: LC-2051, daoust to review OMA STI to see if there's something relevant for CT
14:14:44 [trackbot]: Sorry, couldn't find user - LC-2051,
14:14:53 [DKA]: Topic: LC-1995
14:14:56 [francois]: ACTION: daoust to review OMA STI to see if there's something relevant for CT for LC-2051
14:14:57 [trackbot]: Created ACTION-868 - Review OMA STI to see if there's something relevant for CT for LC-2051 [on François Daoust - due 2008-10-27].
14:15:22 [VagnerBrazil]: VagnerBrazil has joined #bpwg
14:15:26 [DKA]: PROPOSED RESOLUTION: re. LC-1995, resolve yes, and replace "recent draft of HTTP" by "HTTP 1/1"
14:15:27 [jeffs]: LC-1995 - About "recent" HTTP "drafts" - Appendix D.2
14:15:53 [dom]: [should we link to mark nottingham's draft?]
14:15:54 [DKA]: PROPOSED RESOLUTION: re. LC-1995, resolve yes, and replace "recent draft of HTTP" by "HTTP /1.1"
14:16:00 [DKA]: PROPOSED RESOLUTION: re. LC-1995, resolve yes, and replace "recent draft of HTTP" by "HTTP/1.1"
14:16:05 [SeanP]: +1
14:16:12 [jeffs]: +1
14:16:13 [DKA]: +1
14:16:20 [DKA]: Topic: LC-2047
14:16:27 [jeffs]: Topic: LC-2047 - Cascading proxies - Appendix D.4 Inter Proxy Communication
14:16:49 [DKA]: PROPOSED RESOLUTION: re. LC-2047, resolve no, and point out a specific example of why it's not that simple to the commenter
14:16:53 [jeffs]: francois: long comment about how to resolve cascading proxies case
14:17:28 [jeffs]: francois: resolution is not easy in practice
14:18:33 [jeffs]: francois: with cascading proxies, cannot ontrol the chain
14:18:39 [jeffs]: s/ontrol/control
14:18:59 [jeffs]: jo: key point: let us define our terms
14:19:21 [jeffs]: jon: I interpret "upstream" & "downstream" differently than common parlance
14:19:28 [jeffs]: s/jon/jo
14:19:59 [jeffs]: dka: think of the stream as between the server and the client... therefore upstream points to server and downstream points to client
14:20:08 [jeffs]: jo: salmon metaphor
14:20:38 [jeffs]: francois: the upstream proxy cannot transform when there is a downstream proxy
14:20:44 [jeffs]: jo: that is not what we do
14:21:05 [jeffs]: jo: we do not regard downstream proxies as user agents in their own right
14:21:45 [jeffs]: jo: comment is pointing out the combination of proxies makes a non-user-agent
14:22:00 [jeffs]: jo: therefore must be passed on without transformation
14:22:13 [jeffs]: dom & francois: the results are the same
14:22:39 [jeffs]: dom: saying "do as if downstream proxy is not a user agent"
14:23:38 [jeffs]: francois: there is no reason to say the downsteam proxy has precedence over the upstream one
14:23:54 [jeffs]: dka: the upstream proxy knows more about the content
14:24:29 [jeffs]: francois: the first part is saying we cannot choose which has precedence
14:24:47 [jeffs]: francois: the point is about the appendix
14:24:57 [jeffs]: jo: not only about the appendix
14:25:23 [dom]: PROPOSED RESOLUTION: Hi Shadi
14:25:29 [jeffs]: +1
14:25:30 [dom]: Observer+ Shadi
14:26:08 [jeffs]: discussion: is the proxy part of the server or not?
14:26:25 [jeffs]: jo: at whiteboard & drawing things
14:27:21 [francois_]: francois_ has joined #bpwg
14:27:46 [jeffs]: jo: whatever comes out of the content provider's proxy may or may not remain the same as it moves through intermediate proxies
14:28:34 [francois]: RRSAgent, draft minutes
14:28:34 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html francois
14:29:00 [jeffs]: dom & jo: interchange over sould be used vs could be used
14:29:37 [jeffs]: jo: can of worms: the transformers in the middle
14:30:41 [jeffs]: dom: we should say this is not as simple as it looks and we are looking for a way to state the problem & solution simply
14:30:53 [DKA]: PROPOSED RESOLUTION: re. LC-2047, resolve no, and point out a specific example of why it's not that simple to the commenter
14:31:51 [jeffs]: jo: add proxies should not add cache-control header
14:31:56 [DKA]: PROPOSED RESOLUTION: re. LC-2047, resolve partial, and point out a specific example of why it's not that simple to the commenter and add CT proxies should not add no-transform directive on upstream request.
14:32:29 [jeffs]: jo: when it passes through the network, you should not add cache-control header
14:33:09 [jeffs]: jo: if anybody is doing transformation, it should be the one closest to the owner of what is being requested
14:34:17 [jeffs]: jo & francois: discussion of what we have said in past
14:35:44 [dom]: LC-2047.a
14:39:21 [jeffs]: discussion: inter-relationships between the 3 parts of the comment/proposal
14:40:39 [jeffs]: rob: almost impossible to tell who has done what in chain of proxies along path from client (requester) to server (responder)
14:40:42 [jo]: PROPOSED RESOLUTION: ref LC-2047 part a. No. We do not view the CT proxy as being a user agent in its own right, it is a proxy like any other. Knowing that it is upstream of other proxies doesn't alter it's prescibed behaviour according to this document
14:41:38 [jeffs]: jo: if you are a conforming proxy and receive a request, what should you do?
14:42:51 [jeffs]: jo & dom: discussion of whether altered headers result or not
14:44:17 [DKA]: PROPOSED RESOLUTION: re. LC-2047, resolve partial, and point out a specific example of why it's not that simple to the commenter.
14:44:18 [jeffs]: dka: should we include this recommendation? jo: already prohibited
14:45:47 [jeffs]: jo: do we want to say not to change the value of the warning itself?
14:47:11 [jo]: PROPOSED RESOLUTION: ref LC-2047 part a. No. We do not view the CT proxy as being a user agent in its own right, it is a proxy like any other. Knowing that it is upstream of other proxies doesn't alter it's prescibed behaviour according to this document b. we think that this is defined in HTTP and don't need to elaborate on it unless there are specific examples of misoperation that we can...
14:47:13 [jo]: ...refer to and c) we disagree and think that this is very complex and requires a substantial use case analysis to achieve a complete understanding of this, and we also think that a more complex HTTP vocabulary is required to achieve useful results.
14:47:14 [jeffs]: dka: concern that a lot of thought went into these comments & we may not be addressing them thoroughly
14:48:54 [jo]: PROPOSED RESOLUTION: ref LC-2047 part a. No. We do not view the CT proxy as being a user agent in its own right, it is a proxy like any other. Knowing that it is upstream of other proxies doesn't alter it's prescibed behaviour according to this document
14:49:30 [jeffs]: +1
14:49:31 [jo]: PROPOSED RESOLUTION: ref LC-2047 part b. we think that this is defined in HTTP and don't need to elaborate on it unless there are specific examples of misoperation that we can refer to
14:50:12 [jeffs]: discussion: simplify to say content transformers must be transparent??
14:51:00 [jeffs]: discussion: concern over variability of possible cases
14:51:02 [jo]: PROPOSED RESOLUTION: ref LC-2047 part c. we disagree and think that this is very complex and requires a substantial use case analysis to achieve a complete understanding. We think that a more complex HTTP vocabulary for inter proxy operation is likely to be required to achieve useful results, and we are not chartered to create technology of that kind
14:51:29 [jo]: PROPOSED RESOLUTION: Add a section with a diagram explaining which proxies are in scope
14:52:50 [jeffs]: discussion: are there cases where proxy server closest to the client should hold forth??
14:53:10 [DKA]: +1 to Jo's proposed resolution triptych
14:53:36 [dom]: isn't it a tetratych?
14:53:55 [dom]: s/tra/trap/ actually
14:53:56 [jeffs]: rob: what happens when https on closest to client but not on one closest to destination server
14:54:09 [rob]: +1
14:54:25 [DKA]: +1 to the tetratych then
14:55:37 [francois]: +1 to the tetratych
14:55:50 [jeffs]: +1 to the tetratych
14:56:05 [SeanP]: +1 to all of them
14:56:18 [francois]: +1 to cheesetyche
14:56:19 [dom]: s/tetrat/tetrap/g
14:56:35 [dom]: s/tetrapy/tetrapty/g
14:57:04 [jo]: Scribe: Jo
14:57:18 [dom]: http://www.w3.org/Consortium/Legal/2008/04-mobileok-policy.html
14:57:21 [jo]: PROPOSED RESOLUTION: ref LC-2047 part a. No. We do not view the CT proxy as being a user agent in its own right, it is a proxy like any other. Knowing that it is upstream of other proxies doesn't alter it's prescibed behaviour according to this document
14:57:31 [jo]: RESOLUTION: ref LC-2047 part a. No. We do not view the CT proxy as being a user agent in its own right, it is a proxy like any other. Knowing that it is upstream of other proxies doesn't alter it's prescibed behaviour according to this document
14:57:41 [jo]: RESOLUTION: ref LC-2047 part b. we think that this is defined in HTTP and don't need to elaborate on it unless there are specific examples of misoperation that we can refer to
14:57:53 [jo]: RESOLUTION: ref LC-2047 part c. we disagree and think that this is very complex and requires a substantial use case analysis to achieve a complete understanding. We think that a more complex HTTP vocabulary for inter proxy operation is likely to be required to achieve useful results, and we are not chartered to create technology of that kind
14:58:00 [jo]: RESOLUTION: Add a section with a diagram explaining which proxies are in scope
14:58:23 [dom]: RRSAgent, draft minutes
14:58:23 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html dom
14:58:33 [jo]: Scribe: Jeffs
14:58:44 [francois]: ScribeNick: jeffs
14:58:56 [jeffs]: presentation of MobileOK logo and policy
14:59:03 [francois]: Topic: W3C mobileOK Logo and policy
14:59:33 [jeffs]: 2.2 conditions for conformance: 2 criteria
14:59:42 [jeffs]: Topic: W3C mobileOK Logo and policy
15:02:12 [dom]: -> http://www.w3.org/Consortium/Legal/2008/04-mobileok-policy.html mobileOK policy
15:02:28 [jeffs]: conditions to use these, all tests applicable to Basic Tests 1.0 accomplished w a PASS or a WARN & reasonable efforts undertaken to comply w the conditions in the conformance seciton and not covered by any test
15:03:12 [jeffs]: s/seciton/section
15:03:43 [jeffs]: so who certifies someone has met the criteria?
15:03:54 [dom]: -> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/081018 conformance section of latest draft of mobileOK
15:04:31 [jeffs]: must enforce the conditions set or trademark protections are lost
15:05:10 [dom]: (this relates to ISSUE-250)
15:05:30 [dom]: and ACTION-799
15:05:33 [jeffs]: businesses may emerge which certify meeting these conditions, like the ISO approach
15:05:34 [dom]: ACTION-799?
15:05:34 [trackbot]: ACTION-799 -- Dominique Hazaël-Massieux to get back to rigo on updating the mobileOK license -- due 2008-07-24 -- OPEN
15:05:34 [trackbot]: http://www.w3.org/2005/MWI/BPWG/Group/track/actions/799
15:06:51 [jeffs]: dom to rigo: in case of MobileOK 1.0 all tests are machine-testable
15:07:31 [jeffs]: rigo: suggests putting 2nd bullet point (reasonable efforts undertaken to comply w the conditions in the conformance seciton and not covered by any test) into our documents
15:08:08 [DKA]: ack jo
15:08:49 [jeffs]: jo: what is meant by "conditions in the conformance section and not covered by any test"
15:09:21 [jeffs]: dom: mobileOK basic is only about machine-testable issues
15:10:11 [jeffs]: rigo: suggestion for today is throw out 2nd bullet point & just say must pass machine-run auto-testing
15:10:12 [DKA]: q+ to raise the issue of "aspirational mobileOK"
15:10:57 [jeffs]: rigo: the simpler the rule, the easier to handle
15:12:12 [jeffs]: rigo: could get more granular on "applicable to the resource" by including a URI
15:12:37 [jeffs]: jo: URI is included in document
15:12:44 [jeffs]: rigo: then I am clear
15:14:12 [jeffs]: jo: role of the checker need to be looked at in the light of this
15:14:46 [dom]: q+ shadi
15:15:06 [jeffs]: rigo: checker is just a tool to claim passed & thus mobileOK
15:15:37 [jeffs]: jo: is the wording about "against a single resource" okay
15:16:01 [jeffs]: rigo: change to the URI rather than the resources behind the URI
15:17:29 [jeffs]: dom: the object of conformance is a discussion topic
15:17:56 [steph]: steph has joined #bpwg
15:18:12 [jeffs]: rigo: must be taken in context
15:19:00 [jeffs]: dom: claims of conformance may be made by a resource identified by a URI
15:19:42 [jeffs]: rigo: if we say "a single URI that passes" everyone can understand
15:20:32 [jo]: "Specifically, a claim of mobileOK may only be made of a URI that when dereferenced in the manner described in [mobileOK] yields a response that passes all the tests contained in mobileOK Basic Tests."
15:20:50 [DKA]: q?
15:21:16 [jeffs]: rigo: should we just say an object behind a URI can claim conformance?
15:22:20 [jeffs]: rigo will rewrite jo's sentence, likes it
15:22:44 [jo]: should read "Specifically, a claim of mobileOK *conformance* may only be made of a URI that when dereferenced in the manner described in [mobileOK] yields a response that passes all the tests contained in mobileOK Basic Tests."
15:23:23 [jeffs]: dom: various earlier questions addressed by this approach
15:25:03 [jeffs]: rigo: shape primary in establishing recognition value re logo, color etc changes not as critical
15:25:18 [jo]: q+ to ask if the license should specify that the logo should not come from w3C servers
15:25:57 [DKA]: ack jo
15:25:57 [Zakim]: jo, you wanted to ask if the license should specify that the logo should not come from w3C servers
15:27:07 [jeffs]: jo: logo is not in and of itself a conformance claim, needs to include something machine-readable like headers to establish claim? is rigo saying logo itself indicates claim is present?
15:29:36 [jeffs]: rigo: there are sufficient use cases that this version of the terms & conditions does not preclude us also creating a machine-run protocol to automatically include as meeting terms&conditions
15:30:19 [Kai]: q+ to ask if it is not a risk to focus on the logo in the policy, as it will steer users to only use the visual representation?
15:30:57 [dom]: ISSUE-250?
15:30:57 [trackbot]: ISSUE-250 -- The mobileOK License -- OPEN
15:30:57 [trackbot]: http://www.w3.org/2005/MWI/BPWG/Group/track/issues/250
15:31:38 [dom]: ACTION: Jo to review the mobileOK license in more details and send further questions to rigo
15:31:41 [trackbot]: Created ACTION-869 - Review the mobileOK license in more details and send further questions to rigo [on Jo Rabin - due 2008-10-27].
15:31:57 [DKA]: PROPOSED RESOLUTION: We live Rigo!
15:32:00 [dom]: I'm proposing to close ACTION-799
15:32:01 [jeffs]: jo: need to look this over and think about it in more detail before we move beyond a resolution to think about it
15:32:13 [DKA]: PROPOSED RESOLUTION: We love Rigo!
15:32:17 [jeffs]: RESOLUTION: we love Rigo!
15:32:26 [dom]: close ACTION-799
15:32:26 [trackbot]: ACTION-799 Get back to rigo on updating the mobileOK license closed
15:32:55 [dom]: ACTION-869?
15:32:56 [trackbot]: ACTION-869 -- Jo Rabin to review the mobileOK license in more details and send further questions to rigo -- due 2008-10-27 -- OPEN
15:32:56 [trackbot]: http://www.w3.org/2005/MWI/BPWG/Group/track/actions/869
15:33:04 [DKA]: q?
15:33:08 [DKA]: q-
15:33:33 [jeffs]: jo: wants to close on the subject by (as editor of the MobileOK document) by forming sub-committee w Dom & Rigo to discuss and work on this
15:33:35 [dom]: q+ shadi later
15:33:40 [dom]: q- shadi later
15:33:44 [dom]: q+ shadi
15:33:54 [DKA]: PROPOSED RESOLUTION: Dom, Jo and Rigo to form a subcommittee to come back with a final proposal to the group following on from Rigo's current proposal.
15:34:28 [jeffs]: RESOLUTION: Dom, Jo and Rigo to form a subcommittee to come back with a final proposal to the group within 4 weeks following on from Rigo's current proposal.
15:34:43 [DKA]: q?
15:34:46 [DKA]: ack kai
15:34:46 [Zakim]: Kai, you wanted to ask if it is not a risk to focus on the logo in the policy, as it will steer users to only use the visual representation?
15:34:54 [jeffs]: Kai: focus on logo may make machine-testing "fall by the wayside"
15:35:37 [jeffs]: s/testing/readable
15:36:09 [dom]: ack shadi
15:36:43 [jeffs]: shadi: wants to clarify that WCAG conformance is not about machine vs human testing
15:37:05 [jeffs]: shadi: do not be worried about having manual tests for MobileOK in future
15:37:23 [jeffs]: shadi: many models of conformance which can be explored
15:38:08 [jeffs]: shadi: ensure there are objectively testable criteria to avoid different reviewers coming up with different results
15:38:31 [francois]: RRSAgent, draft minutes
15:38:31 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html francois
15:38:33 [DKA]: Resolution of Boo-yeah!
15:38:58 [francois]: RRSAgent, draft minutes
15:38:58 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html francois
15:39:01 [jo]: Topic: Dinner
15:39:11 [dom]: Les Bartavelles
15:39:20 [dom]: pl Château
15:39:20 [dom]: 06210 Mandelieu la Napoule
15:39:22 [jo]: Restaurant is called les bartavelles
15:39:24 [dom]: Phone: +33 4 93 49 95 15
15:40:12 [francois]: [Meeting adjourned]
15:40:16 [francois]: RRSAgent, draft minutes
15:40:16 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/10/20-bpwg-minutes.html francois
15:40:38 [abel]: abel has left #bpwg
15:45:15 [dom]: RRSAgent, bye
15:45:15 [RRSAgent]: I see 6 open action items saved in http://www.w3.org/2008/10/20-bpwg-actions.rdf :
15:45:15 [RRSAgent]: ACTION: Jo to word smith resolution on LC-2069 in line with its spirit and come up with something a bit cleaner andmore comprehensible [1]
15:45:15 [RRSAgent]: recorded in http://www.w3.org/2008/10/20-bpwg-irc#T08-49-03
15:45:15 [RRSAgent]: ACTION: Jo to include text referencing resolution to LC-2003 [2]
15:45:15 [RRSAgent]: recorded in http://www.w3.org/2008/10/20-bpwg-irc#T08-57-49
15:45:15 [RRSAgent]: ACTION: daoust to look into an appendix with relevant normative statements of RFC2616 and report back to the group. [3]
15:45:15 [RRSAgent]: recorded in http://www.w3.org/2008/10/20-bpwg-irc#T10-35-58
15:45:15 [RRSAgent]: ACTION: LC-2051, daoust to review OMA STI to see if there's something relevant for CT [4]
15:45:15 [RRSAgent]: recorded in http://www.w3.org/2008/10/20-bpwg-irc#T14-14-44
15:45:15 [RRSAgent]: ACTION: daoust to review OMA STI to see if there's something relevant for CT for LC-2051 [5]
15:45:15 [RRSAgent]: recorded in http://www.w3.org/2008/10/20-bpwg-irc#T14-14-56
15:45:15 [RRSAgent]: ACTION: Jo to review the mobileOK license in more details and send further questions to rigo [6]
15:45:15 [RRSAgent]: recorded in http://www.w3.org/2008/10/20-bpwg-irc#T15-31-38
15:45:18 [dom]: Zakim, bye
15:45:18 [Zakim]: Zakim has left #bpwg