IRC log of bpwg on 2008-06-16

Timestamps are in UTC.

06:53:12 [RRSAgent]
RRSAgent has joined #bpwg
06:53:12 [RRSAgent]
logging to http://www.w3.org/2008/06/16-bpwg-irc
06:53:15 [Zakim]
Zakim has joined #bpwg
06:53:26 [dom]
trackbot, start meeting
06:53:29 [trackbot]
RRSAgent, make logs public
06:53:31 [trackbot]
Zakim, this will be BPWG
06:53:31 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
06:53:32 [trackbot]
Meeting: Mobile Web Best Practices Working Group Teleconference
06:53:32 [trackbot]
Date: 16 June 2008
06:54:19 [DKA1]
DKA1 has joined #bpwg
06:56:04 [abel]
abel has joined #bpwg
06:58:47 [dom]
Present: Abel, Manrique, Miguel, Ed, Jo, DKA, Kai, Dom, Francois, Rob, SeanP, Matt
06:58:59 [dom]
Chair: Dan, Jo
07:02:34 [matt]
Scribe: Matt
07:03:24 [dom]
Agenda: http://docs.google.com/View?docid=dd3jk8v_114tkbg6kgj
07:03:49 [achuter]
achuter has joined #bpwg
07:03:54 [rob]
rob has joined #bpwg
07:05:27 [matt]
Topic: Content Transformation Guidelines Document
07:07:55 [jo]
jo has joined #bpwg
07:08:20 [matt]
dom: Normative or informative -- it can be informative if you won't require people to conform to it. BP's are informative because people use them as a guide.
07:08:48 [matt]
dom: MobileOK is normative, because we want people to conform to it.
07:09:16 [matt]
dom: When BP was chartered it was decided that the CT work would be informative.
07:09:23 [matt]
dom: The charter was not about creating new technologies.
07:10:08 [Kai]
Kai has joined #bpwg
07:10:12 [matt]
dom: For normative docs the w3c patent policy applies, which means members with patents agree to give royalty free licenses... this does not apply to informative docs.
07:10:38 [manrique]
manrique has joined #bpwg
07:11:06 [matt]
dom: We can't make them normative for the time being. The question is the legal risk more expensive than rechartering the group to make it normative?
07:11:46 [matt]
DKA: What about amending the charter at extension time?
07:11:57 [matt]
dom: If we want to change from informative to normative, you need to recharter the group.
07:12:17 [Kai]
q+ to ask about a mismatch between the intention of the document and what a normative specification represents
07:12:27 [edm]
edm has joined #bpwg
07:12:31 [matt]
dom: We have to propose something to the w3m, the AC reviews the charter for four weeks, and then a 45 day grace period for rejoining the group.
07:12:35 [matt]
dom: It takes about a month or two.
07:12:54 [matt]
dom: Then republish as WD...
07:13:19 [matt]
dom: Then 150 days before published as PR.
07:13:42 [francois]
ack Kai
07:13:42 [Zakim]
Kai, you wanted to ask about a mismatch between the intention of the document and what a normative specification represents
07:13:53 [DKA1]
q?
07:14:14 [matt]
Kai: When you look at a specification, it's supposed to be something that is implemented, not a lot of room to interpret, etc. A guideline has a lot more wiggle room.
07:14:30 [matt]
Kai: How do we say they've fulfilled the specification?
07:14:34 [matt]
dom: My reading is that they're testable.
07:14:51 [matt]
dom: WCAG is testable for instance.
07:14:58 [matt]
DKA1: Yes, these should be testable, the work is specific enough.
07:15:04 [jo]
q+
07:15:04 [SeanP]
SeanP has joined #bpwg
07:15:27 [matt]
Kai: In the end you have to say "yes or no" to whether it's adhered to.
07:15:32 [matt]
q?
07:15:35 [matt]
ack jo
07:16:56 [matt]
<group pauses for station identification>
07:19:56 [matt]
jo: Propose continuing the group to end of charter with doc being normative. When the group recharters I suggest that we take the work continue in a normative fashion.
07:20:12 [dom]
s/being normative/being informative/
07:20:34 [matt]
jo: We don't lose much, only 6 months.
07:20:49 [matt]
dom: We can extend the group without having an AC review for up to a year...
07:20:52 [JonathanJ]
JonathanJ has joined #bpwg
07:21:01 [matt]
jo: The group probably should be rechartered if it's going to go beyond this year.
07:21:06 [DKA1]
PROPOSED RESOLUTION: The CT document should be taken to its conclusion under the current chartered (non-normative) and therefore the question of whether to change it to a normative document should be put off to the future re-chartering.
07:21:28 [Sunghan]
Sunghan has joined #bpwg
07:23:19 [matt]
jo: Can we change an informative rec into a normative rec?
07:23:58 [matt]
francois: Maybe we can make normative tests that reference the informative guidelines?
07:24:09 [matt]
jo: We don't want to lose momentum.
07:25:03 [matt]
DKA: I'm concerned that it will impact the usefulness of the doc in the long run.
07:25:14 [matt]
jo: Anyone who wants to conform to it will conform to it.
07:25:29 [matt]
DKA: I don't think it will impact the conformance but the IP.
07:25:41 [matt]
DKA: Because it won't be covered under the w3c IP policy.
07:27:16 [matt]
DKA: The chance of someone having patents on the HTTP stuff is probably low.
07:27:37 [matt]
jo: We've had this discussion already. The rational thing to do is to take legal advice.
07:28:17 [matt]
jo: There are many people who are not w3c members who have patents and are not obliged to declare them..
07:28:41 [matt]
Kai: Why is this so important with this document?
07:29:16 [matt]
DKA: This doc is the one that gets furthest down the road towards implementing new technology -- but it is NOT implementing...
07:29:25 [matt]
s/implementing/introducing/
07:30:15 [matt]
DKA: I think we should accept this resolution and then seek legal advice, give an action to a w3c-er to find out.
07:30:29 [matt]
dom: Asking the lawyer will result in a no.
07:30:37 [matt]
jo: Perhaps we can refine the question.
07:32:01 [matt]
DKA: Is there a way we can continue with the doc as it is, but work in the background so we don't lose time before rechartering?
07:32:41 [matt]
DKA: We get it to CR, and leave it there until July of 2009.
07:33:09 [matt]
jo: How does this mitigate IP problems?
07:33:10 [edm]
Q+ to ask about publishing the doc as is or inserting some statement re its anticipated normative future (or not...)
07:34:00 [matt]
SeanP: Can we ask for testimonials?
07:34:11 [francois]
ack edm
07:34:11 [Zakim]
edm, you wanted to ask about publishing the doc as is or inserting some statement re its anticipated normative future (or not...)
07:34:19 [matt]
SeanP: Wouldn't necessarily be enforceable, but make it feel better.
07:34:35 [matt]
edm: Can we expose what we're talking about now in the document? Say that it's anticipated to become normative?
07:34:37 [Kai]
q+
07:34:48 [DKA1]
ack k
07:34:55 [Kai]
q+
07:35:26 [matt]
DKA: You say keep it informative, but put wording in saying "sorry, we forgot to make it normative?"
07:35:38 [matt]
edm: Is it better to do it as we are, or to spell it out?
07:35:48 [DKA1]
q?
07:35:50 [dom]
ack k
07:35:50 [DKA1]
ack k
07:36:06 [matt]
Kai: I don't see the problem. If we make it a normative document, the process deals with it.
07:36:26 [matt]
jo: The issue is that we have to change the charter to make it normative. We can't
07:36:39 [matt]
jo: produce normative stuff in this charter.
07:37:21 [matt]
dom: We could start rechartering now...
07:37:32 [matt]
jo: I would be uncomfortable rechartering without knowing the future of the MWI.
07:37:41 [matt]
dom: I don't believe the group will close regardless of what happens to the MWI.
07:37:52 [SeanP]
q+
07:38:04 [DKA1]
ack se
07:38:08 [matt]
DKA: It seems like the work will go on regardless.
07:38:17 [matt]
SeanP: There's talk about slowing down the momentum if we recharter...
07:38:54 [matt]
DKA: It will slow things down, the AC has to review it.
07:39:15 [matt]
dom: Plus there's the delay of getting your AC rep to rejoin the group, etc.
07:39:29 [matt]
DKA: Plus writing the charter, etc time for the staff.
07:39:37 [matt]
Kai: There's no short cut?
07:39:44 [matt]
dom: I don't believe there is when there's a patent policy implication.
07:43:09 [Kai]
Kai has joined #bpwg
07:43:19 [matt]
dom: People still had to disclose patents, even for informative docs.
07:44:19 [matt]
Kai: Now if the doc remains informative, this patent stuff isn't an issue...
07:44:30 [matt]
DKA: Yes, but you could be exposing the entire ecosystem down the line...
07:44:55 [matt]
jo: But only adding in exposure for the WG members.
07:45:07 [matt]
s/exposure for/ exposure from/
07:45:32 [matt]
q+
07:45:47 [DKA1]
q?
07:46:04 [matt]
dom: People in the WG are developing this, and don't want to put things in there that are patented, even by those outside the group.
07:46:13 [matt]
dom: If you have patents and are in the group, you are giving a license.
07:47:02 [DKA1]
ack matt
07:48:03 [rob]
q+ to note that Openwave las lots of patents, some that might be relevant - but I haven't checked through them to know if they are essential
07:48:09 [matt]
matt: If this WG is representative of the ecosystem as a whole, and the WG doesn't believe it's patentable, that's a good indicator that it might not be.
07:48:40 [matt]
DKA: That's why I'm leaning towards @@
07:49:15 [matt]
DKA: Perhaps the new charter includes a conformance document that references this doc... very lightweight.
07:49:17 [matt]
dom: But you lose the patent commitments...
07:50:01 [matt]
dom: We should take the resolution now or @@
07:50:34 [matt]
s/@@/if we make it normative, start the recharterting process now/
07:50:42 [matt]
dom: and otherwise keep it informative and leave it alone.
07:50:50 [francois]
q?
07:50:55 [francois]
ack rob
07:50:55 [Zakim]
rob, you wanted to note that Openwave las lots of patents, some that might be relevant - but I haven't checked through them to know if they are essential
07:50:56 [DKA1]
ack rob
07:51:21 [matt]
rob: We've got lots of patents that might be relevant, haven't checked them, haven't gotten the lawyers to look at them either.
07:51:40 [matt]
DKA: The downside of going into this process is that it might trigger a whole lot of legal searches, etc
07:51:47 [matt]
dom: It's not a downside.
07:52:07 [matt]
DKA: Do we think rechartering would significantly delay things?
07:52:12 [matt]
dom: The biggest risk is that we lose members.
07:52:35 [matt]
jo: It's not clear that members who signed up through December would be happy to go beyond that.
07:52:58 [Kai]
q+ to ask about going normative with an unfinished document and the legal issues involved
07:53:04 [matt]
dom: There's always the chance for participants to leave at any time.
07:53:56 [DKA1]
ack k
07:53:56 [Zakim]
Kai, you wanted to ask about going normative with an unfinished document and the legal issues involved
07:54:03 [francois]
ack Kai
07:54:44 [matt]
Kai: I wouldn't bring a doc to the lawyers until it's just about done.
07:54:59 [matt]
dom: There are various calls for exclusions during the publishing process.
07:55:11 [matt]
dom: You never quite get to see the final document before it's finished.
07:56:39 [matt]
DKA: Two options: 1. Restart rechartering process now, where the only changes: would be the informative to normative change for this doc, as well as extend the WG, 6 months into 2009
07:56:52 [matt]
DKA: Option 2: Do nothing, issue document non-normatively, possibly revisit in December, but no guarantees.
07:57:47 [matt]
DKA: Having the document being normative would shield you, somewhat from member-IP.
07:58:02 [matt]
dom: Anything they don't exclude you get a license for.
08:00:06 [matt]
dom: Very few charters have been rejected after AC review.
08:00:22 [matt]
q
08:00:24 [matt]
q+
08:00:31 [DKA1]
ack matt
08:01:51 [matt]
matt: If the charter ran out in December, and you wanted a new charter, would there be more work that you might want to add to the WG than just these?
08:02:26 [matt]
DKA: The talk right now is that we just want to wind down the work that's in the charter... and then <mixed metaphor about zombies or something>
08:02:35 [matt]
DKA: I favor the idea of not adding more work items.
08:03:35 [matt]
jo:"Option 2: Do nothing, issue document non-normatively, possibly revisit in December, but no guarantees." -- plus get legal advice.
08:04:28 [matt]
1 vote for option 2, option 1 had five or so votes...
08:04:48 [matt]
dom: Jo, voting for option 2, is there a strong objection to 1?
08:05:03 [matt]
jo: No objection other than there's no chance of me working on it past the charter.
08:05:39 [matt]
DKA: I think people will look even closer when we recharter at the CT stuff.
08:05:56 [matt]
DKA: Let's take a resolution that reflects the rough consensus.
08:06:30 [jo]
s/No objection other than there's no chance of me working on it past the charter./I will not object given the strength of feeling on this but there is no chance of my working on a new charter given my current work load/
08:06:32 [matt]
Kai: Option 1 still needs everyone to check their legal stuff before we recharter.
08:06:48 [DKA1]
q?
08:07:54 [jo]
s/on a new charter/on writing a new charter/
08:07:55 [matt]
matt: Does this mean jo leaves asap or at end of the year?
08:08:06 [matt]
rrsagent, draft minutes
08:08:06 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/06/16-bpwg-minutes.html matt
08:09:54 [matt]
PROPOSED RESOLUTION: Restart rechartering process now, where the only changes: would be the informative to normative change for this doc, as well as extend the WG, 6 months into 2009
08:10:03 [DKA1]
+1
08:10:07 [Kai]
+1
08:10:07 [rob]
+1
08:10:09 [dom]
I object
08:10:12 [SeanP]
+1
08:10:13 [dom]
NOT
08:10:18 [edm]
+1
08:10:35 [dom]
ACTION: francois to start the rechartering process
08:10:35 [trackbot]
Created ACTION-776 - Start the rechartering process [on Fran├žois Daoust - due 2008-06-23].
08:10:35 [matt]
RESOLUTION: Restart rechartering process now, where the only changes: would be the informative to normative change for this doc, as well as extend the WG, 6 months into 2009
08:10:41 [jo]
I abstain
08:36:40 [edm]
scribe: edm
08:36:55 [edm]
scribenick: edm
08:37:23 [edm]
topic: Content transformation revisited
08:38:14 [edm]
dka: would like to get the CT document as close as possible to last call working draft status
08:38:30 [francois]
-> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080606 latest draft
08:39:12 [Scott]
Scott has joined #bpwg
08:39:21 [edm]
dka: suggest a quick walkthrough
08:40:15 [edm]
francois: emphasis on quick - let's focus on the remaining issues
08:42:00 [DKA1]
http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/0049.html
08:42:53 [edm]
francois: CT guidelines focus on the proxy between the user and the server...
08:43:29 [dom]
-> http://www.w3.org/2005/MWI/BPWG/Group/track/products/12 13 open issues on content transformation guidelines
08:43:43 [edm]
francois: ... so that content provider retains some control over proxy behavior
08:44:48 [edm]
francois: CT guidelines are organized as request side and response side
08:45:17 [adam]
adam has joined #bpwg
08:45:27 [edm]
francois: restrictions appear mostly on the request side - less on the response side
08:45:36 [francois]
q?
08:45:43 [zakcohen]
zakcohen has joined #bpwg
08:45:59 [edm]
francois: let's review the remaining issues
08:46:39 [francois]
Close ACTION-756
08:46:39 [trackbot]
ACTION-756 Seek further legal advice on the patent issues around CT closed
08:46:43 [edm]
dka: let's close the informative vs. normative issue - as per this nmorning discussion
08:46:45 [francois]
Close ACTION-757
08:46:45 [trackbot]
ACTION-757 Seek opinion on CT Patent issue closed
08:47:08 [francois]
+ Close ISSUE-259
08:47:09 [edm]
s/nmorning/morning's/
08:47:43 [edm]
francois: issue-187 (old)
08:47:59 [jo]
ISSUE-187?
08:47:59 [trackbot]
ISSUE-187 -- Link/Rel to MOK versions of non-MOK resources -- OPEN
08:47:59 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/187
08:48:06 [edm]
francois: ISSUE-187 Link/Rel to MOK versions of non-MOK resources
08:49:40 [edm]
jo: this relates to ISSUE-222...
08:49:49 [edm]
ISSUE-222?
08:49:49 [trackbot]
ISSUE-222 -- TAG Finding on Alternative Representations -- OPEN
08:49:49 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/222
08:51:14 [edm]
francois: link element is the key
08:52:00 [edm]
francois: guidelines specify CT proxy should redirect to handheld representation...
08:53:17 [edm]
francois:...but the server should indicate the medium for the intended presentation...
08:53:56 [edm]
dka: what's the negative of using the link element to link to itself?
08:54:53 [edm]
jo: how do you determine if the representation from the URI is a link to self
08:57:44 [dom]
-> http://www.w3.org/TR/html401/types.html#type-media-descriptors Media descriptors in HTML 4.01 rec
08:58:38 [dom]
"Future versions of HTML may introduce new values and may allow parameterized values. To facilitate the introduction of these extensions, conforming user agents must be able to parse the media attribute value as follows:
08:58:38 [dom]
1. The value is a comma-separated list of entries. For example,
08:58:38 [dom]
media="screen, 3d-glasses, print and resolution > 90dpi"
08:58:38 [dom]
is mapped to:
08:58:38 [dom]
"screen"
08:58:40 [dom]
"3d-glasses"
08:58:42 [dom]
"print and resolution > 90dpi"
08:58:44 [dom]
"
08:59:09 [jo]
PROPSOSED RESOLUTION: Link header/element with media type of handheld and an empty URI indicates that the current resource is intended for handhelp presentation
08:59:29 [edm]
jo: we need means for the origin server to signal that this representation is meant for this presentation
09:00:49 [jo]
s/handhelp/handheld/
09:01:48 [edm]
dom: points out a difference between the URI referring to the resource and/or the representation
09:01:54 [jo]
s/resource/representation of the resource/
09:02:40 [edm]
dom: if you send the right user agent header you should get the right representation
09:04:19 [edm]
jo: some URIs point to abstract resource, some to specific representations of this resource
09:06:42 [edm]
dom: CT guidelines suggest not transforming anything that is mobile friendly - whether or not it really is
09:07:13 [edm]
s/that is mobile/that claims to be mobile/
09:09:11 [dom]
maybe "s/the current resource/the current representation/"
09:09:15 [edm]
jo: is response to mobile headers, whose mobile friendly content should apply - origin server's or proxy's?
09:09:29 [edm]
s/is response/in response/
09:09:44 [jo]
PROPSOSED RESOLUTION: Having requested a resource with mobile headers, a Link header/element with media type of handheld and an empty URI indicates that the current representation of the resource is intended for handheld presentation
09:10:03 [dom]
+1
09:12:51 [adam]
q+
09:14:10 [DKA1]
q?
09:14:19 [DKA1]
ack adam
09:14:29 [edm]
s/PROPSOSED/PROPOSED/
09:15:38 [SeanP]
q+
09:15:41 [achuter]
achuter has joined #bpwg
09:15:57 [DKA1]
ack seanp
09:19:41 [edm]
dom: the decision of what is appropriate representation rests with the content provider
09:21:06 [dom]
-> http://www.w3.org/2008/06/rejected-mwbp-test/results Results of testing 406 responses on mobile browsers
09:22:34 [edm]
Francois: 404 response works, 406 not necessarily for all browsers
09:23:35 [jo]
q+ to say something meaningful
09:24:28 [edm]
dka: media handheld is what is being supported now, other media types could be considered when get introduced
09:24:39 [DKA1]
ack jo
09:24:39 [Zakim]
jo, you wanted to say something meaningful
09:24:41 [francois]
ack jo
09:25:10 [dom]
-> http://www.w3.org/TR/html401/struct/global.html#adef-profile profile attribute on HEAD in HTML
09:32:02 [DKA1]
q?
09:32:04 [jo]
PROPOSED RESOLUTION: a Link header/element with media type of handheld and a URI referring to a location within the resource indicates that the current representation of the resource is intended for handheld presentation
09:32:44 [edm]
dka: would this allow to close ISSUE-222?
09:33:23 [rob]
+1
09:33:30 [francois]
+1
09:33:31 [jo]
+1
09:33:40 [Kai]
+1
09:33:42 [DKA1]
+1
09:34:09 [SeanP]
+1
09:35:21 [edm]
RESOLUTION: a Link header/element with media type of handheld and a URI referring to a location within the resource indicates that the current representation of the resource is intended for handheld presentation
09:35:25 [Kai]
ScribeNick: Kai
09:36:02 [dom]
RRSAgent, draft minutes
09:36:02 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/06/16-bpwg-minutes.html dom
09:36:09 [Kai]
DKA1: only the tag thing needs to be resolved for this issue
09:36:28 [jo]
PROPOSED RESOLUTION: Make the point explicitly in the document that an empty href on a link header/element means that this reource is capable of being rendered in a way that is suitable for handhelp presentation, but that without the above link element there is a question as to whether this representation is or is not suitable for handheld
09:37:17 [DKA1]
q?
09:37:58 [Kai]
Jo: if you have an emtpy href it could mean it is or could be rendered as handheld
09:38:30 [Kai]
francois: the important part is the fragment. you could link to yourself
09:38:51 [Kai]
dom: does that effect the resolution we just took?
09:38:59 [Kai]
francois: no not really.
09:39:50 [jo]
PROPOSED RESOLUTION: Make the point explicitly in the document that an href which refers to this resource but which does not have a fragment identifier on a link header/element means that this reource is capable of being rendered in a way that is suitable for handhelp presentation, but that without the above link element there is a question as to whether this representation is or is not...
09:39:52 [jo]
...suitable for handheld
09:39:53 [edm]
s/handhelp/handheld/
09:40:09 [francois]
+1
09:40:20 [DKA1]
+1
09:40:31 [Kai]
RESOLUTION: Make the point explicitly in the document that an href which refers to this resource but which does not have a fragment identifier on a link header/element means that this reource is capable of being rendered in a way that is suitable for handhelp presentation, but that without the above link element there is a question as to whether this representation is or is not...
09:40:34 [SeanP]
+1
09:41:09 [dom]
ISSUE-261?
09:41:09 [trackbot]
ISSUE-261 -- Scoping 200 responses that should be regarded as 406 responses -- OPEN
09:41:09 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/261
09:41:16 [Kai]
francois: Topic ISSUE-261
09:41:31 [edm]
ISSUE-261?
09:41:31 [trackbot]
ISSUE-261 -- Scoping 200 responses that should be regarded as 406 responses -- OPEN
09:41:31 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/261
09:42:21 [Kai]
francois: I am not sure how many websites will send human readble responses about an error
09:42:44 [Kai]
...Aaron was going to send some stats on this
09:43:03 [Kai]
...he has not yet, but could bring stats within 2 weeks
09:43:13 [jo]
s/handhelp/handheld/
09:43:15 [Kai]
...is our recommendation useful and needed?
09:43:28 [Kai]
dom: does dotmobi have studies on this?
09:43:32 [Kai]
jo: not that I know of
09:44:08 [Kai]
Dka: is that a meaningful question? If one or two high use sites do it, that would already be as damaging as many low use sites
09:44:29 [Kai]
francois: if only a few are doing that, proxies could list those and send different headers
09:44:33 [DKA1]
q?
09:44:58 [Kai]
jo: however they do it does not concern the guidelines#
09:45:40 [Kai]
dka: the guidelines are written thinking that more and more site adapt, operators use proxies...problems will become bigger problems, which is why we are setting these rules down.
09:45:54 [Kai]
...this is the whole point...anticpation
09:46:02 [zakcohen]
zakcohen has joined #bpwg
09:46:15 [Kai]
...we try to codfiy it before it becomes a problem
09:46:41 [Kai]
francois: we already have enough restritction on http header modification
09:47:01 [jo]
q+
09:47:04 [Kai]
dka: key is are recommeding this approach or not?
09:47:08 [dom]
q?
09:47:37 [Kai]
...for when a 200 response is sent but there is no link header. If they do see it they should consider it.
09:47:59 [Kai]
...we are justified to put this in the doc
09:48:14 [Kai]
SeanP: so you say we will have to do something about this anyway?
09:48:18 [Kai]
DKA1: yes
09:48:24 [DKA1]
ack jo
09:48:49 [Kai]
jo: we could not mention bogus responses
09:49:22 [Kai]
...or we say a 200 response like that is a rejection
09:49:23 [SeanP]
q+
09:49:42 [DKA1]
ack seanp
09:49:48 [Kai]
...if there is no no-transform this is intentional
09:49:55 [francois]
ack SeanP
09:50:06 [Kai]
SeanP: I think we should mention it. we don't want to be too vague.
09:50:14 [Kai]
DKA1: we should be explicit
09:50:28 [dom]
s/DKA1:/DKA:/g
09:51:08 [jo]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0039.html
09:51:56 [Kai]
jo is going through his email
09:53:28 [Kai]
jo: proposes to use the pertinent part of the document, with some editorial changes
09:53:35 [jo]
jo quotes the following:
09:53:37 [jo]
The logic of 4.1.2 would then be:
09:53:38 [jo]
Request resource with original headers
09:53:40 [jo]
- If the response is a 406 response, re-request with altered headers
09:53:42 [jo]
(unless the 406 response contains no-transform).
09:53:43 [jo]
- If the response is a 200 response,
09:53:45 [jo]
--if the response contains vary: User-Agent, an appropriate link
09:53:46 [jo]
element or header, or no-transform, forward it
09:53:48 [jo]
--otherwise assess (by unspecified means) whether the 200 response is a
09:53:49 [jo]
bogus one
09:53:51 [jo]
---if it is not, forward it
09:53:52 [jo]
---if it is, re-request with altered headers
09:54:24 [Kai]
jo: this could become a normative algorythm
09:54:37 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-261, adopt Jo's proposal for a process for a process for CT bogus 200 response detection (4.1.2) and close ISSUE-261.
09:54:44 [jo]
s/this could/ we would not want this to/
09:55:08 [jo]
+1
09:55:11 [francois]
+1
09:55:13 [DKA1]
RESOLUTION: Regarding ISSUE-261, adopt Jo's proposal for a process for a process for CT bogus 200 response detection (4.1.2) and close ISSUE-261.
09:55:14 [dom]
+1
09:55:15 [Kai]
RESOLUTION: Regarding ISSUE-261, adopt Jo's proposal for a process for a process for CT bogus 200 response detection (4.1.2) and close ISSUE-261.
09:55:32 [francois]
Close ACTION-673
09:55:32 [trackbot]
ACTION-673 See if he can get some figures that scope the problem of bogus 200 responses closed
09:55:39 [francois]
Close ACTION-768
09:55:39 [trackbot]
ACTION-768 Ping Aaron on scoping bogus 200 responses closed
09:55:41 [Kai]
francois: so I don't have to bother aaron
09:55:49 [francois]
Close ACTION-771
09:55:49 [trackbot]
ACTION-771 Send a proposal on using meta data to alert CT-proxy that this is a rejected response even if it's a 200 closed
09:55:57 [dom]
s/<DKA1> RESOLUTION:/<DKA1> PROPOSED RESOLUTION:/
09:55:59 [jo]
ACTION: Jo to edit 4.1.2 according to above resolution
09:55:59 [trackbot]
Created ACTION-777 - Edit 4.1.2 according to above resolution [on Jo Rabin - due 2008-06-23].
09:56:03 [Kai]
francois: ISSUE-257?
09:56:13 [Kai]
ISSUE-257?
09:56:25 [dom]
ISSUE-257?
09:56:25 [trackbot]
ISSUE-257 -- Clarification of section 4.1.2 -- OPEN
09:56:25 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/257
09:56:48 [Kai]
francois: I would like to resolve to rename the section
09:57:12 [Kai]
jo: i would prefer if we address specific points
09:57:22 [Kai]
....(going through email)
09:57:53 [Kai]
s/(going through email)/(going through document)
09:58:19 [Kai]
Jo: Section 4.1.2
09:58:36 [DKA1]
a) the user would be prohibited from accessing content as a result of a
09:58:36 [DKA1]
406 or bogus 200 response;
09:58:37 [DKA1]
b) the user has specifically requested a restructured desktop experience;
09:58:37 [DKA1]
c) the request is part of a session of some sort and either it is
09:58:37 [DKA1]
technically infeasible not to adjust the request because of earlier
09:58:39 [DKA1]
interaction, or because doing so preserves a consistency of user experience.
09:58:49 [DKA1]
In that section my understanding of what we are trying to do is
09:58:49 [DKA1]
identify that the request headers should not be altered unless:
09:58:49 [DKA1]
a) the user would be prohibited from accessing content as a result of a
09:58:49 [DKA1]
406 or bogus 200 response;
09:58:49 [DKA1]
b) the user has specifically requested a restructured desktop experience;
09:58:51 [DKA1]
c) the request is part of a session of some sort and either it is
09:58:53 [DKA1]
technically infeasible not to adjust the request because of earlier
09:58:55 [DKA1]
interaction, or because doing so preserves a consistency of user experience.
09:59:31 [Kai]
jo: i think together with renaming is the essence of what we are trying to say
09:59:53 [Kai]
s/is the/this is the
10:00:57 [Kai]
francois: we still need to deal with user preferences
10:01:06 [Kai]
jo: yes, need to have a discussion on it
10:02:14 [Kai]
jo: so we would remove the unnumbered bullets and reword 1 through 3
10:02:30 [Kai]
...do we need very specific text here?
10:02:49 [Kai]
...there are three cases to consider
10:03:22 [Kai]
dka: that removes the discussion of prior knowledge, server behavior etc.
10:03:27 [Kai]
jo: yes it does
10:03:55 [zakcohen`]
zakcohen` has joined #bpwg
10:03:57 [Kai]
dka: it removes the ability for CT proxies to rely on user preferences
10:04:05 [Kai]
francois: that is a different discussion
10:04:21 [Kai]
dka: the request doesn't have to be at that point
10:04:27 [Kai]
jo: that's for us to defein
10:04:35 [Kai]
s/defein/define
10:04:38 [DKA1]
q?
10:05:03 [Kai]
seanp: can look at the exact text?
10:06:40 [Kai]
...tick...tick...tick...tick
10:07:42 [jo]
Proxies should not intervene in methods other than GET, POST, HEAD and PUT.
10:07:44 [jo]
If there is a no-transform directive present in the request the proxy should not modify the request headers.
10:07:45 [jo]
The proxy should not modify request headers unless:
10:07:47 [jo]
a) the user would be prohibited from accessing content as a result of a
10:07:48 [jo]
406 or bogus 200 response;
10:07:50 [jo]
b) the user has specifically requested a restructured desktop experience;
10:07:52 [jo]
c) the request is part of a session of some sort and either it is
10:07:53 [jo]
technically infeasible not to adjust the request because of earlier
10:07:55 [jo]
interaction, or because doing so preserves a consistency of user experience.
10:09:11 [jo]
Note:
10:09:12 [jo]
Rejection of a request by a server is taken to mean both a HTTP 406 Status as well as HTTP 200 Status, with content indicating that the request cannot be handled - e.g. "Your browser is not supported"
10:09:21 [Kai]
dka: this replace all up to point 3) in 4.1.2
10:09:32 [Kai]
s/replace/replaces
10:09:51 [Kai]
francois: can we change the name of the section?
10:10:05 [Kai]
SeanP: this is to remove the duplication and make it clearer?
10:10:13 [DKA1]
PROPOSED RESOLUTION: Adopt Jo's wording for 4.1.2 of the CT document (pending some editorial "tweaking") and close ISSUE-257.
10:10:46 [Kai]
dka: any objections?
10:10:51 [DKA1]
+1
10:10:54 [francois]
+1
10:11:07 [Kai]
RESOLUTION: Adopt Jo's wording for 4.1.2 of the CT document (pending some editorial "tweaking") and close ISSUE-257.
10:12:00 [Kai]
francois: could we agree on issue-243 to leave it and address it later?
10:12:24 [Kai]
...it's linked to POWDER and can probably wait?
10:12:41 [jo]
ACTION: Jo to add the stuff on possible use of OPTIONS to the appendix
10:12:41 [trackbot]
Created ACTION-778 - Add the stuff on possible use of OPTIONS to the appendix [on Jo Rabin - due 2008-06-23].
10:13:16 [Kai]
francois: I will take the action
10:13:20 [dom]
ACTION-777?
10:13:20 [trackbot]
ACTION-777 -- Jo Rabin to edit 4.1.2 according to above resolution -- due 2008-06-23 -- OPEN
10:13:20 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/777
10:13:25 [DKA1]
PROPOSED RESOLUTION: Close ISSUE-243.
10:13:50 [francois]
PROPOSED RESOLUTION: Close ISSUE-243 and mention it in "Scope for Future Work" appendix
10:13:53 [DKA1]
PROPOSED RESOLUTION: Close ISSUE-243 and mention this topic in the appendix as scope for future work.
10:14:00 [francois]
+1
10:14:20 [Kai]
RESOLUTION: Close ISSUE-243 and mention this topic in the appendix as scope for future work.
10:15:02 [Kai]
ISSUE-224?
10:15:02 [trackbot]
ISSUE-224 -- How should we make an assessment of the impact of the various possible guidelines on real web sites -- OPEN
10:15:02 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/224
10:15:28 [Kai]
francois: don't know how to address that?
10:15:39 [Kai]
jo: it is not so much of an issue today.
10:16:07 [Kai]
dom: the cr phase would be for that
10:16:44 [DKA1]
PROPOSED RESOLUTION: regarding ISSUE-224, we are no longer as worried about the impact of these guidelines on existing content, so this issue can be closed and the topic left to the exit-criteria from CR (testing implementations).
10:16:56 [francois]
+1
10:17:07 [DKA1]
PROPOSED RESOLUTION: regarding ISSUE-224, we are no longer as worried about the impact of these guidelines on existing content, so this issue can be closed and the topic left to the exit-criteria from CR (testing implementations) - and close ISSUE-224.
10:17:12 [francois]
Close ACTION-774
10:17:12 [trackbot]
ACTION-774 Check the OPTIONS method for ISSUE-243 closed
10:17:14 [jo]
+1
10:17:18 [Kai]
RESOLUTION: regarding ISSUE-224, we are no longer as worried about the impact of these guidelines on existing content, so this issue can be closed and the topic left to the exit-criteria from CR (testing implementations) - and close ISSUE-224.
10:17:36 [DKA1]
lunch!
10:18:14 [Kai]
dka: we will continue to go through issues after lunch. Will do scheme discussion after break.
10:18:30 [Kai]
s/after break/after second break
11:09:08 [DKA1]
Returning from lunch.
11:09:41 [Scott]
Scott has joined #bpwg
11:16:20 [adam]
adam has joined #bpwg
11:20:33 [rob]
Scribe: rob
11:20:40 [rob]
scribenick: rob
11:20:45 [edm]
edm has joined #bpwg
11:21:21 [rob]
dka: 6 issues remain...
11:21:39 [manrique]
manrique has joined #bpwg
11:22:00 [rob]
ISSUE-241?
11:22:00 [trackbot]
ISSUE-241 -- Tokenization of URIs -- OPEN
11:22:00 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/241
11:22:07 [dom]
ISSUE-223?
11:22:07 [trackbot]
ISSUE-223 -- Various Items to Consider for the CT Guidelines -- OPEN
11:22:07 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/223
11:22:34 [rob]
francios: 1-6 already dealt with
11:22:45 [dom]
s/ios/ois/
11:23:44 [rob]
... point 7 seems like nothing we can do without inventing new technology
11:24:01 [rob]
... POWDER could be used in future
11:24:23 [rob]
jo: points 7,8,9,11 are the same - future work
11:25:01 [DKA1]
PROPOSED RESOLUTION: From Jo's list (ISSUE-223) we will consider points 7, 8, 9 and 11 as out of scope for the current work (but possibly in scope for future work).
11:25:07 [francois]
+1
11:25:16 [SeanP]
+1
11:25:19 [rob]
+1
11:25:30 [rob]
RESOLUTION: From Jo's list (ISSUE-223) we will consider points 7, 8, 9 and 11 as out of scope for the current work (but possibly in scope for future work).
11:25:32 [jo]
ACTION: Jo to transcribe points 7 8 9 and 11 of ISSUE-223 into Scope for future work
11:25:32 [trackbot]
Created ACTION-779 - Transcribe points 7 8 9 and 11 of ISSUE-223 into Scope for future work [on Jo Rabin - due 2008-06-23].
11:26:23 [rob]
francois: point 10 is MobileOK required for CT-proxies?
11:26:43 [rob]
dka: seems obvious, it's overloading the doc
11:26:53 [DKA1]
q?
11:26:54 [dom]
q+ jo
11:26:55 [DKA1]
ack jo
11:27:02 [rob]
... a chilling advertising effect
11:27:15 [zakcohen]
zakcohen has joined #bpwg
11:27:56 [rob]
jo: in doc sec 4.4 we said CT-proxy output should validate according to a published standard
11:29:41 [rob]
s/published/formal/
11:30:00 [DKA1]
PROPOSED RESOLUTION: On point 10 of ISSUE-223 (whether CT proxies should be MobileOK) we should remain silent.
11:30:15 [SeanP]
+1
11:30:22 [DKA1]
+1
11:30:23 [rob]
+1
11:30:37 [Kai]
+1
11:30:40 [rob]
RESOLUTION: On point 10 of ISSUE-223 (whether CT proxies should be MobileOK) we should remain silent.
11:31:25 [rob]
francois: point 12 - if content is mobileOK then can it be transformed?
11:33:01 [DKA1]
PROPOSED RESOLUTION: On point 12 of ISSUE-223 (whether CT proxies should refrain from transforming MobikeOK content) we should allow for the possibility that CT proxies should be able to transform MobikeOK content but that they should take into account MobileOK-ness as part of the heuristics involved in determining whether content is mobile-friendly.
11:33:57 [SeanP]
+1
11:34:02 [rob]
kai: content could still be transformed (from mobileOK to mobileOK) because a CT-proxy knows somehting about the device that the original content didn't account for
11:35:50 [rob]
jo: RFC2616 has an example about medical imaging content that mustn't be altered
11:36:10 [DKA1]
PROPOSED RESOLUTION: On point 12 of ISSUE-223 (whether CT proxies should refrain from transforming MobikeOK content) we should allow for the possibility that CT proxies should be able to transform MobikeOK content but that they should take into account MobileOK-ness as part of the heuristics involved in determining whether content is mobile-friendly (but remain silent on how you check if something is mobileOK).
11:36:27 [francois]
+1
11:36:31 [SeanP]
+1
11:36:45 [rob]
+1
11:36:49 [Kai]
+1
11:36:52 [dom]
+1
11:37:13 [DKA1]
PROPOSED RESOLUTION: On point 12 of ISSUE-223 (whether CT proxies should refrain from transforming MobikeOK content) we should allow for the possibility that CT proxies should be able to transform MobileOK content but that they should take into account MobileOK-ness as part of the heuristics involved in determining whether content is mobile-friendly (but remain silent on how you check if something is mobileOK).
11:37:27 [rob]
RESOLUTION: On point 12 of ISSUE-223 (whether CT proxies should refrain from transforming MobileOK content) we should allow for the possibility that CT proxies should be able to transform MobileOK content but that they should take into account MobileOK-ness as part of the heuristics involved in determining whether content is mobile-friendly (but remain silent on how you check if something is mobileOK).
11:37:30 [jo]
+1 (in respect of Mobikes)
11:38:11 [jo]
ACTION: Jo to add text to section 4.4 referencing above resolution on mobikeOK
11:38:11 [trackbot]
Created ACTION-780 - Add text to section 4.4 referencing above resolution on mobikeOK [on Jo Rabin - due 2008-06-23].
11:38:36 [edm]
edm has joined #bpwg
11:39:57 [DKA1]
q?
11:40:43 [rob]
ISSUE-241?
11:40:43 [trackbot]
ISSUE-241 -- Tokenization of URIs -- OPEN
11:40:43 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/241
11:43:07 [rob]
francois: do we need to say anything about changing links in an adapted session to "made-up links" to the CT-proxy's own domain so it can invent new URLs for sub-pages, javascript events, etc
11:46:05 [rob]
dom: so what about rewriting URLs in a page of search-results?
11:46:22 [rob]
seanP: they all get rewritten
11:46:56 [rob]
jo: if you follow what it says in sec 4.1 you will then fall out of the transforming look
11:47:04 [rob]
s/look/loop/
11:48:20 [rob]
dom: URL re-writing does overwrite the Host: request header
11:52:16 [rob]
jo: it would be inconsistent to allow users to go to the operator portal and the operator to rewrite URLs to the whole of the Internet to then assume they are compliant
11:53:00 [dom]
[I would request at least that the issue be re-titled]
11:54:29 [rob]
francois: need to ensure content-providers at least can see the requests as faithfully as possible when appropriate
12:02:01 [rob]
jo: this touches on the undefined concept of a "session" being entered where the CT-proxy is unavoidably explicitly addressed by all requests from the handset
12:02:56 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request to a new server, this is a different "session" and therefore the content must be tasted.
12:05:16 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request to a new "web site", this is a different "session" and therefore the content must be tasted (allowing for different heuristics for determining whether request is to a different or the same "web site.")
12:06:59 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request to a new "web site", this is a different "session" and therefore the content must be tasted (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example.)
12:08:29 [rob]
... key issue is if CT-proxy is transforming content for site A and then makes bad decisions in continuing transformation following links to site B that would normally be mobile-friendly
12:08:39 [DKA1]
q?
12:11:23 [rob]
kai: domain name isn't a great distinguishing feature for websites, eg images often served from different domains
12:12:38 [rob]
seanP: in the CT world, we tend to think of a "session" as something between the handset and CT-proxy, not between bandset and website
12:14:23 [rob]
dom: currently guidelines allow you to carry on transforming all the time (even after following a link to mobile-friendly site) after you have started transforming a website that needed transformation
12:16:13 [rob]
jo: do we need to distinguish between "linked resources" (eg <a href="...">) and "included resources" (eg <img src="..." />)
12:16:24 [rob]
... ?
12:17:26 [rob]
dka: do we stand a chance of resolving this issue today? Or should we leave it for future work?
12:18:52 [rob]
... should we tease apart the two sides of the CT-proxy and define "sessions" on both sides?
12:19:07 [rob]
... or concentrate on rules for "tasting content"
12:19:29 [rob]
s/content"/content"?/
12:19:42 [rob]
jo: both in my opinion
12:21:36 [DKA1]
PROPOSED RESOLUTION: Except in the case of https, the content transformation guidelines document does not differentiate between URI rewriting and so-called "transparent" proxy operation.
12:23:09 [DKA1]
PROPOSED RESOLUTION: For CT guidlines, for included resources within a page, content tasting is not required.
12:23:17 [rob]
francois: for included resources tasting is clearly not required. It's only be for linked resources that the question arises
12:23:41 [rob]
s/question/question of tasting content/
12:23:56 [rob]
+1
12:23:57 [DKA1]
PROPOSED RESOLUTION: For CT guidelines, for included resources within a page, additional content tasting is not required.
12:24:02 [Kai]
+1
12:24:03 [francois]
+1
12:24:09 [SeanP]
+1
12:24:12 [rob]
RESOLUTION: For CT guidelines, for included resources within a page, additional content tasting is not required.
12:24:41 [Kai]
ScribeNick: Kai
12:24:56 [Kai]
jo: should you then taste all linked resources?
12:25:08 [Kai]
...this is where get into the end to end session
12:25:39 [Kai]
...it would be simpler if we said all linked resources must be tasted
12:25:50 [DKA1]
PROPOSED RESOLUTION: For CT guidelines, except in the case of https, the content transformation guidelines document does not differentiate between URI rewriting and so-called "transparent" proxy operation.
12:26:20 [Kai]
rob: tasting linked resources may end in superflous tasting
12:26:40 [Kai]
jo: a linked resource is the target of an a element...for sake of simplicity
12:26:58 [Kai]
....following a hyper link is a linked resource...what would that mean?
12:27:08 [Kai]
SeanP: might mean extra requests
12:27:25 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request for a linkd resource to a new "web site", content must be tasted (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example.)
12:27:38 [Kai]
rob: perhaps you should abide by the same tasting rules if you don't know the resource
12:27:47 [Kai]
jo: what does not know mean?`
12:28:05 [Kai]
...tasted before cache expiry level
12:28:26 [Kai]
DKA: can we focus on resolutions?
12:28:38 [edm]
edm has joined #bpwg
12:29:30 [Kai]
RESOLUTION: For CT guidelines, except in the case of https, the content transformation guidelines document does not differentiate between URI rewriting and so-called "transparent" proxy operation.
12:29:59 [Kai]
jo: for the second resolution..any linked resource should be tasted with respect to cache expiry
12:30:36 [Kai]
dka: I don't think so. this brings up all the issues of tasting...am I putting two bids on an auction, putting two books in my basket, etc.
12:30:47 [Kai]
...it's a non starter
12:30:56 [Kai]
jo: we are exploring what ifs
12:31:09 [Kai]
....never taste or always taste linked resources
12:31:21 [DKA1]
q?
12:31:46 [Kai]
francois: dan's point relates to the HTTP method. If there is a form it should not trigger a new tasting.
12:32:03 [Kai]
...can this be explained with GET?
12:32:09 [Kai]
dka: I don't think it is possible.
12:32:38 [Kai]
SeanP: another issue is whether a user wants a desktop experience
12:32:47 [Kai]
...then you wouldn't need to taste it
12:32:56 [Kai]
francois: that is a separate issue
12:33:11 [Kai]
SeanP: the resolution says that it must be tasted.
12:33:20 [Kai]
rob: it should be what is says 4.1
12:33:37 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request for a linked resource to a new "web site", then what's in section 4.1 should happen (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example.)
12:34:09 [Kai]
jo: if we say that linked resources are a different case then we always have content tasting. On the other hand never do that, which it won't be and I don't know why it is not always
12:34:11 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request for a linked resource to a new "web site", then what's in section 4.1.2 should happen (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example.)
12:34:22 [Kai]
rob: it is not clear to me either considering 4.1
12:34:54 [Kai]
francois: if there is a session started, if there is another tasting for the same session......
12:35:26 [edm2z]
edm2z has joined #bpwg
12:35:46 [Kai]
dka: jo you are saying we don't need the thing about new website, because it is dealt with?`
12:35:54 [Kai]
jo: no, not exactly.
12:36:27 [Kai]
dka: so what is wrong with the proposed resolution?
12:36:46 [Kai]
...(reading the resolution)
12:37:56 [Kai]
jo: rob is thinking why not always taste, but prior knowledge has been taken out....how does that change what you said?
12:38:29 [Kai]
rob: dan is talking about a resource to a new website, using the domain name as a definition....it is probably as good as taking out all prior knowledge
12:38:44 [Kai]
jo: the prior knowledge relates to black and white list discussion
12:39:15 [Kai]
...the problem there is if the server alters its behavior it is difficult to change lists. It would be better to do this dynamically.
12:39:30 [Kai]
dka: I don't see where we have white and black lists
12:39:35 [Kai]
jo: we had this last week
12:40:18 [Kai]
....if we can do this dynamically, without ref to prior knowledge or blacka nd white lists it sets an expectation that server behavior is taken account of
12:40:41 [Kai]
...question about the sesssion is related to the prior knowledge...
12:41:03 [Kai]
....so this is like lists, you could make equal assumptions
12:41:36 [Kai]
...linked resources...how often do you need to taste...would also ensure you are fresh
12:42:11 [Kai]
dka: we are not introducing wording that would have a bad effect.
12:42:19 [Kai]
jo: but we need to take session out
12:42:38 [Kai]
....this is why we are teasing this apart
12:42:46 [Kai]
dka: so hence my resolution
12:42:52 [Kai]
jo: but it may be more granular
12:43:29 [Kai]
...if you have a domain with people having differnet websites underneath same domain...for example
12:44:01 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that the proxy should not taste every linked resource.
12:44:27 [Kai]
SeanP: I think I agree with Dans resolutio before..
12:44:55 [Kai]
rob: we should say do taste if you go to a different website, but not define it as such
12:45:10 [Kai]
jo: let's take both of these resolutions then
12:45:50 [Kai]
...section 4.3...we are saying that you have to re-request, if headers have been modified
12:46:19 [Kai]
jo: this means if the heuristics are wrong you may be wrong
12:46:52 [dom]
RRSAgent, draft minutes
12:46:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/06/16-bpwg-minutes.html dom
12:47:25 [Kai]
francois: there are other ways to control transformation.....
12:47:54 [Kai]
jo: I understand but lets take these resolutions, after modification to remove the word session
12:48:05 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request for a linked resource to a new "web site", then what's in section 4.1.2 should happen (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example. And remove the word "session" from the previous resolution on 4.1.2.
12:48:09 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that the proxy should not taste every linked resource.
12:48:43 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we agree that the proxy does not have to taste every linked resource.
12:48:58 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we agree that the proxy does not have to taste every linked resource (for the sake of clarity).
12:49:05 [Kai]
RESOLUTION: Regarding ISSUE-241, in the CT guidelines we agree that the proxy does not have to taste every linked resource (for the sake of clarity).
12:49:15 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request for a linked resource to a new "web site", then what's in section 4.1.2 should happen (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example. And remove the word "session" from the previous resolution on 4.1.2.
12:49:49 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request for a linked resource to a new "web site", then what's in section 4.1.2 should happen (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example.) And remove the word "session" from the previous resolution on 4.1.2.
12:50:12 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request for a linked resource to a new "web site", then what's in section 4.1.2 should happen (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example. And remove the word "session" from the previous resolution on 4.1.2. And close ISSUE-241. And subsi
12:50:33 [dom]
s/subsi/subsidize soybeans/
12:50:47 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request for a linked resource to a new "web site", then what's in section 4.1.2 should happen (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example. And remove the word "session" from the previous resolution on 4.1.2. And close ISSUE-241.
12:50:57 [Kai]
RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should state that when the proxy makes a request for a linked resource to a new "web site", then what's in section 4.1.2 should happen (allowing for different heuristics for determining whether request is to a different or the same "web site" but giving "hitting a new domain name" as a good example. And remove the word "session" from the previous resolution on 4.1.2. And close ISSUE-241.
12:51:21 [dom]
RRSAgent, draft minutes
12:51:21 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/06/16-bpwg-minutes.html dom
12:51:53 [dom]
ISSUE-255?
12:51:53 [trackbot]
ISSUE-255 -- Subdomain and Path as a heuristic in content transformation -- OPEN
12:51:53 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/255
12:51:59 [SeanP]
scribe: SeanP
12:52:06 [SeanP]
scribenick: SeanP
12:52:40 [SeanP]
Topic: Issue-255
12:53:48 [jo]
[jo makes note to self ref Linked Resources and Included Resources plus Form Submission]
12:53:50 [dom]
PROPOSED RESOLUTION: re. ISSUE-255, drop mention of examination of URI from 4.1.2 as it's a heuristic to scope rejected 200 responses, detailed in 4.4, and 4.1.2 already precises to examine the response (with a link to 4.4)
12:53:59 [francois]
+1
12:54:09 [jo]
ACTION: Jo to enact changes sugegsted by the previous 4 resolutions
12:54:09 [trackbot]
Created ACTION-781 - Enact changes sugegsted by the previous 4 resolutions [on Jo Rabin - due 2008-06-23].
12:55:14 [SeanP]
Topic: Issue-258
12:55:38 [dom]
RESOLUTION: re. ISSUE-255, drop mention of examination of URI from 4.1.2 as it's a heuristic to scope rejected 200 responses, detailed in 4.4, and 4.1.2 already precises to examine the response (with a link to 4.4)
12:55:54 [dom]
s/<dom> RES/<SeanP> RES/
12:56:08 [SeanP]
Francois: Do we still want to do what's in 258?
12:56:33 [SeanP]
Jo: Not sure requirements belong here, but some people like them.
12:57:03 [SeanP]
Francois: Used to find this useful, now that I've been working on it a while, think it should be removed.
12:57:51 [SeanP]
DKA: If you are new to the W3C, then you might need it. Could leave it in for historical reasons.
12:58:03 [SeanP]
...Could move requirements into scope section.
12:58:13 [SeanP]
Jo: Requirements are partially wrong.
12:58:34 [SeanP]
Francois: Should move them and refresh them.
12:59:15 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-258, move section 3.1 of CT Guidelines document into Scope section (and refresh to synchronize with the rest of the document).
12:59:19 [SeanP]
Jo: In 3.1, 1a and 1b are fine.
13:00:09 [SeanP]
... 2a is OK, 2b is not OK, 2c is OK
13:00:19 [SeanP]
... 3a is OK, 3b is OK
13:00:59 [SeanP]
... 3b needs to be replaced by "is not permissible"
13:01:06 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-258, move section 3.1 of CT Guidelines document into Scope section (and refresh to synchronize with the rest of the document) moving removed requirements into scope for future work.
13:01:10 [SeanP]
... 3c is OK
13:01:16 [SeanP]
... 3d is OK
13:02:05 [SeanP]
... 4a is OK, 5a is not OK, 5b is OK
13:02:31 [SeanP]
... 2d is OK
13:02:37 [DKA1]
PROPOSED RESOLUTION: Regarding ISSUE-258, move section 3.1 of CT Guidelines document into Scope section (and refresh to synchronize with the rest of the document) moving removed requirements into scope for future work (and close ISSUE-258).
13:04:19 [SeanP]
Jo: This could be folded into 3.2 (1, 2, 3, and 4)
13:05:00 [SeanP]
RESOLUTION: Regarding ISSUE-258, move section 3.1 of CT Guidelines document into Scope section (and refresh to synchronize with the rest of the document) moving removed requirements into scope for future work (and close ISSUE-258).
13:05:16 [SeanP]
Topic: Issue-260
13:06:05 [SeanP]
Francois: Difference between regular CT proxy and proxy client combination (like Opera Mini). Treat proxy/client combo as black box.
13:06:19 [SeanP]
... Jo noted that black boxes tend to leak.
13:07:18 [SeanP]
... So guidelines should partially apply. Example of where guidelines should apply is to fix problem where all Opera Mini requests seem to come from Norway.
13:07:55 [SeanP]
Rob: with google proxy, all requests come from the same place too
13:08:26 [SeanP]
Francois: but in that case, the Google proxy is a regular CT proxy
13:08:40 [DKA1]
q?
13:09:10 [jo]
ACTION: Jo to draft text on which aspects of the CT guidelines should be followed by e.g. Opera Mini
13:09:10 [trackbot]
Created ACTION-782 - Draft text on which aspects of the CT guidelines should be followed by e.g. Opera Mini [on Jo Rabin - due 2008-06-23].
13:09:20 [SeanP]
Francois: We should put something about proxy/client combo following guidelines into Appendix.
13:10:09 [francois]
Close ACTION-678
13:10:09 [trackbot]
ACTION-678 Raise and issue on the distinction between a CT proxy and (say) Opera Mini closed
13:34:35 [rob]
rob has left #bpwg
13:34:49 [rob]
rob has joined #bpwg
13:35:13 [dom]
ScribeNick: dom
13:35:20 [zakcohen]
zakcohen has joined #bpwg
13:35:32 [dom]
Topic: ISSUE-242 User expression of persistent and session preferences
13:35:35 [dom]
ISSUE-242?
13:35:35 [trackbot]
ISSUE-242 -- User expression of persistent and session preferences -- OPEN
13:35:35 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/242
13:35:42 [dom]
Francois: 2 questions here
13:35:57 [dom]
... the distinction between persistent and semi-persistent
13:36:10 [dom]
... we decided to avoid talking about semi-persistent settings
13:36:25 [dom]
... we still have to explain what persistent means
13:36:47 [dom]
... The problem here is about user preferences and administrative arrangements
13:37:08 [dom]
... User preferences could just mean that the operator got the user to sign an agreement that completely removes control from the user
13:37:16 [dom]
... this opens a big hole in the guidelines
13:37:48 [dom]
... we need to rewrite 3.2 to be explicit (or clear we're not explicit)
13:38:15 [dom]
DKA: this about the relation between the user and the CT proxy, right?
13:38:31 [dom]
FD: yes, unrelated to a specific request made by the user
13:38:44 [dom]
... It could be controlled by terms and conditions set by the operator
13:39:02 [dom]
EdM: how persistent is persistent? until explicitly changed by the user?
13:39:09 [dom]
Jo: let's put it another way
13:39:47 [dom]
... in the rewritten 4.1.2, the 3 conditions for a proxy to change the headers: technically required, according by previous interactions with the server, because the user has specifically requested a desktop presentation
13:39:53 [dom]
... for this third bit, what does it mean?
13:40:02 [dom]
... * for this server specifically
13:40:12 [dom]
... * or for any request?
13:40:19 [dom]
... I think that's what's at the heart of this
13:40:38 [dom]
... I think it's reasonable that the user should be able to say "for this site, always give me the desktop presentation"
13:40:46 [dom]
... (if the proxy offers that feature)
13:42:38 [jo]
PROPOSED RESOLUTION: It is permissible for the proxy to offer the user a restructured desktop presentation on a 'site' by 'site' basis
13:44:50 [Kai_]
Kai_ has joined #bpwg
13:45:01 [dom]
EdM: when you say site, is "m.example.com" and "www.example.com" the same site?
13:45:08 [Kai_]
nick Kai
13:45:09 [dom]
FD: we leave this to CT vendors to define
13:45:37 [Kai_]
Nick /Kai
13:46:01 [dom]
s/<Kai_>//g
13:49:06 [dom]
Jo: one of the questions is whether we can say something is permissible if it isn't under law?
13:49:15 [dom]
DKA: think we're covered by the document license
13:49:56 [dom]
RESOLUTION: It is permissible for the proxy to offer the user a restructured desktop presentation on a 'site' by 'site' basis
13:50:47 [dom]
Jo: in 3.1 of the guidelines, we say that the best place to implement user choice of presentation is at the origin server
13:51:16 [dom]
... which comes first? presentation switch on the origin server or in the CT proxy?
13:51:43 [dom]
... so it's probably worth noting that it would be useful to develop that point in BP2
13:53:07 [dom]
ISSUE: Discuss the option to offer choices of presentation as a best practices for mobile web apps
13:53:07 [trackbot]
Created ISSUE-262 - Discuss the option to offer choices of presentation as a best practices for mobile web apps ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/262/edit .
13:55:26 [dom]
Jo: we want to encourage the creation of mobile-friendly content on the origin server, so we probably don't want to promote a practice that would go against that policy
13:58:00 [dom]
SeanP: so you're saying that a CT proxy should have a persistent preference to always get the desktop version?
13:58:59 [dom]
Jo: the complication is that if the user wants a mobile version, and the CT still sends the desktop headers, the user doesn't get what she wants
13:59:18 [dom]
... it raises the question of blanket user preferences
13:59:32 [dom]
SeanP: but that's what most CT do
13:59:59 [dom]
Jo: but is this the expression of a specific user's choice?
14:00:11 [dom]
SeanP: I think in reality is that the operator is making the choice
14:00:31 [dom]
Jo: but is it appropriate? esp. with the mission of the BP in mind
14:01:37 [dom]
... a concern is that if all vendors default to desktop-presentation, this would still be conformant with the guidelines without helping what we want to achieve
14:02:21 [dom]
... so my conclusion that a blanket agreement doesn't constitute a proper expression of user's choice
14:03:32 [dom]
Francois: my concern is, if the user really wants the default desktop-experience, we would forbid him to have this expressed or recorded?
14:04:10 [dom]
Jo: it comes back to a matter of principle
14:04:31 [dom]
... the CP choice must prevail, unless the user specifically expresses it
14:04:49 [DKA1]
PROPOSED RESOLUTION: If both a mobile and a desktop experience are provided by the origin server, the default should be to provide the user with the mobile experience unless the proxy determines that providing the mobile experience will result in a non-functional user experience.
14:09:18 [dom]
SeanP: the way of the CT work now is that they send the desktop headers
14:09:35 [francois]
q+ to talk about power users
14:09:46 [DKA1]
ack francois
14:09:46 [Zakim]
francois, you wanted to talk about power users
14:10:23 [dom]
francois: it's probably true that this would affect very few users (referring to dom's not minuted comment)
14:11:09 [dom]
... it's no big deal if only a few users can't express their preferences if most benefit from it
14:12:09 [dom]
Jo: I'm not sure we should make assumptions about the existing balance - given how rapidly these consideration change
14:13:37 [Kai]
q+ to point out that we need to consider editorial issues when it comes to thinking about content providers views
14:14:19 [DKA1]
ack kai
14:14:19 [Zakim]
Kai, you wanted to point out that we need to consider editorial issues when it comes to thinking about content providers views
14:15:00 [dom]
Kai: editorially speaking, it's sometimes impossible to have a single version adapted to mobile - and creating many versions is expensive
14:15:54 [jo]
PROPOSED RESOLUTION: Blanket expression of user preference for restructured desktop presentation is not consistent with encouraging content providers to build specific mobile user experiences and providing a choice of experience at the origin server
14:17:09 [dom]
... automation is cheap - so leaving the burden on transformation proxy makes economical sense
14:18:17 [dom]
Dom: but there is a different between content transformation proxies and content adaptation engine used by the CP
14:18:26 [dom]
Jo: we should note that distinction in the doc
14:19:41 [jo]
PROPOSED RESOLUTION: Insert into the document a scoping statement that says that a CT proxy is a CT proxy only if it is not under the control of a content provider. One that is in control of the contrnet provider is an adaptation solution and is out of scope
14:21:37 [jo]
PROPOSED RESOLUTION: Insert into the document a scoping statement that says that a CT proxy is a CT proxy only if it is not under the control of a content provider. One that is in control of the contrnet provider is an adaptation solution and is considered to be part of the origin server and is therefore out of scope
14:22:06 [jo]
PROPOSED RESOLUTION: Insert into the document a scoping statement that says that a CT proxy is a CT proxy only if it is not under the control of a content provider. One that is in control of the content provider is an adaptation solution and is considered to be part of the origin server and is therefore out of scope
14:23:53 [dom]
DKA: Vodafone does both - isn't that a bit wishy-washy?
14:29:05 [jo]
PROPOSED RESOLUTION: Insert into the document a scoping statement that says that a proxy is a CT proxy only where no prior arrangement exists between the operator of the proxy and a content provider. One where an arrangement exists with the content provider is an adaptation solution, is considered to be part of the origin server and is therefore out of scope
14:29:32 [DKA1]
+1ish
14:29:47 [rob]
+1
14:29:52 [SeanP]
+1
14:30:57 [jo]
PROPOSED RESOLUTION: Insert into the document a scoping statement that says that a proxy is a CT proxy in scope of this document only where no prior arrangement exists between the operator of the proxy and a content provider. One where an arrangement exists with the content provider is an adaptation solution, is considered to be part of the origin server and is therefore out of scope
14:31:28 [dom]
RESOLUTION: Insert into the document a scoping statement that says that a proxy is a CT proxy in scope of this document only where no prior arrangement exists between the operator of the proxy and a content provider. One where an arrangement exists with the content provider is an adaptation solution, is considered to be part of the origin server and is therefore out of scope
14:31:47 [dom]
PROPOSED RESOLUTION: Blanket expression of user preference for restructured desktop presentation is not consistent with encouraging content providers to build specific mobile user experiences and providing a choice of experience at the origin server
14:31:49 [jo]
PROPOSED RESOLUTION: Blanket expression of user preference for restructured desktop presentation is not consistent with encouraging content providers to build specific mobile user experiences and providing a choice of experience at the origin server
14:32:22 [dom]
+1
14:32:34 [jo]
+1
14:32:38 [SeanP]
0
14:33:13 [DKA1]
+1
14:33:19 [adam]
+1
14:33:59 [dom]
RESOLUTION: Blanket expression of user preference for restructured desktop presentation is not consistent with encouraging content providers to build specific mobile user experiences and providing a choice of experience at the origin server
14:34:11 [dom]
q?
14:34:45 [dom]
s/<dom> RESO/<dom> PROPOSED RESO/
14:34:52 [dom]
RRSAgent, draft minutes
14:34:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/06/16-bpwg-minutes.html dom
14:35:39 [dom]
Jo: a possible simple fix would to insert simply a note in the document that states this
14:35:57 [dom]
francois: and remove the part that allows to always request the desktop version
14:36:00 [dom]
jo: right
14:36:11 [jo]
(and remove section 3.3)
14:36:39 [dom]
... otherwise, we can require this to be made on a case by case basis
14:37:02 [dom]
... a further choice would be to say that when a CP provides the choice, this should override the blanket agreement
14:37:16 [dom]
Kai: why this would override the choice of the user?
14:37:22 [jo]
s/3.3/3.2.3/
14:37:31 [dom]
Jo: the choice the user has expressed is with the CT, not with the CP
14:37:42 [edm]
edm has joined #bpwg
14:37:47 [dom]
SeanP: I would disagree with such a proposal - we have plenty of requests for this
14:38:15 [dom]
Jo: but the user doesn't really care whether the desktop version comes from the CT or the CP
14:39:06 [dom]
DKA: we need to consider the point of encouraging content providers to create mobile friendly content
14:39:23 [dom]
... these rules need to be consistent with that overall set of goals
14:39:49 [dom]
... also, this task force was kicked off in reaction to the call from content providers to have more control and visibility in the proxy layer
14:40:04 [dom]
... so I think we should be erring on the side of what Jo proposed
14:41:25 [rob]
q+ to say that site-by-site opt-in to restructuring desktop editions could also prevent thos sites from subsequently getting a mobile-friendly edition to the user
14:41:35 [DKA1]
q?
14:41:47 [DKA1]
ack rob
14:41:47 [Zakim]
rob, you wanted to say that site-by-site opt-in to restructuring desktop editions could also prevent thos sites from subsequently getting a mobile-friendly edition to the user
14:42:37 [dom]
Jo: we need to reconcile the need from the users (e.g. always wanting the desktop version), from the needs of CP to control what is served
14:42:38 [dom]
ack rob
14:43:03 [dom]
Rob: site-by-site opt-in to restructuring desktop editions could also prevent those sites from subsequently getting a mobile-friendly edition to the user
14:44:26 [dom]
Rob: I think default is less an issue than the fact that you can change your mind
14:44:36 [dom]
DKA: but most users just don't know anything about this
14:44:49 [dom]
... so we're talking about making decisions for users
14:45:48 [dom]
... with a blanket preference, as a new user, I wouldn't ever know that there may be a mobile version of a given site
14:46:10 [dom]
SeanP: there would probably be a link, though
14:46:21 [dom]
DKA: (which is what Jo raised as an issue for BP2)
14:46:39 [dom]
SeanP: if you disallow blanket preferences for Desktop-version, you run the risk of people not following the guidelines
14:48:13 [dom]
Dom: what about requiring a CT proxy that relies on a user preference to always get the desktop version to have a link to get the mobile version served by the site?
14:48:19 [dom]
Kai: what about the other way around?
14:48:57 [dom]
DKA: or more generally speaking, when a CT proxy does transformation, requiring that it puts a link to the "other mode" of the site?
14:49:17 [dom]
... In vodafone, lots of the discussions about the default depends on the device the user has
14:50:20 [jo]
PROPOSED RESOLUTION: Put a pin in this discussion noting that the questions that remain to be resolved are:
14:50:22 [jo]
a. how the CT proxy should react against specific user preferences when a site becomes more capable
14:50:23 [jo]
b. that the default experience should be for the mobile experience
14:50:25 [jo]
c. that blanket expression of preferences should be interpreted in the context that if an origin server can provide a choice of experience then it should do so
14:50:26 [jo]
d. that CT proxies should, in restructured content, proivide links to alternative representations
14:52:27 [dom]
Jo: I agree with Rob's point that the user should be alerted when a site changes and becomes mobile-friendly if she had expressed a preference for that site before
14:54:13 [jo]
e. how would a CP indicate to a CT Proxy that it offers user choice of representation?
14:55:30 [DKA1]
PROPOSED RESOLUTION: if there is a blanket user preference asserted for desktop presentation and multiple representations are found to exist then the CT proxy server SHOULD prompt the user to inform them of this and ask the user which representation they want to view.
14:57:24 [DKA1]
PROPOSED RESOLUTION: if there is a blanket user preference asserted for desktop presentation and multiple representations are found to exist then the CT proxy server SHOULD inform the user of this fact and provide the user with an option to change the representation.
14:57:35 [jo]
PROPOSED RESOLUTION: if there is a blanket user preference asserted for desktop presentation and multiple representations are found to exist then the CT proxy server SHOULD make the user aware of it and provide the user with the option to change the represntataion
14:57:57 [DKA1]
PROPOSED RESOLUTION: if there is a blanket user preference asserted for any specific presentation option and multiple representations are found to exist then the CT proxy server SHOULD inform the user of this fact and provide the user with an option to change the representation.
14:58:07 [DKA1]
PROPOSED RESOLUTION: if there is a blanket user preference asserted for any specific representation option and multiple representations are found to exist then the CT proxy server SHOULD inform the user of this fact and provide the user with an option to change the representation.
14:58:59 [DKA1]
PROPOSED RESOLUTION: if there is a blanket user preference asserted for any specific representation option and multiple representations are found to exist then the CT proxy server SHOULD inform the user of this fact and provide the user with an option to change to one of the alternative representations.
15:03:22 [dom]
Adam: this seems to be making the document much more complex
15:03:31 [dom]
... I wonder if we shouldn't stay silent on this
15:05:59 [DKA1]
PROPOSED RESOLUTION: We remain silent on the issue of what explicit prior user consent consists of.
15:06:44 [dom]
Jo: the key question is the level of user expression consent
15:07:03 [dom]
Dom: agree; once the user has sufficiently agreed to it, the ct proxy becomes part of the user-agent
15:07:20 [dom]
... (e.g. a user could use a user-defined proxy to do the transformations he deems necessary)
15:08:23 [dom]
[discussions on no-transform]
15:08:42 [dom]
SeanP: one problem with no-transform is that ct proxies still want to add headers/footers or rewrite links
15:08:49 [dom]
... even if the content is set to no-transform
15:10:24 [dom]
Dom: I think that whether this is going to be implemented or not is a different discussion on whether it should be or not
15:10:40 [dom]
... maybe not all vendors will apply this, but that doesn't change the fact that we might think this is a good thing
15:11:03 [dom]
DKA: as an operator, we may actually want to have these changes as a longer term goal
15:12:02 [DKA1]
PROPOSED RESOLUTION: if there is a blanket user preference asserted for any specific representation option and multiple representations are found to exist then the CT proxy server SHOULD inform the user of this fact and provide the user with an option to change to one of the alternative representations.
15:12:38 [dom]
RESOLUTION: if there is a blanket user preference asserted for any specific representation option and multiple representations are found to exist then the CT proxy server SHOULD inform the user of this fact and provide the user with an option to change to one of the alternative representations.
15:13:22 [dom]
DKA: I think we need to strengthen the clauses around "no-transform"
15:16:11 [dom]
Rob: when rewriting urls, if one of the links link to a no-transform site, what do you do?
15:16:21 [dom]
dom: you could redirect there instead of rewriting?
15:16:31 [jo]
PROPOSED RESOLUTION: For no-transform responses and for https change text referring to "express user choice" to mean "case by case choice"
15:19:33 [DKA1]
PROPOSED RESOLUTION: In the context of tasting content, if header comes back as cache-control no-transform, then CT proxies SHOULD change to transparent proxy operation.
15:19:49 [DKA1]
PROPOSED RESOLUTION: I
15:20:06 [DKA1]
PROPOSED RESOLUTION: remain silent on all other issues
15:20:42 [francois]
ScribeNick: dom
15:20:47 [francois]
ScribeNick: francois
15:21:39 [francois]
DKA: can we exclude visible header/footers from our discussion?
15:21:52 [francois]
SeanP: Well, the other issue is URI rewriting
15:23:12 [francois]
DKA: I don't think that's a problem.
15:23:35 [DKA1]
PROPOSED RESOLUTION: no means no
15:23:57 [francois]
... If a site is precisely tailored for a specific device, then it takes into account width and screen of the device, and adding link would mess with the representation
15:24:24 [francois]
Kai: support that Cache-Control: no-transform needs to be a strong statement
15:25:10 [francois]
Rob: OK, but I still point that URI rewriting is a problem
15:25:20 [francois]
francois: redirect doesn't solve the problem?
15:25:44 [francois]
rob: probably, but not in all cases. [explanation on a case missed by the scribe]
15:25:56 [DKA1]
PROPOSED RESOLUTION: In the context of tasting content, if header comes back as cache-control no-transform, then CT proxies SHOULD change to transparent proxy operation (e.g. sending a http redirect).
15:26:46 [francois]
Jo: I don't think we need to write this, because we already say that the proxy SHOULD be transparent "unless".
15:27:26 [jo]
+1
15:27:27 [francois]
... I don't particularly object to your resolution though.
15:27:33 [francois]
... Agree we need to be clear.
15:28:42 [francois]
RESOLUTION: In the context of tasting content, if header comes back as cache-control no-transform, then CT proxies SHOULD change to transparent proxy operation (e.g. sending a http redirect)
15:29:09 [jo]
PROPOSED RESOLUTION: For no-transform responses and for https change text referring to "express user choice" to mean "case by case choice"
15:29:16 [francois]
DKA: next proposed resolution to resolve the issue within the next half hour?
15:29:20 [rob]
s/[explanation on a case missed by the scribe]/There could be cases where various proxies in the path would proxy the HTTP 302 redirect back to the CT-proxy again. But this is only a technical problem to overcome, not a reason to not specify best-practise./
15:29:23 [achuter]
achuter has joined #bpwg
15:30:41 [francois]
DKA: does that not imply that the user will be repeatedly prompted with security warnings?
15:31:13 [francois]
jo: the point is that blanket expression of user preferences should not be used here.
15:32:42 [francois]
rob: insertion of a warning header by the CT-proxy in the page is enough?
15:33:09 [francois]
francois: no, the CT-proxy must not start transformation of HTTPS content without the agreement of the user
15:33:26 [francois]
... same thing with HTTPS links within HTTP pages
15:34:22 [francois]
SeanP: Can the proxy keep the user's choice for the web site?
15:35:12 [francois]
DKA: yes, it would be the middle ground between blanket and case by case. The user could be given different choices: only for this page, for the site, ...
15:35:33 [francois]
... but that may be going too far in prescribing how the CT-proxy may behave
15:35:48 [francois]
Dom: I don't think we need to be explicit about that
15:37:29 [francois]
francois: I note that what is in the guidelines for HTTPS rewriting is already the result of such a discussion on how to rephrase it so that we stay on this middle ground
15:38:01 [francois]
DKA: OK, can we translate the HTTPS part to the Cache-Control: no-transform directive?
15:39:55 [achuter]
achuter has joined #bpwg
15:40:18 [jo]
PROPOSED RESOLUTION: If the response includes a Cache-Control: no-transform directive then the response must remain unaltered other than to comply with transparent HTTP behavior and other than as noted below. If the proxy determines that the resource as currently represented is likely to cause serious mis-operation of the user agent then it may advise the user that this is the case and must...
15:40:20 [jo]
...provide the option for the user to continue with unaltered content.
15:41:59 [jo]
PROPOSED RESOLUTION: If the response includes a Cache-Control: no-transform directive then the response must remain unaltered other than to comply with transparent HTTP behavior and other than as follows. If the proxy determines that the resource as currently represented is likely to cause serious mis-operation of the user agent then it may advise the user that this is the case and must...
15:42:00 [jo]
...provide the option for the user to continue with unaltered content.
15:45:03 [francois]
DKA: Should we lower the statement: "If the proxy knows better"
15:45:06 [francois]
... ?
15:46:01 [francois]
francois: I don't think so. The response that is being altered may not be designed to be displayed directly to the user. It could be the result of an AJAX call for instance. I still support a strong Cache-Control: no-transform directive.
15:46:20 [francois]
... Adding an interstitial response would break existing content
15:46:28 [DKA1]
+1
15:47:32 [francois]
DKA: I suggest that we move forward on this resolution, and that we use the Last Call period to get feedback from CT vendors and Content Providers. I suggest we use the Last Call to poll feedback.
15:49:20 [jo]
a. how the CT proxy should react against specific user preferences when a site becomes more capable
15:49:22 [jo]
b. that the default experience should be for the mobile experience
15:49:23 [jo]
c. that blanket expression of preferences should be interpreted in the context that if an origin server can provide a choice of experience then it should do so
15:49:25 [jo]
d. that CT proxies should, in restructured content, proivide links to alternative representations
15:49:26 [jo]
e. how would a CP indicate to a CT Proxy that it offers user choice of representation?
15:49:28 [jo]
f. allow users to change previosuly expressed preferences
15:49:35 [francois]
francois: agree with the resolution, although I don't see the difference with what we already have in there.
15:50:06 [francois]
RESOLUTION: If the response includes a Cache-Control: no-transform directive then the response must remain unaltered other than to comply with transparent HTTP behavior and other than as follows. If the proxy determines that the resource as currently represented is likely to cause serious mis-operation of the user agent then it may advise the user that this is the case and must .provide the option for the user to continue with unaltered content.
15:50:24 [francois]
DKA: Another resolution we can take in the remaining 10mn?
15:50:38 [francois]
Jo: [going through the above list]
15:51:50 [francois]
... On point e: we already resolved on the use of the Link element with some reference somewhere in the document. Now we need the following:
15:52:03 [jo]
PROPOSED RESOLUTION: If the server has alternative representations then it should indicate this using link header/elements
15:52:17 [DKA1]
+1
15:52:23 [rob]
+1
15:52:41 [francois]
Kai: What about POWDER?
15:52:59 [francois]
RESOLUTION: If the server has alternative representations then it should indicate this using link header/elements
15:53:56 [francois]
Jo: Then, how does a Content Provider advertise the fact that it proposes a choice to the end user between a desktop and a mobile representation?
15:54:03 [francois]
dom: I think we should leave that as heuristics
15:54:49 [francois]
jo: Overall, my feeling is that we're not going to make more progress on this subject today...
15:55:15 [francois]
Kai: would appreciate if resolutions were not taken that quickly, especially when I have questions on the matter.
15:57:12 [francois]
francois: summary of where we are re. CT?
15:57:40 [francois]
... I think we need to think carefully about it. It involves complete rewriting of 3.2 in my view.
15:57:58 [francois]
jo: I'd say the whole section should disappear.
15:58:19 [francois]
... Well have to wait for the new draft and see where the direction goes.
15:59:05 [francois]
Topic: A quick look on the agenda
15:59:07 [francois]
DKA: On the agenda, I don't want to move the points we missed this afternoon to tomorrow morning
15:59:45 [francois]
... I suggest that in order of priority that we move these discussions into early afternoon on Wednesday.
15:59:51 [francois]
Jo: I think that's fine.
16:00:27 [francois]
DKA: Session adjourned
16:00:29 [Sunghan]
Sunghan has left #bpwg
16:00:29 [dom]
RRSAgent, draft minutes
16:00:29 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/06/16-bpwg-minutes.html dom
16:00:56 [Kai]
Kai has left #bpwg
16:02:56 [rob]
rob has left #bpwg
17:05:46 [Zakim]
Zakim has left #bpwg