IRC log of bpwg on 2008-07-08

Timestamps are in UTC.

13:55:50 [RRSAgent]
RRSAgent has joined #bpwg
13:55:50 [RRSAgent]
logging to http://www.w3.org/2008/07/08-bpwg-irc
13:55:52 [trackbot]
RRSAgent, make logs public
13:55:52 [Zakim]
Zakim has joined #bpwg
13:55:54 [trackbot]
Zakim, this will be BPWG
13:55:54 [Zakim]
ok, trackbot; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 5 minutes
13:55:55 [trackbot]
Meeting: Mobile Web Best Practices Working Group Teleconference
13:55:55 [trackbot]
Date: 08 July 2008
13:56:02 [francois]
Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0003.html
13:56:06 [francois]
Chair: francois
13:56:26 [francois]
Regrets: Pontus, AndrewS
14:00:24 [rob]
rob has joined #bpwg
14:01:35 [Zakim]
MWI_BPWG(CTTF)10:00AM has now started
14:01:36 [jo]
jo has joined #bpwg
14:01:42 [Zakim]
+hgerlach
14:01:57 [jo]
zakim, code?
14:01:57 [Zakim]
the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), jo
14:02:19 [Zakim]
+rob
14:02:36 [hgerlach]
hgerlach has joined #bpwg
14:02:37 [SeanP]
SeanP has joined #bpwg
14:02:54 [Zakim]
+jo
14:03:10 [Zakim]
+Francois
14:05:18 [jo]
rrsagent, draft minutes
14:05:18 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/07/08-bpwg-minutes.html jo
14:05:39 [francois]
Regrets+ Bryan
14:06:20 [jo]
zakim, who is here?
14:06:20 [Zakim]
On the phone I see hgerlach, rob, jo, Francois
14:06:22 [Zakim]
On IRC I see SeanP, hgerlach, jo, rob, Zakim, RRSAgent, francois, trackbot, dom, matt2MIT
14:06:27 [Zakim]
+SeanP
14:07:26 [jo]
scribe: jo
14:08:12 [jo]
Topic: Blaming Jo for Incredible Delays
14:08:55 [jo]
s/Blaming Jo for Incredible Delays/Allow and Disallow Lists
14:09:25 [jo]
francois: I summarized the choices as I see them in the agenda, and I was wondering if this is a good picture
14:09:53 [jo]
... we should wait for the new draft before deciding unless we can come up with a clear consensus now
14:10:03 [jo]
... we have three choices (as discussed in the agenda)
14:11:22 [jo]
... my personal preference would be for b), but are there any other points of view to take into account?
14:11:26 [jo]
q+
14:11:35 [hgerlach]
q+
14:11:39 [francois]
ack jo
14:12:31 [francois]
jo: I think we can step around this one actually, either with "unspecified means", either by saying "prior interaction with the server"
14:12:44 [francois]
... and then we can then leave that open
14:13:56 [francois]
... The important thing is IMO that the so-called algorithm is self-healing, and if we keep it this way, we don't really need to go in the like/don't like allow/disallow lists discussion
14:15:20 [jo]
jo: I think we can avoid referring to specific internal mechansims by referring tot he notion of p"previous experience" and "a priori" knowledege, providing that the algorithm makes it plain that no matter what the proxy thinks it knows, but whatever means it thinks it knows it, it must act on the evidence that is presented by the server first and formost
14:15:37 [jo]
s/formost/foremost/
14:17:05 [francois]
ack hgerlach
14:17:18 [jo]
... we can gain consensus hopefully by focussing on mitigating the undesirable effects without prohibiting the use of them
14:17:40 [SeanP]
q+
14:17:42 [jo]
heiko: two issues here ...
14:18:35 [jo]
... role of allow and disallow list is one question, the other question is setting up an allow list for setting up a different user agent string
14:19:08 [jo]
... the first issue is allow or disallow transformation the second is allow or disallow bogus user agent headers
14:19:25 [jo]
francois: but not mentioning them surely avoids the issue
14:20:06 [jo]
heiko: if you are allowed to bypass this is a different issue to no-transform
14:20:22 [jo]
... we need to think about what we are allowing or disallowinging
14:20:40 [jo]
s/disallowinging/disallowing/
14:21:16 [jo]
francois: allow lists to discuss the possibility of sending altered headers
14:21:50 [jo]
... and the second to allow overriding cache control, two different uses of the list
14:22:19 [jo]
q+ to say that as a point of principle one should avoid mentioning internal mechanisms that are proprietary to the proxy
14:22:29 [francois]
ack SeanP
14:23:22 [jo]
seanp: one issue with b) is that it deals only with the response whereas one would need to look at such lists on the request
14:23:36 [jo]
... there may be a disconnect as to what people are using such lists for now
14:23:48 [jo]
... so if we mention at all we should make this clear
14:24:25 [jo]
francois: actually I think b) only deals with the HTTP request to know if you have to send another one
14:24:41 [hgerlach]
sorry I got a 2nd call will be back soon
14:25:22 [jo]
seanp: if you have allow list you can send altered headers straight away
14:25:34 [jo]
... you are saying that is the prior knowledge
14:26:16 [jo]
francois: the point jo emphasised it that it makes sense to send altered headers straight way but it needs refeeshing from time to time
14:26:33 [jo]
s/refeeshing/refreshing/
14:26:39 [jo]
... it really depends
14:27:27 [jo]
... ithink we should postpone the decision till we see the new document
14:27:31 [francois]
ack jo
14:27:31 [Zakim]
jo, you wanted to say that as a point of principle one should avoid mentioning internal mechanisms that are proprietary to the proxy
14:28:59 [francois]
jo: Allow/Disallow are not really externally visible, so we should not step into the behavior of the Proxy, and not mention them. You can infer that there are such lists. Forms that users may fill are not within scope of this specification.
14:29:34 [jo]
s/Forms that users may fill are not within scope of this specification./we deal with the interactions between the server and the proxy
14:29:50 [jo]
francois: suggest we leave it and move on
14:30:18 [jo]
Topic: Persistent Expression of User Preferences
14:30:29 [francois]
-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0002.html Jo's points commented by Sean and me
14:31:12 [jo]
q+ to say that the algorithm referred to above should help with this too
14:31:26 [francois]
ack jo
14:31:26 [Zakim]
jo, you wanted to say that the algorithm referred to above should help with this too
14:33:31 [francois]
jo: Thinks that it is linked to the algorithm. If we're clever, I guess we'll say that the proxy should prompt the user again when the response from the server differs from the previous one.
14:33:49 [francois]
... a bit woolly but we cannot do any better, I think.
14:34:33 [jo]
jo: I think that the key point is that when a user has a persistent expression of preference we want to make sure that if a host changes its operation the user gets the chance to re-express their preferences
14:35:07 [jo]
... and this requires the proxy maintain some kind of "prior knowledge"
14:36:47 [jo]
francois: seanp can you clarify something from your email ... the origin server can tell that the request has passed through the CT proxy, if it changes its operation it can tell the CT proxy this by sending a 406 status with a vary header
14:37:21 [jo]
seanp: basically the origin server can tell ... by looking at the X-Headers
14:37:51 [jo]
... so it can determine that the server now does not want the CT proxy to do transformation any more
14:38:12 [jo]
... so the CT proxy will know to not do transformation for that site any more
14:38:40 [jo]
... I thought tha was why we had the point under 4.3 in here
14:38:52 [jo]
francois: {mumbles}
14:39:29 [jo]
seanp: origin server can tell that it is going through a proxy so what we need is for the origin server to show that is is now aware
14:40:10 [jo]
... couple of cases one where is was aware and changes its mind, and the other is that it wasn't aware and now doesn't want transformation
14:40:53 [jo]
francois: there we are using the response from the server as a direct communication with the proxy rather than having end-to-end significance
14:41:19 [jo]
... the problem is that the 406 is not intended for the end-users
14:41:38 [jo]
seanp: but surely that's what we do when it works the other way round
14:42:01 [jo]
francois: but in that case it really is saying "I can't handle your device"
14:42:18 [jo]
... in your illustration its the server telling the proxy to change its ways
14:42:32 [jo]
seanp: sure but the practical results are the same
14:42:33 [jo]
q+
14:42:39 [francois]
ack jo
14:44:02 [jo]
jo: not sure that what Seanp proposed doesn't require the server to know about tasting and prior requests, hope we can sweep this all together in a new draft
14:44:19 [jo]
... I have put a placeholder for illustrations of interactions
14:44:32 [jo]
... so we can make sure we have tested this all out
14:44:54 [jo]
francois: anything else we need to sweep up
14:45:12 [jo]
... trciky part is about cps that offer users a choice of representation
14:45:34 [jo]
.. and how to tell proxy that they are handling the choice themselves
14:46:11 [jo]
... don't know if there are any technical possibilities, not sure we can decorate this any further
14:46:19 [jo]
... anyone got a view on that?
14:46:44 [jo]
jo: think that this is a problem and am hoping to find an answer!
14:46:46 [hgerlach]
+1
14:46:51 [hgerlach]
q+
14:46:57 [francois]
ack hgerlach
14:47:11 [jo]
francois: clarifying that it's best practice for the server to offer such a choice
14:47:38 [jo]
heiko: server can offer a menu offering choices
14:47:56 [jo]
.. but this will require an additional database
14:48:14 [jo]
... e.g. how to determine that there is a .mobi page for something that is not in the .mobi domain
14:48:28 [jo]
francois: can advertise via the linkelement
14:48:46 [jo]
heiko: how can can the proxy know that the pages exist
14:49:09 [jo]
... how do they know where the mobile page is
14:50:02 [jo]
francois: there are two things, the server can already tell the proxy that such pages exist using the link element, but the difficulty is telling the proxy that they also offer that choice in a user visible way
14:50:58 [jo]
... there are a number of problems, e.g. that this may offer this at a site level, could be POWDER, but that is scope for future work
14:51:27 [jo]
heiko: no there can be a database for that purpose even if the site owner has not set this information?
14:51:45 [jo]
francois: what kind of database?
14:51:55 [jo]
heiko: well there is the .mobi database
14:52:18 [jo]
francois: the ct proxy could consult such a database?
14:52:22 [jo]
heiko: yes
14:52:28 [SeanP]
q+
14:52:40 [jo]
q+ to say that databases are out of scope
14:53:05 [jo]
francois: there is no fixed relationship between domain names
14:53:07 [francois]
ack SeanP
14:53:38 [jo]
seanp: there is lots of way to map between mobile sites and desktop sites and mobile sites and vice versa
14:53:50 [jo]
... so this seems like a CT vendor issue
14:54:16 [jo]
... if the page doesn't contain the issue then its a CT vendor issue
14:54:48 [francois]
ack jo
14:54:48 [Zakim]
jo, you wanted to say that databases are out of scope
14:54:52 [jo]
... there are a million different ways of doing this, no algoritm as such
14:54:55 [jo]
ack me
14:55:32 [francois]
jo: out of scope, since we're talking about using HTTP. We should not refer specifically to any specific implementation mechanisms
14:55:51 [jo]
jo: we shouldn't refer specifically to particular implementation mechanisms
14:56:51 [jo]
francois: final issue ... CT proxies providing links to alternative representations ... I did include a Proposed Resolution, in the agenda but let's leave that one too
14:57:03 [jo]
... for the time being
14:58:29 [jo]
jo: hope to have new draft by tomorrow or by thursday
14:59:02 [francois]
jo: I'm halfway through the document, we may have an update
14:59:13 [francois]
s/jo: I'm halfway through the document, we may have an update//
14:59:37 [hgerlach]
-1 bye
14:59:45 [Zakim]
-hgerlach
14:59:56 [Zakim]
-jo
14:59:57 [Zakim]
-SeanP
14:59:57 [Zakim]
-rob
14:59:59 [Zakim]
-Francois
14:59:59 [Zakim]
MWI_BPWG(CTTF)10:00AM has ended
15:00:00 [Zakim]
Attendees were hgerlach, rob, jo, Francois, SeanP
15:00:57 [jo]
rrsagent, draft minutes
15:00:57 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/07/08-bpwg-minutes.html jo
15:27:30 [rob]
rob has left #bpwg
15:32:13 [francois]
RRSAgent, bye
15:32:13 [RRSAgent]
I see no action items