IRC log of bpwg on 2008-03-03

Timestamps are in UTC.

00:20:56 [RRSAgent]
RRSAgent has joined #bpwg
00:20:56 [RRSAgent]
logging to
00:21:00 [Zakim]
Zakim has joined #bpwg
00:21:54 [DKA]
SL: First time having a W3C meeting in Korea.
00:21:58 [Rotan]
Rotan has joined #bpwg
00:26:33 [francois]
Meeting: BPWG F2F Seoul - 1st day
00:26:56 [francois]
Chair: DKA, Jo
00:27:19 [jcantera]
jcantera has joined #bpwg
00:27:44 [wonsuk]
wonsuk has joined #bpwg
00:28:11 [francois]
Date: 3 March 2008
00:32:16 [DKA]
scribenick: bryan
00:32:24 [DKA]
Topic: Agenda
00:34:05 [Bryan]
DKA: for BP2, propose to use the sessions for live editing
00:34:47 [Bryan]
DKA: BP2 will likely spill over to 2nd day
00:35:26 [Bryan]
DKA: any other changes to agenda?
00:37:37 [Bryan]
Jo: the accessibility doc review may be difficult with Alan missing; we might reuse that time for the other agenda items. Also MobileOK TF is not represented, so BP2 could continue.
00:38:01 [francois]
Present: DKA, Jo, MartinJ, jcantera, rob, SeanP, Bryan, francois, wonsuk, JonathanJ, SeungyunLee, KangchanLee
00:40:35 [francois]
Present+ Minkyo
00:41:10 [JonathanJ]
00:41:13 [francois]
Present+ SungHan
00:41:26 [MartinJ]
00:41:42 [Kangchan]
Present+ Soonho_Lee
00:42:02 [Bryan]
Topic: CT Taskforce
00:42:32 [JonathanJ]
00:42:40 [francois]
-> CT draft
00:43:11 [Bryan]
Francois: update on the status, overview of goals
00:45:03 [Bryan]
Francois: some CT proxies have been deployed in the market, to enable whole web access from mobile devices; problems are lack of consistent rules, and CP's complained
00:45:26 [Bryan]
Francois: So W3C started a program to set expectations on CT proxy behavior
00:46:16 [Bryan]
Francois: After a year, we need decisions, e.g. on the scope re use of new technologies e.g. new HTTP headers
00:47:10 [Bryan]
Francois: CT will probably need more flexible ways in the future, so we decided to stick to existing technologies. Thus the current draft we are reviewing.
00:48:28 [Bryan]
Francois: "Summary of requirements" section is an overview for all entities in the delivery chain.
00:49:16 [Bryan]
Francois: An assumption is that legacy browsers are used, thus the user (and not user-agent) is in the loop for any controls of CT behavior.
00:49:23 [jo]
[note to editor to correct section 2.1 where it says HTTP between user and user agent
00:49:38 [jo]
thanks to DKA and francois for pointing this out!]
00:50:11 [Bryan]
Francois: So the requirements are a little outdated, with the current scope, and cannot be fulfilled with current technologies. But it is a good hint for the future.
00:50:55 [DKA]
00:51:04 [Bryan]
Francois: "Types of Proxy" are what HTTP defines, included here to establish the terms.
00:51:52 [Bryan]
Jo: Wonders if we can revisit the decision on the CT entity being a "proxy".
00:52:10 [jo]
[the proxy is indeed a proxy not a user agent extension or a gateway]
00:52:29 [SeanP]
00:52:44 [DKA]
00:53:07 [DKA]
ack seanp
00:53:27 [Bryan]
Francois: We do not view the CT proxy as an user-agent extension (masquerader), but as a simple intermediary.
00:53:41 [jo]
00:53:50 [DKA]
ack j
00:53:59 [Bryan]
Sean: Are we leaving the specialized client/'server solutions e.g. Opera Mini, out of the scope of these guidelines?
00:54:49 [Bryan]
Jo: We are addressing how HTTP path entities should behave.
00:55:10 [DKA]
q+ to suggest it is out of scope
00:55:14 [Bryan]
Francois: We could consider Opera Mini as two different parts.
00:55:16 [Bryan]
00:55:19 [SeanP]
00:55:34 [Bryan]
Francois: Opera Mini is both.
00:56:03 [jo]
q+ to suggest that we need to make reference to the principles, which are to facilitate the communication between the user and the content provider
00:56:04 [Bryan]
Dan: It is a different animal, an integrated system built in a special way.
00:56:09 [DKA]
00:56:09 [jo]
ack d
00:56:10 [Zakim]
DKA, you wanted to suggest it is out of scope
00:56:14 [DKA]
ack br
00:56:19 [DKA]
00:56:23 [DKA]
00:56:25 [DKA]
00:56:27 [DKA]
jo beep
00:56:54 [jo]
q+ to add that we should raise an issue on this and askOpera
00:57:05 [DKA]
00:57:07 [DKA]
ack seanp
00:57:14 [jo]
q+ to add that there is something about user choice of user agent
00:57:17 [Bryan]
Bryan: Opera Mini is an application with specialized behavior, and does not necessarily use HTTP.
00:57:53 [DKA]
00:57:56 [DKA]
ack jo
00:57:56 [Zakim]
jo, you wanted to suggest that we need to make reference to the principles, which are to facilitate the communication between the user and the content provider and to add that we
00:57:59 [Zakim]
... should raise an issue on this and askOpera and to add that there is something about user choice of user agent
00:58:17 [Bryan]
Sean: It does operate different from normal browsers, and does appear to use something other than HTTP. But Novarra has similar experience with clients that do use HTTP.
00:59:04 [Bryan]
Jo: We should ask Chaals about his attitude on this.
00:59:37 [DKA]
01:00:04 [Bryan]
Jo: We could get distracted by considering all the types of solutions, and if we consider on the normal proxy, we can focus on the case where the user has not made an active choice (e.g. to use an specialized browser).
01:00:08 [DKA]
ack jcantera
01:00:14 [jo]
01:00:20 [jo]
01:00:48 [sylee]
sylee has joined #bpwg
01:00:58 [SeanP]
01:00:59 [jo]
ACTION: Patterson to raise and issue on the distinction between a CT proxy and (say) Opera Mini
01:00:59 [trackbot-ng]
Created ACTION-678 - Raise and issue on the distinction between a CT proxy and (say) Opera Mini [on Sean Patterson - due 2008-03-10].
01:01:00 [Bryan]
Jose: Guidelines of the CT TF should cover all the cases including specialized cases and normal browsers.
01:01:14 [francois_]
francois_ has joined #bpwg
01:01:19 [jo]
01:01:26 [Bryan]
Jo: Doesn't disagree, just wants to discuss it later.
01:01:41 [jo]
ack s
01:01:43 [Bryan]
01:01:56 [DKA]
01:01:59 [DKA]
ack br
01:01:59 [jo]
ack b
01:02:33 [francois_]
RRSAgent, draft minutes
01:02:33 [RRSAgent]
I have made the request to generate francois_
01:03:21 [Bryan]
Bryan: Thinks that some usability aspects will be useful nonetheless even if we don't address any client-server enhancements e.g. that are enabled by HTTP extensions.
01:05:06 [Bryan]
Francois: Going on to "control by the user", re ability of client to use "no-transform" directive to control the CT proxy behavior. This is a limited control that new browsers could leverage.
01:06:52 [Bryan]
Jo: Back on 2.4 ("types of transformation"), suggests that we clarify the scope to avoid giving mixed messages on what a proxy should/should-not do.
01:08:09 [Bryan]
Francois: We don't mention those special types of transformation later.
01:09:06 [jo]
[jo points out that this has gone from the document for now, but is likely to come back in the form of POWDER descriptions]
01:09:10 [Bryan]
Francois: For the moment we don't have any guidelines on how to use particular types of special transformation. We might link the transformations to other documents later on.
01:09:49 [Bryan]
Francois: Leaving "controlled by the server" as is for the time being.
01:10:35 [SeanP]
01:10:41 [DKA]
01:10:55 [Bryan]
Francois: In Section 3, the most common control is to use "no-transform" to affect CT proxy behavior.
01:11:18 [SeanP]
01:11:19 [jo]
01:11:50 [DKA]
ack jo
01:12:00 [Bryan]
Francois: We can't expect this from legacy browsers, but there could be out-of-band arrangements to control the behavior.
01:12:49 [Bryan]
Jo: Re section 3.1.1, we have an issue for the CT proxy to act transparently for non-browsers.
01:12:59 [Bryan]
01:13:05 [DKA]
ack bryan
01:13:14 [RH]
RH has joined #bpwg
01:13:41 [MartinJ]
01:14:02 [DKA]
01:14:10 [rob]
01:14:13 [DKA]
ack martin
01:14:22 [SeanP]
01:14:35 [DKA]
01:14:37 [Bryan]
Bryan: Use of proxies for non-browsers is a common deployment, and must be addressed.
01:15:26 [Bryan]
Martin: the guidelines should be firmer, and stated such that the CT proxy should be transparent unless it can be sure that the user agent is a browser, e.g. using user-agent lists.
01:15:30 [DKA]
ack rob
01:15:37 [DKA]
01:15:54 [jo]
q+ to suggest that Martin
01:16:06 [DKA]
ack seanp
01:16:19 [jo]
q+ to add should take an action to express his point as a proposed text
01:16:19 [DKA]
01:16:26 [Bryan]
Robert: Its a difficult problem, but does need to be addressed since all HTTP is likely going thru the proxy.
01:17:05 [DKA]
ack jo
01:17:05 [Zakim]
jo, you wanted to suggest that Martin and to add should take an action to express his point as a proposed text
01:17:38 [MartinJ]
ACTION: Martin to propose text re browser identification: para 2 of sectio 3.1.1
01:17:38 [trackbot-ng]
Sorry, amibiguous username (more than one match) - Martin
01:17:38 [trackbot-ng]
Try using a different identifier, such as family name or username (eg. mharris2, mjones4)
01:17:49 [Bryan]
Jo: Suggests that Martin take an action to propose text for 3.1.1 based upon the discussion,
01:17:49 [DKA]
01:18:06 [jo]
ACTION: Jones to propose text for para 2 of 3.1.1
01:18:06 [trackbot-ng]
Created ACTION-679 - Propose text for para 2 of 3.1.1 [on Martin Jones - due 2008-03-10].
01:18:58 [Bryan]
Francois: Moving on to 3.1.2 "proxy decision to transform", these are the ways the proxy can know what to do.
01:19:51 [Bryan]
Jo: As editor, unclear how to take the section forward.
01:20:04 [rob]
01:20:24 [Bryan]
Francois: It's just a collection of options on how to control the behavior.
01:20:26 [DKA]
ack rob
01:21:08 [Bryan]
Rob: It's a SHOULD, thus there is a list of things to consider, and the overall is helpful.
01:21:55 [minkyo]
minkyo has joined #bpwg
01:22:36 [SeanP]
01:23:29 [jo]
01:23:51 [Bryan]
Francois: About the editorial note, its similar to what we would write if we were considering the browser extension role for the CT proxy.
01:24:17 [francois_]
ack SeanP
01:24:20 [francois_]
ack jo
01:24:52 [Bryan]
Sean: What was intended by the call comment that prompted the note, was that the user may want a specialized adaptation of the desktop content.
01:25:01 [DKA]
01:26:18 [Bryan]
Jo: Not altering the headers is mandated unless its essential to what the user wanted.
01:26:25 [SeanP]
01:26:40 [DKA]
ack se
01:26:47 [DKA]
01:27:20 [sylee_]
sylee_ has joined #bpwg
01:27:35 [Bryan]
Sean: In the last CT call Aaron mentioned for legacy servers a 200 response which says "use a different browser" is not always clear as an error indication to the user.
01:28:39 [Bryan]
Francois: Moving on, re the open question on request bodies, it was mentioned that the CT proxy may modify body encoding if the body does not match that requested by the server.
01:28:51 [jo]
01:29:07 [Bryan]
01:29:26 [Bryan]
Francois: Not convinced there is a real problem to be mentioned here.
01:30:20 [Bryan]
Jo: Confused about this; not sure what the problem is that is not general; can the server mandate a specific request body for any specific action
01:30:24 [jo]
ack j
01:30:28 [jo]
ack b
01:31:22 [RH]
RH has joined #bpwg
01:31:42 [Bryan]
Bryan: See this as a corner case, not a normal proxy behavior, and maybe something for specialized service access.
01:31:42 [rob]
01:31:57 [Bryan]
Francois: Suggests we ask Aaron for more input,.
01:32:08 [SeanP]
01:32:19 [francois]
ack rob
01:32:23 [Bryan]
Jo: We could say that the body should not be altered unless there is a specific mobile use case being addressed.
01:33:21 [Bryan]
Rob: The proxy may modifying a form as needed, e.g. to break a page into subpages.
01:33:53 [Bryan]
Francois: How does that work in practice, e.g. the pages and form functions are split up?
01:34:20 [Bryan]
Rob: Yes, that's how it happens.
01:35:04 [Bryan]
Ron: The handset sent form may be modified by the CT proxy if necessary for adapting the page.
01:35:07 [SeanP]
01:36:37 [SeanP]
01:36:43 [Bryan]
Francois: Other notes need to be considered re breaking a page into subpages which are locally served by the proxy.
01:37:32 [Bryan]
Jo: The choices for this document is to say whether the entity body should be modified or not, or being more detailed eg. should not do (a) unless (b).
01:39:05 [jo]
ack s
01:39:15 [Rotan]
We do form splitting. Have found that user perception of goal/purpose/intent of form can be affected by how much of the form can be seen at one time. So it's more than a pure technical issue.
01:39:18 [jo]
q+ seanP
01:39:27 [Bryan]
Bryan: The two cases are being discussed; a single request-response with modification, and a request that is delivered in pieces to the user, with possible form modifications as needed to make the page work.
01:40:16 [Bryan]
Dan: Would like to see if any CT discussions we are having resonates for the Korean market, and what input they will have.
01:40:19 [Rotan]
People tend to read forms first. Then fill them in. By limiting the form (or "wizarding" it) you change the way a user perceives the form. It's psychology... :)
01:41:25 [jo]
zakim, pingme at 0200
01:41:25 [Zakim]
I don't understand 'pingme at 0200', jo
01:41:35 [jo]
zakim, ping me at 0200
01:41:35 [Zakim]
I don't understand 'ping me at 0200', jo
01:41:45 [jo]
zakim, ping me in 19 mins
01:41:45 [Zakim]
ok, jo
01:41:59 [jo]
[coffee break]
01:51:15 [soonho]
soonho has joined #bpwg
02:00:35 [DKA]
Scribe: Dan
02:00:43 [DKA]
ScribeNick: DKA
02:00:45 [Zakim]
jo, you asked to be pinged at this time
02:01:14 [DKA]
02:02:18 [DKA]
Sean: going back to the talk of forms - transforming the request - at one point the novarra server would change the form to a more streamlined version - for example, integers refering to each field in the form - and that would get sent back to the proxy and the proxy would change it back to what the original form id values were.
02:02:31 [jo]
ack se
02:02:38 [DKA]
Sean: So you're basically changing the form on the way down and changing it back to the original on the way up.
02:03:15 [jo]
[fancois asks for examples of this behavior]
02:03:17 [DKA]
Francois: could we have an example of that?
02:03:25 [jo]
02:03:27 [DKA]
Sean: I think we can do it.
02:03:33 [DKA]
Rob: I could do a pseudo-code example.
02:03:38 [jcantera]
jcantera has joined #bpwg
02:03:47 [DKA]
Francois: to see what's being done in practice
02:04:09 [DKA]
02:04:35 [DKA]
ACTION: Rob to provide a pseudo-code example of form transformation for CT document.
02:04:35 [trackbot-ng]
Sorry, couldn't find user - Rob
02:05:00 [jo]
ACTION: finean to provide a pseudo-code example of form transformation for CT document.
02:05:00 [trackbot-ng]
Created ACTION-680 - Provide a pseudo-code example of form transformation for CT document. [on Robert Finean - due 2008-03-10].
02:05:35 [DKA]
Jo: We need more text - we need something from Aaron.
02:05:37 [Bryan_Sullivan]
Bryan_Sullivan has joined #bpwg
02:06:15 [jo]
ACTION: daoust to ask aaron kemp for clarification of the character encoding issue
02:06:15 [trackbot-ng]
Created ACTION-681 - Ask aaron kemp for clarification of the character encoding issue [on François Daoust - due 2008-03-10].
02:07:02 [DKA]
Francois: reaching the identified issue that needs to be addressed - how should the CT proxy behave when it has a request and it needs to forward it to the server.
02:07:55 [DKA]
Francois: one proposal is that it issues a HEAD request and analyze the response, then if it's still in doubt issue a GET request with the original headers and if it's still in doubt issue a GET request with altered headers.
02:07:56 [jcantera]
jcantera has joined #bpwg
02:09:03 [DKA]
Francois: We'd like the CT proxy not to change the original headers. However, the CT proxies do that because they have to do this because many servers won't respond correctly when they get a mobile user agent string - they might respond with a 406 or they may respond with a 200 but none-the-less it's an error page saying they can't serve the page.
02:09:31 [DKA]
Francois: My POV on that would be to forget the HEAD requests.
02:09:43 [jo]
q+ to explain why the HEAD request is there
02:11:03 [DKA]
Francois: From the server's POV there should be only one request. An example of why this is necessary is when the server computes statistics - another example would be for example confirmation URIs or GET requests with parameters which change a state [and therefore double-requesting these URIs would be problematic].
02:11:53 [DKA]
Francois: I think when you send a HEAD request to the server, the server will just perceive it as a GET request and only return the headers - so the underlying code would be excecuted. Needs to be checked in practice. So issuing a HEAD request is _as harmfull_ as issuing a GET request.
02:12:30 [SeanP]
02:12:42 [DKA]
Francois: I suggest we only issue the request with the original headers and as a fallback issue with the altered headers but that would mean we have a way to determine when the response fromt he server is unsuitable.
02:14:02 [DKA]
Jo: The HEAD request is to retreive meta information in the resource. Couple of problems here. Chicken and egg situation here - we need to know meta information about resources without retreiving it so we should do some research on whether using HEAD would be harmful. Because HEAD is in HTTP specifically for this very purpose.
02:14:18 [Rotan]
This is the case for Apache.
02:14:24 [DKA]
Francois: You want to check that a HEAD request would be processed on the server as if it were a GET request.
02:14:37 [Rotan]
Apache generates the content, then throws it away as it responds to HEAD.
02:14:56 [DKA]
Jo: Yes - Although we probably need to kick this one upstairs to the TAG.
02:15:39 [DKA]
Francois: I'll take an action to try it with different servers -- how it would be handled with Apache and IIS - with JSP, ASP, PHP, etc...
02:16:14 [Bryan_Sullivan]
02:16:15 [DKA]
ACTION: Francois to write some simple tests for well-known server environments for how they deal with HEAD requests.
02:16:15 [trackbot-ng]
Sorry, couldn't find user - Francois
02:16:17 [DKA]
02:16:21 [jcantera]
jcantera has joined #bpwg
02:16:21 [jo]
ack j
02:16:21 [Zakim]
jo, you wanted to explain why the HEAD request is there
02:16:23 [Rotan]
WSGI systems replace HEAD with GET when passing on requests.
02:16:29 [jo]
ack seanP
02:17:05 [rob]
02:17:06 [DKA]
Sean: The idea of making multiple requests seems overly complicated to me - the simplest way would be make one request, allow the headers to be changed and include the change header information in the request.
02:17:07 [DKA]
02:17:13 [francois]
ack Bry
02:17:14 [jo]
ack b
02:17:32 [DKA]
Bryan: Are we assuming that the head request is coming from the client?
02:17:40 [DKA]
Francois: No it's from the proxy.
02:18:04 [DKA]
Bryan: because HEAD requests sometimes do come from the client - should the CT proxy simply pass these through?
02:18:10 [Rotan]
See 3. at
02:18:14 [DKA]
Jo: That's an open question.
02:18:22 [DKA]
Bryan: What's the intervention in the case of HEAD then?
02:18:54 [DKA]
Francois: CT proxy with a HEAD request - it should do nothing on a HEAD request - just add the VIA header.
02:19:09 [Rotan]
Please read 3. on the link above.
02:19:28 [MartinJ]
02:19:35 [DKA]
Bryan: Typlically the HEAD request is sent becaus the client needs to know certain things - because it wants to determine if the response is too large for example. I'm not sure if turning the HEAD request into a GET request would be appropriate.
02:19:49 [DKA]
Francois: I don't think the CT proxy should do anything with a HEAD request.
02:20:04 [DKA]
Bryan: Other than potentially changing the user agent header - to maintain consistency.
02:20:06 [DKA]
02:20:12 [DKA]
ack rob
02:21:03 [DKA]
Rob: the HEAD request is used from handsets a lot but tends to be used for cache management of images. We do have to be able to adapt the HEAD request - in OpenWave's case, we're tokenizing the URLs in order to save space so we have to de-tokenize the URL.
02:21:32 [Rotan]
I agree. Have observed HEAD/GET equivalence in many Web servers.
02:21:55 [DKA]
Rob: A lot of web servers do exactly the same for a HEAD as well as a GET. Confirmation strings that are sent in Email messages need to be GETs because they're sent in Email - although they should be POST.
02:22:13 [DKA]
Rob: I think the two-phase approach - tasting the content - is beneficial.
02:22:28 [DKA]
Francois: The cool thing about about that is we wouldn't need to change the user agent.
02:22:42 [francois]
02:22:50 [DKA]
Rob: There's still the business about tokenizing URLs so you might change requests just not user agents.
02:22:53 [jo]
ack m
02:23:03 [DKA]
Martin: I'd like to echo what Rob said about the two-phase approach [content tasting].
02:23:47 [sylee_]
sylee_ has joined #bpwg
02:24:21 [DKA]
Martin: 2ndly on turning a HEAD request into a GET request - a device might be issuing a HEAD request in order to find out how large the response is - so servers must execute the code in order to know this - but PROXYs would need to issue a GET request as well so it can get the content and attempt to transform it.
02:24:34 [DKA]
Martin: So there's a valid use case for converting a HEAD into a GET in the proxy.
02:24:35 [Bryan_Sullivan]
02:24:49 [francois]
ack Br
02:25:27 [DKA]
Bryan: Most cases where the user agent would use a HEAD, you wouldn't expect the transforming proxy to signifigantly altter the size (eg media).
02:25:43 [DKA]
Bryan: Are you saying it would be the optimized form the user agent would store?
02:25:46 [DKA]
Martin: yes.
02:26:20 [DKA]
Bryan: so the CT proxy should modify the content size in the HEAD response to the optimized size but unless it actually got the content it wouldn't know that.
02:26:23 [DKA]
Martin: right.
02:26:42 [DKA]
Bryan: But the statefulness effect of issuing a GET could be signifigant.
02:27:07 [DKA]
Martin: the CT proxy could help do this by not issuing another GET request when the user agent actually did GET the content.
02:27:52 [DKA]
Francois: 2 discussions here: one is how it should behave with a GET request and one on how it should behave with a HEAD request from the client - which we hadn't considered before.
02:28:18 [DKA]
Francois: This should be in scope - we need to do something about such a comon case.
02:29:23 [DKA]
DKA: Let's try to bottom out the first discussion and action someone to write a proposal on the HEAD issue.
02:29:34 [Rotan]
02:29:35 [DKA]
ACTION: Martin to write a proposal on the HEAD request handling.
02:29:35 [trackbot-ng]
Sorry, amibiguous username (more than one match) - Martin
02:29:35 [trackbot-ng]
Try using a different identifier, such as family name or username (eg. mharris2, mjones4)
02:29:44 [DKA]
ACTION: Martinj to write a proposal on the HEAD request handling.
02:29:44 [trackbot-ng]
Sorry, couldn't find user - Martinj
02:29:51 [DKA]
ACTION: Martin Jones to write a proposal on the HEAD request handling.
02:29:51 [trackbot-ng]
Sorry, amibiguous username (more than one match) - Martin
02:29:51 [trackbot-ng]
Try using a different identifier, such as family name or username (eg. mharris2, mjones4)
02:30:21 [jo]
02:30:57 [jo]
q+ to add wondering if the two approaches can work in parallel
02:32:08 [DKA]
ACTION: Jones to write a proposal on the HEAD request handling.
02:32:08 [trackbot-ng]
Created ACTION-682 - Write a proposal on the HEAD request handling. [on Martin Jones - due 2008-03-10].
02:33:03 [rob]
02:33:06 [DKA]
Francois: the real question is: how can the CT proxy know when it needs to re-issue a request with an altered header. If the server returns a 406, it's easy. If it doesn't, you can't.
02:34:39 [DKA]
DKA: I suggest we say the server can issue a 406 and that's great but the CT proxy could also use its own heuristics to determine if it's an unacceptable response - because this is percisely the point on which CT proxy vendors differentiate.
02:34:52 [DKA]
Francois: Yes if that's what we agree.
02:34:57 [jo]
ack rob
02:35:12 [MartinJ]
02:35:57 [DKA]
Rob: I agree with Dan. There's a lot fo complexity in tasting content and figuring out what kind of content it is is complex. Usually 406 is only ever returned if you do a POST instead of a GET and vice-versa. In terms of the two-phase approach and in terms of how you taste the content, it should be left up to the vendors.
02:36:24 [DKA]
Francois: I don't want to write the method - and it's the added value for the CT vendor. Sean would you be pleased with that/
02:36:46 [Rotan]
You can force a 406 on Apache with a particular pattern in POSTed HTML when mod_security is present in its default config.
02:37:21 [DKA]
Sean: Maybe - I wanted to bring up two things - one it can be difficult to determine if the reponse is a reasonable response, the other is the case where the user wants the desktop content - then it doesn't make sense to request the mobile content first if that's not what you want.
02:37:25 [rob]
02:37:39 [DKA]
Jo: I think that this case is carved out above [in the Note above]
02:37:41 [DKA]
02:38:30 [DKA]
Jo: this is going on to say - unless these carveouts apply - you should do this [tasting]. This will give content providers guidance on how tasting will occur.
02:38:46 [DKA]
ack jo
02:38:47 [Zakim]
jo, you wanted to add wondering if the two approaches can work in parallel
02:38:50 [DKA]
ack martin
02:39:09 [jo]
q+ you wanted to add wondering if the two approaches can work in parallel
02:39:43 [jo]
q+ to wonder if the two approaches can work in parallel
02:39:43 [Rotan]
+1 to Martin
02:40:07 [DKA]
Martin: Agree with Dan and Rob - the approach to allow CT vendors to have their own methods to determine if response is acceptable. But we should try to discourage 2nd requests unless necessary. We should discourage people from making 2 requests automatically and comparing the two responses, for example.
02:41:07 [DKA]
Martin: Caching the knowledge of responsiveness of the site to different header types - if it's know that the site is adapting - then it could start making requests using the altered headers the first time once it knows the non-altered response doesn't work.
02:41:29 [rob]
02:41:30 [Kangchan]
02:42:12 [DKA]
Jo: We need to come back to a point - about the a priori knowledge it has of server preferences.
02:42:46 [francois]
02:43:08 [francois]
ack jo
02:43:08 [Zakim]
jo, you wanted to wonder if the two approaches can work in parallel
02:44:22 [DKA]
Jo: it seems that we could do something - submit the request with the genuine original headers by default but maybe introduce an optimization that you could provide alternative headers that say "if you're smart enough, I could be this if you want me to be." There doesn't seem to be a signifigant disadvantage tho there may not be an advantage.
02:45:03 [DKA]
Francois: This would only target new implementations that would know about the guidelines. I don't think we want servers in the future to know about multiple requests. It's agains the "one Web" approach.
02:45:14 [DKA]
Jo: Just because it's one web doesn't mean you don't have varrying representations.
02:46:02 [DKA]
Francois: I agree, but this is not a flexible enough mechanism to be useful in the future. What would be interesting would be for a client to define more percisely what it can be - possibly using labeling instead. It can't be easily extended.
02:46:10 [DKA]
Jo: It could be easily extended.
02:46:22 [DKA]
Jo: I don't think it's harmful but I don't know if it would be useful.
02:46:44 [DKA]
Jo: send the alternative user agent as the alternative...
02:46:51 [DKA]
02:46:53 [DKA]
ack dka
02:48:21 [DKA]
DKA: [speaks in support of sending the dual headers]
02:48:59 [SeanP]
02:49:01 [Bryan_Sullivan]
02:49:14 [DKA]
Jo: If you have a primary, secondary and teriary it may not be clear what the server has picked - if we said that there could be multiple user agent headers, we should write how the server should make that decision and how it should indicate what header it used back up the stream.
02:49:26 [DKA]
Sean: Why is it necessary to know how the decision was made.
02:50:26 [DKA]
Jo: On the basis of the input from Rob and Martin - once you've had a response from a particular origin server - which would determine your future behavior - so if you've put mutliple UA headers in and you don't know what the response was based on then you wouldn't have the knowledge.
02:50:32 [DKA]
Sean: you could always put them in though.
02:50:35 [DKA]
Jo: good point.
02:50:36 [francois]
02:50:38 [francois]
ack se
02:50:40 [francois]
ac br
02:50:44 [francois]
ack br
02:52:19 [DKA]
Bryan: it's good to stick as much with existing technology, existing methodology. I'm not sure whether content providers will appriacte us complicating their lives to support this use case. The overhead of submitting 1 request vs. 2 reqeusts (the first time) is fairly minimal. I think it's a fairly complicated thing from a content provider perspective meeting a relative short term requirement.
02:52:25 [DKA]
Francois: I agree with Bryan.
02:52:26 [jo]
PROPOSED RESOLUTION: Under 3.1.2 drop the HEAD request
02:52:26 [MartinJ]
+1 to Bryan
02:53:09 [DKA]
Francois: We agree with what is written here except for the HEAD request.
02:53:36 [DKA]
Jo: We should probably still have a justification for having removed it [but I suggest we remove it anyway.]
02:54:00 [rob]
02:54:02 [francois]
02:54:05 [MartinJ]
02:54:05 [francois]
02:54:07 [SeanP]
02:54:18 [jo]
RESOLUTION: Under 3.1.2 drop the HEAD request
02:54:21 [Rotan]
(Just observing, but I also agree)
02:54:41 [DKA]
Francois: 2 remaining points - emphasis on a priori knowledge
02:55:16 [DKA]
Francois: should we say something about a request to a URI may mean something about a request of a document "close to" that URI.
02:55:29 [Rotan]
What does "close to" mean?
02:55:37 [Rotan]
URIs are supposed to be opaque.
02:55:38 [rob]
02:55:39 [DKA]
Jo: We should move on to that - what inference could be made...
02:55:40 [DKA]
02:55:46 [DKA]
ack rob
02:55:50 [Rotan]
02:56:08 [Rotan]
I could build a whole set of sites all using that example URI.
02:56:18 [Rotan]
You have NO WAY to know what is or is not close.
02:56:41 [Rotan]
You cannot assume that a URI has a "path" in it.
02:56:43 [jo]
jo points out the authentication model which contradicts Rotan
02:56:48 [DKA]
Rob: You can't do it in the way you do authentication - once you're in a gateway mode, changing the content, handling cookies and javascript, you can find yourself jumping from domain to domain (for example for a sign-in) you have to keep on adapting in the same way. You have to have consistency during a session.
02:57:35 [Rotan]
Respectfully disagree.
02:57:37 [jo]
02:57:46 [jo]
ack d
02:58:17 [DKA]
DKA: I think the concept of user session comes into it.
02:58:18 [DKA]
02:58:29 [DKA]
Jo: Um
02:58:37 [Bryan_Sullivan]
03:00:23 [DKA]
Jo: As I understand what Rob is saying : in a page which is a composite of many different object you need to have consistency for how you deal with each item. But you need to have a priori knowledge of how servers handle requests. The fact that a particular page has references to other pages sure means you have to have the a priori knowledge from those other places as well...
03:00:27 [rob]
03:00:39 [francois]
ack rob
03:01:00 [francois]
ack Br
03:01:01 [DKA]
Rob: If you're following a page and links off that page you should maintain consistency. But if you go to a new website starting from scratch you should taste content again.
03:01:51 [DKA]
Bryan: the basic concern I have over the notion of content tasting is that it's likely to break some services. It'll be very important for CT proxies to be intelligent enough to discover when things are breaking or at least to have a configuration of "don't do this for certain sites."
03:02:40 [DKA]
Bryan: Just because you get redirected from one place to another doesn't necesarilly mean you need to go taste the service from the new server. That presumption could break the operation of the overall data flow. The notion of content tasting has to be used very carefully.
03:03:01 [DKA]
Bryan: the service provider should know what sites are sensitive - for example regexp-specified URIs.
03:03:46 [rob]
03:03:49 [DKA]
Jo: both Rob and Martin said thought that inferences of a sort could be made - the question remains open what are those inferences.
03:03:52 [DKA]
ack rob
03:04:13 [DKA]
Rob: They are - that there either is a mobile edition suitable for the user agent or there isn't.
03:04:55 [DKA]
Jo: what can we put in the document about under what circumstances they can be an inference made? What is the algorithm we could suggest or what are some clues we can give?
03:05:28 [SeanP]
03:05:37 [jo]
ack s
03:05:37 [DKA]
Jo: A CT proxy - if it visits landing page x and then it visits y, if the following relationship is true of x and y then it will assume that x and y have the same characteristics given no a priori information.
03:06:06 [DKA]
Sean: we're talking about 2 things - 1. what can we tell content providers 2. what can we do about servers that are out there.
03:06:19 [jo]
s/no a/no other a/
03:06:30 [DKA]
Bryan: I agree - the non CT-aware servers are the richest use case.
03:06:51 [DKA]
Jo: From the POV of the guidelines to CT proxies, what inferences are reasonable to make?
03:07:07 [DKA]
Scribe: Rob
03:07:15 [DKA]
ScribeNick: rob
03:08:05 [rob]
Francois: I've no answer and we definitely need one...
03:08:56 [jo]
ACTION: Finean to raise an issue on inferencing from the structure of the URI what assumptions to make about another from the point of view of the CT Proxy
03:08:56 [trackbot-ng]
Created ACTION-683 - Raise an issue on inferencing from the structure of the URI what assumptions to make about another from the point of view of the CT Proxy [on Robert Finean - due 2008-03-10].
03:09:02 [rob]
Bryan: eg if I request content in 2 forms and my hand gets slapped in 2nd form, what should I infer?
03:09:51 [rob]
Francois: eg and then -- are they really connected?
03:10:12 [Rotan]
(Has anyone ever considered the HTTP 1.1 "OPTIONS" request? It was designed to be extensible.)
03:10:15 [SeanP]
03:10:44 [francois]
ack SeanP
03:10:45 [Rotan]
03:11:09 [Bryan_Sullivan]
03:11:18 [rob]
Sean: it's possible a solution works for all - but it's more likely vendors will come up with different solutions
03:12:07 [rob]
Jo: if we wnat to tell CT-aware content something then perhaps POWDER is the answer
03:12:17 [rob]
03:12:44 [rob]
Bryan: what's the advantage of inferring future behaviour?
03:13:26 [rob]
... minimising n of hits? making it work at all?
03:14:17 [rob]
Jo: specifically it's bullet "any a priori knowledge"... in sec 3.1.2
03:15:03 [DKA]
03:15:04 [DKA]
03:15:06 [DKA]
ack bry
03:15:06 [rob]
Bryan: and might we note the a priori knowledge is user-specific
03:15:06 [francois]
ack bry
03:15:08 [DKA]
ack dka
03:15:35 [SeanP]
03:15:45 [DKA]
03:15:50 [DKA]
ack seanp
03:15:54 [DKA]
q+ seanp
03:15:55 [rob]
Dan: and note it could be vendor-specific and needn't be detailed too much here
03:15:59 [Bryan_Sullivan]
03:16:19 [francois]
ack Bryan_Sullivan
03:16:42 [rob]
Bryan: most valuable a priori knowledge will be pre-configured by operators and vendors
03:16:45 [SeanP]
03:16:53 [DKA]
03:17:06 [rob]
... and by content authors with POWDER
03:17:50 [DKA]
03:18:22 [rob]
Sean: I don't see a particular way to describe this other than say it's up to vendors
03:18:27 [MartinJ]
03:18:45 [rob]
Dan: 2 specific use-cases come to mind:
03:19:14 [rob]
... one is you think you know about a website then a different User-Agent works differently
03:19:18 [Rotan]
+1 to Dan (we're seeing demand for iPhone-specific responses)
03:19:23 [jo]
[The server should have a vary:* in that case, Dan]
03:19:34 [rob]
... (eg iPhone-aware site)
03:20:13 [jo]
q+ to sya that surely this is a general caching problem
03:20:28 [jo]
ack d
03:20:29 [rob]
... the other one is where the user has a "mobile/desktop edition preference" that the origin server has no knowledge of
03:20:49 [DKA]
03:21:30 [jo]
s/has no knowledge of/knows about but the CT proxy doesnt
03:21:34 [Rotan]
The "vary" should indicate all the headers upon which it made its response decisions.
03:21:44 [jo]
or *
03:21:45 [rob]
s/that the origin server has no knowledge of/with the ORIGIN website
03:21:57 [DKA]
03:22:16 [Rotan]
But user prefs might be outside of the HTTP interaction. E.g. customer-specific knowledge held in an Operator's database.
03:22:16 [Bryan_Sullivan]
03:22:18 [DKA]
ack martinj
03:22:58 [rob]
... a user preference with the origin website that the CT-proxy has no knowledge of
03:23:30 [DKA]
ack jo
03:23:30 [Zakim]
jo, you wanted to sya that surely this is a general caching problem
03:23:33 [francois]
ack jo
03:23:41 [rob]
Martin: we should conentrate on a set of warning notes instead of a description of how it works
03:24:39 [rob]
Jo: how about either an informational point about this is what you can expect a CT-proxy to do
03:26:05 [francois]
ack Bryan_Sullivan
03:26:08 [rob]
... and note the issue of cachability is generally appliccable
03:26:21 [rob]
s/either an/an/
03:26:59 [rob]
Bryan: at the very least this is inferred on a User-Agent by User-Agent basis
03:27:08 [MartinJ]
03:28:25 [jo]
[summary of my response to Martin: that informational notes would help CPs understand what CTs are doing but giving warnings to CT providers may not be as useful, and there are very large number of possible warning areas that we would have to note]
03:29:03 [rob]
Martin: it's appropriate other CT-vendors outside this WG will be interested in these guidelines
03:29:16 [jo]
03:29:20 [jo]
ack m
03:29:23 [jo]
ack j
03:30:17 [rob]
Jo: agree with Martin, the level of discussion indicates it isn't obvious
03:31:29 [jo]
[notes that if we put some warning notes in and not others then incorrect inferences may be made about the importance of those notes]
03:31:43 [rob]
Francois: on to sec 3.1.3
03:32:00 [rob]
... and talking about POWDER
03:32:29 [DKA]
I wanted to highlight a newly-lauched mobile web site - - which does a particularly good job of following the best practices (not MobileOK - fails 3 tests - but passes 23 - impressive) - and also provides a iPhone-optimized version on the same URI - alternate representations. Just to underscore that these guidelines are addressing real use cases that headline websites are implementing TODAY.
03:32:37 [rob]
... according to HTTP the CT-proxy must add a Via header
03:33:09 [rob]
... and we can reference a URI to describe CT capabilities in the Via string
03:33:52 [rob]
... POWDER is only a 1st working draft at present
03:34:47 [rob]
... but sounds like it will be an ideal format to use
03:35:31 [rob]
... Question is does anyone know enogh to define this guideline yet?
03:35:59 [SeanP]
03:36:08 [rob]
Dan: does it make sense to wait until POWDER is more gorund?
03:36:22 [rob]
03:37:04 [jo]
ack s
03:37:11 [Bryan_Sullivan]
03:37:46 [rob]
Sean: it seems to make the Via information useful you need to go into some detail about capabilities
03:37:58 [rob]
... so fact it is a moving target is a problem
03:38:08 [jo]
q+ to say that we should avoid repeating UA PROF
03:38:23 [rob]
Bryan: isn't it helpful just to know there is a CT-proxy in the 1st place?
03:39:26 [rob]
... even with no additional knowledge of its exact capabilities?
03:40:09 [Rotan]
One of the downsides of UAProf was that the URI was hardcoded into the client's request, and referred to a server that was external and beyond the control of the client. That rigidity and disconnect was a source of much pain.
03:40:41 [rob]
... maybe we're getting ahead of ourselves trying to define a capabilities specification yet
03:40:45 [Rotan]
A URI in a response from a server could be flexible, and could even refer to itself, so it doesn't have the downsides of UAProf,
03:41:01 [MartinJ]
03:41:22 [jo]
ack b
03:41:26 [jo]
ack j
03:41:26 [Zakim]
jo, you wanted to say that we should avoid repeating UA PROF
03:41:50 [rob]
Jo: we shouldn't repeat the UAprof style of specifying a URI and saying "go figure"
03:42:09 [Rotan]
The "here be dragons" flag.
03:43:50 [jo]
[adjourn for lunch]
04:43:01 [MartinJ]
MartinJ has joined #bpwg
04:49:35 [jcantera]
jcantera has joined #bpwg
04:50:30 [jo]
rrsagent, make minutes
04:50:30 [RRSAgent]
I have made the request to generate jo
04:51:36 [jo]
rrsagent, make logs public
04:57:46 [wonsuk]
wonsuk has joined #bpwg
04:59:23 [soonho]
soonho has joined #bpwg
05:04:33 [SeanP]
05:04:42 [SeanP]
05:06:24 [SeanP]
DKA: does a lot of the MobileOK stuff
05:06:57 [SeanP]
DKA: does a lot of the MobileOK stuff
05:07:31 [sylee]
sylee has joined #bpwg
05:07:34 [SeanP]
Topic: Content Transformation
05:08:39 [SeanP]
Francois: Before lunch we said that maybe only a flag that CT was taking place was necessary.
05:08:53 [Bryan_Sullivan]
05:09:02 [SeanP]
...I tend to think that a URI is kind of harmless and would be a good thing.
05:09:15 [jo]
ack b
05:09:26 [jo]
ack m
05:09:31 [SeanP]
Bryan: The parameter would represent a flag.
05:10:38 [SeanP]
Francois: The question about Powder still exists but we'll come back to that. The POWDER description may not be needed for now.
05:11:55 [rob]
05:12:41 [SeanP]
...In section 3.1.4, if we go with the two requests then there is no need to put the original headers in the second request.
05:12:53 [DKA]
05:13:38 [SeanP]
Rob: That my be too far. Mandating that the first request has the original UA is too much.
05:14:21 [SeanP]
Francois: That's what we said earlier. I don't see the reason to provide the original headers in the second request.
05:14:24 [jo]
05:14:29 [jo]
ack r
05:14:50 [SeanP]
Rob: I don't see why we should prohibit sending the original headers.
05:15:42 [SeanP]
Jo: There may be administrative arrangement between user and operator--the content provider still needs to get the original header values.
05:17:00 [SeanP]
Jo: In some cases it will have sent the original headers but not all cases.
05:17:26 [SeanP]
Francois: In that case we need to find a way to provide the original headers.
05:17:40 [Bryan_Sullivan]
05:17:56 [jo]
ack j
05:18:33 [SeanP]
...The main point is the UA header. Not too many possible ways to do that. Need to use a new header.
05:18:52 [SeanP]
Bryan: Are we just talking about the Accept headers.
05:19:04 [SeanP]
Francois: Talking about UA and Accept.
05:20:12 [SeanP]
Bryan: Sometimes UA Profile header is changed. Going down the path of providing original headers gets into the new technology territory.
05:20:52 [jo]
05:20:56 [francois]
ack Bryan_Sullivan
05:21:07 [francois]
ack jo
05:21:08 [MartinJ]
05:21:18 [SeanP]
...That is a significant bar to set for content providers. Another level of complexity if content provider needs to handle two different types of responses.
05:22:10 [francois]
ack MartinJ
05:22:11 [jo]
ack m
05:22:18 [Bryan_Sullivan]
05:22:57 [SeanP]
Jo: A chicken and egg situation. Not providing original headers removes incentive to make mobile sites.
05:23:03 [Rotan]
It would be counter to what we're trying to do with the DDR Simple API, which will need to find the device evidence in the headers.
05:23:16 [francois]
ack Bryan_Sullivan
05:23:53 [SeanP]
Martin: Mobile content providers use headers for statistics, etc. Seems like a good idea to provide original headers.
05:25:08 [SeanP]
Bryan: Simply suffixing the original UA header to the end of the new UA is common technique for WAP gateways.
05:25:30 [rob]
05:25:37 [SeanP]
...Saying a request comes from 2 different user agents will confuse content providers.
05:26:52 [SeanP]
Bryan: 1) need to specify that a CT server is in the path and 2) need to give the original server a different UA--the second one is the problem.
05:27:20 [SeanP]
Rob: Agree. Two UAs in a request could confuse Content servers.
05:27:58 [SeanP]
Francois: Hard to append original headers to end of existing headers. Need to create new header.
05:28:04 [SeanP]
05:28:27 [rob]
ack rob
05:29:22 [SeanP]
Jo: Could include a URI in request where the original headers could be found. Wrap up original headers and put them in the request body.
05:30:03 [SeanP]
Francois: Could add a new header that has all of the original information that we need.
05:31:08 [SeanP]
Jo: There are no good answers. Need the least bad answer. A possibility is to include a URI to the original headers.
05:32:15 [SeanP]
Bryan: Put a content-type in the message body. That's lighter weight.
05:32:42 [rob]
05:33:14 [SeanP]
Jo: What headers should be provided? All of them, some of them, the ones we have identified (UA and Accept). Content providers may look at more headers than just the UA.
05:33:37 [MartinJ]
05:34:02 [SeanP]
...Could look at things that are added downstream from CT proxy.
05:34:13 [DKA]
05:34:33 [DKA]
ack seanp
05:35:51 [SeanP]
Sean: Could put original headers in Via header.
05:36:05 [SeanP]
Francois: That sounds dirty.
05:36:14 [francois]
ack rob
05:36:32 [jo]
ACTION: Jo to include a note that we think it is bad practice to strip the comment from downstream via header fields
05:36:33 [trackbot-ng]
Created ACTION-684 - Include a note that we think it is bad practice to strip the comment from downstream via header fields [on Jo Rabin - due 2008-03-10].
05:36:43 [jo]
05:36:56 [francois]
ack MartinJ
05:37:11 [SeanP]
Rob: If you change the header provide the original, otherwise don't worry about it. Provide the original header in Original-xxx.
05:37:27 [SeanP]
Martin: Use the Warning header--can be used in requests.
05:37:29 [Bryan_Sullivan]
05:38:44 [jo]
ack j
05:38:56 [SeanP]
Jo: We're doing variations on a theme. The problem with the X-Original-xxx headers is what if the headers are modified further. The problem with the Warning header is it is not a structured field.
05:39:02 [Rotan]
Are CT chains in scope? Could be a very tricky issue, as hinted at by Jo.
05:39:25 [SeanP]
Bryan: Are we addressing efficiency here?
05:40:32 [SeanP]
Jo: No we are not talking about efficiency. We're trying to help the content providers to provide the right content and tabulate mobile statistics.
05:41:50 [chaals]
chaals has joined #bpwg
05:42:02 [SeanP]
Bryan: We're going to have trouble embedding multiple headers in a single line. Something along the lines of a pointer to the headers makes more sense. Using Application External Body would work.
05:42:35 [francois]
Present+ chaals
05:42:53 [chaals]
rrsagent, draft minutes
05:42:53 [RRSAgent]
I have made the request to generate chaals
05:43:26 [jo]
-> HTTP mime types
05:44:47 [SeanP]
Francois: Using references to external URI seems to be too complicated. Would have to use a link to get original request. Seems too complex in practice.
05:45:08 [SeanP]
Jo: Should have investigatory actions on this topic.
05:45:45 [SeanP]
Francois: Need everyone to look into this.
05:45:59 [Rotan]
Could also introduce a security threat if the headers were available at a location external to the path between client and server.
05:46:31 [jo]
good point Rotan
05:47:05 [SeanP]
Francois: Methods: 1. Embed headers in another header. 2. Provide a pointer to headers in a separate location. 3. Warning header 4. Additional HTTP headers
05:47:17 [Rotan]
Adding more bulk to the headers is also a problem because some systems (e.q. squid and load balancers) limit total header size to counter DoS attacks.
05:47:18 [DKA]
05:50:16 [SeanP]
Jo: In HTTP spec the content type I was referring to is message/HTTP.
05:50:36 [francois]
ACTION: Daoust to investigate embedded original headers in altered requests (message/http), external ref to original headers (application/external-body) and/or use of WARNING headers for 3.1.4
05:50:36 [trackbot-ng]
Created ACTION-685 - Investigate embedded original headers in altered requests (message/http), external ref to original headers (application/external-body) and/or use of WARNING headers for 3.1.4 [on François Daoust - due 2008-03-10].
05:50:55 [SeanP]
Bryan: I was talking about message/External-Body.
05:51:15 [SeanP]
05:51:45 [SeanP]
Jo: Warning would at least provide an indication that headers have been modified.
05:52:04 [SeanP]
Francois: Warning is a general header--can be used in request.
05:53:31 [SeanP]
Francois: Can't take any resolutions yet. Need to settle the use of POWDER in the response from the server.
05:54:45 [SeanP]
...Do we want to use it? Need details for it to be useful. For now we should just mention that POWDER could be used.
05:55:09 [jo]
05:55:15 [jo]
ack b
05:55:15 [francois]
ack Bryan_Sullivan
05:55:40 [SeanP]
Bryan: The POWDER reference is fine if we say that further work on this is done in the context of POWDER or the Delivery Context.
05:56:06 [SeanP]
Jo: We can't leave it to POWDER since they aren't chartered for that.
05:56:30 [SeanP]
...Not really part of the Delivery Context either.
05:57:28 [SeanP]
Jo: Would like to see us create the POWDER vocabulary. Phil says that POWDER will be done real soon now. Given that we have more work on CT, we can afford to wait.
05:57:54 [SeanP]
Francois: We're not ready to publish a first public working draft.
05:57:54 [wonsuk]
05:57:58 [jo]
s/.../server preferences /#
05:58:36 [SeanP]
Jo: We can publish a FPWD with a dangling reference to POWDER.
05:58:48 [SeanP]
Francois: I think that is OK.
06:00:14 [DKA]
PROPOSED RESOLUTION: AS far as we have reviewed of CT will not alter other than agreed changes and editorial notes; there will be no changes up to 3.1.4 other than these, therefore we can focus on 3.1.4 onwards and then move to fpwd.
06:00:35 [francois]
06:00:48 [jo]
06:00:50 [DKA]
RESOLUTION: AS far as we have reviewed of CT will not alter other than agreed changes and editorial notes; there will be no changes up to 3.1.4 other than these, therefore we can focus on 3.1.4 onwards and then move to fpwd.
06:00:50 [SeanP]
06:05:53 [Seungyun_]
Seungyun_ has joined #bpwg
06:32:24 [MartinJ]
MartinJ has joined #bpwg
06:32:56 [MartinJ]
scribe: MartinJ
06:33:05 [MartinJ]
scribenick: MartinJ
06:34:02 [Seungyun_]
Seungyun_ has joined #bpwg
06:35:08 [Seungyun__]
Seungyun__ has joined #bpwg
06:37:50 [jcantera]
jcantera has joined #bpwg
06:38:00 [MartinJ]
Chaals: Opera will implement the recommendations. Will investigate hosting a CTTF meeting in Prague
06:38:25 [MartinJ]
... (Opera has an office there)
06:38:40 [MartinJ]
Jo: It would be an editor's meeting
06:38:56 [MartinJ]
... so would not need 8 weeks' notice
06:39:26 [MartinJ]
... thinking of a couple of weeks
06:39:55 [MartinJ]
Dan: There will be a MobileOK Pro editors's meeting in London about that time
06:40:11 [MartinJ]
06:41:14 [MartinJ]
06:41:50 [MartinJ]
Dan: will try to find out when
06:42:21 [MartinJ]
Dan: is there anythinh happening in the Korean Market that would help to inform the work of the CT Task Force?
06:42:36 [MartinJ]
... e.g. are any Korean operators implementing CT proxies?
06:44:17 [MartinJ]
Soonho: Yes SK implemented one last year. It is in-house software.
06:44:55 [MartinJ]
DKA: It would be very intersting to get some feedback on the CT document
06:45:11 [MartinJ]
06:45:23 [MartinJ]
ACTION: Soonho to provide feedback on CT document
06:45:23 [trackbot-ng]
Sorry, couldn't find user - Soonho
06:45:33 [francois]
q+ to note that W3C/ERCIM could host the editor's meeting if needed
06:45:48 [MartinJ]
ACTION: Soonho Lee to provide feedback on CT document
06:45:48 [trackbot-ng]
Sorry, couldn't find user - Soonho
06:45:59 [jo]
trackbot, list
06:46:09 [jo]
trackbot-ng, list
06:46:30 [jo]
trackbot-ng, list users
06:47:11 [MartinJ]
ACTION: soonho to provide feedback on CT document
06:47:11 [trackbot-ng]
Sorry, couldn't find user - soonho
06:47:41 [jo]
trackbot, status
06:47:50 [jo]
trackbot-ng, status
06:48:24 [DKA]
trackbot-ng, reload
06:48:37 [DKA]
trackbot-ng, status
06:49:01 [francois]
06:49:09 [jo]
ack j
06:49:31 [MartinJ]
Francois: If necessary ERCIM could host the editor's meeting
06:50:30 [jo]
ack f
06:50:30 [Zakim]
francois, you wanted to note that W3C/ERCIM could host the editor's meeting if needed
06:50:55 [MartinJ]
ACTION: Francois will organise the next CTTF Editors' meeting
06:50:55 [trackbot-ng]
Sorry, couldn't find user - Francois
06:51:16 [MartinJ]
Topic: BP2.0 Document
06:51:16 [jo]
>ACTION: daoust will organise the next CTTF Editors' meeting
06:51:35 [jo]
ACTION: daoust will organise the next CTTF Editors' meeting
06:51:35 [trackbot-ng]
Created ACTION-686 - Will organise the next CTTF Editors' meeting [on François Daoust - due 2008-03-10].
06:52:07 [MartinJ]
DKA: We should have a discussion to nail down the scope of the document
06:52:25 [MartinJ]
... this wil help to inform the review of the other documents
06:52:31 [MartinJ]
06:52:51 [MartinJ]
... including input from the Mobile Web 2.0 Forum (Korea)
06:53:15 [MartinJ]
... Bryan please take us through the current document including scope and sticking points
06:53:30 [MartinJ]
Jo: Let's do scoping first
06:55:08 [jo]
-> BP 2 Draft
06:55:42 [MartinJ]
Bryan: ref section 1.4 Scope..
06:55:58 [MartinJ]
... doesn't attempt to recreate the same focus as BP1.0
06:56:26 [MartinJ]
... focuses on mobile web *applications*
06:56:45 [jo]
06:56:52 [MartinJ]
... not the client type or the specific content types
06:57:09 [MartinJ]
... keeping in the overall framework of web technologies
06:57:34 [MartinJ]
... focus on the browser as the main example of a web application "engine"
06:58:22 [MartinJ]
... there is ongoing discussion about the accessibility part (WCAG)
06:59:21 [francois]
06:59:23 [francois]
ack jo
06:59:28 [jo]
ack me
06:59:29 [MartinJ]
... the mobile environment hasn't changed dramatically but BP2 goes further to encompass more advanced technologies including both browser and non-browser based interaction.
06:59:48 [DKA]
07:00:02 [MartinJ]
Jo: should we spend more time talking about scope or just throw ideas around to find the appropriate ones
07:00:24 [chaals]
07:00:28 [DKA]
07:00:37 [MartinJ]
... problem is to define the basis on which we decide which to leave in or throw out
07:01:45 [MartinJ]
... what I think is that we should look at the Sondheim 7 points.
07:02:06 [chaals]
ack me
07:02:41 [jo]
-> Scope discussion
07:03:33 [MartinJ]
chaals: mostly agree with Jo, in that we should not spend too much time defining scope, but the term "web applications" is problematic. Should talk about more advanced technology rather than "web applications"
07:03:39 [Bryan_Sullivan]
07:04:10 [chaals]
s/advanced technology rather than/advanced technology as used to develop richer/
07:04:22 [MartinJ]
Dan: strongly agrees - there is a statement about "advanced web technologies" already in the document
07:04:35 [DKA]
07:04:37 [DKA]
ack bry
07:04:46 [MartinJ]
... so should we just describe what they are
07:04:50 [jo]
q+ to comment on the word advanced, which is time limited
07:05:09 [MartinJ]
Bryan: the current definition is deliberately non-prescriptive
07:05:48 [DKA]
ack jo
07:05:48 [Zakim]
jo, you wanted to comment on the word advanced, which is time limited
07:05:49 [MartinJ]
... it is an evolving thing.. not sure we can define too rigidly what an advanced web technology is
07:06:14 [MartinJ]
Jo: I agree but we are chartered only to look at certain things
07:07:36 [MartinJ]
... so we should make the point that some recommendations may apply to other types of technology. We should be reasonably comprehensive but not try to be comprehensive in areas that are out of scope
07:07:55 [MartinJ]
... e.g. Flash Lite would not be in scope
07:08:22 [MartinJ]
Bryan: But let's be careful not to be too prescriptive
07:08:33 [Rotan]
Are there criteria for deciding what is in scope? Apart from being a "Web technology", which is quite a lot these days.
07:08:51 [MartinJ]
Jo: we should be careful about the word "advanced"
07:09:10 [MartinJ]
DKA: looking for suggested non-controversial text..
07:09:35 [jo]
1. uses the Internet and the Web to access data,
07:09:37 [jo]
generally provided in XML form
07:09:38 [jo]
2. models the data on the client device in the form of a
07:09:40 [jo]
Document Object Model
07:09:41 [jo]
3. uses Cascading Style Sheets to presesent the data
07:09:43 [jo]
on the client device
07:09:45 [jo]
4. uses a scripting language (often ECMAScript or a
07:09:47 [jo]
derivative) to control the data and view on the client
07:09:48 [jo]
07:09:50 [jo]
5. can operate successfully on client devices which may move
07:09:51 [jo]
6. can be presented successfully on handheld client devices
07:09:53 [jo]
7. can operate successfully in a networking environment
07:09:54 [jo]
which may involve intermittent, relatively slow, and relatively
07:09:56 [jo]
expensive connectivity
07:10:54 [MartinJ]
Jo: Point 1 is obvious but should say "XML form or HTML form"
07:11:25 [MartinJ]
... or the other way around
07:12:13 [MartinJ]
chaals: a web technology may have its front end in XML or HTML but might be accessing its data in some other form. Would say "uses the web to access data".
07:12:30 [Rotan]
"can operate successfully on client devices that are designed primarily for use while moving or being carried"
07:12:56 [MartinJ]
... would say a "web application typically have many of the following characteristics" rather than "has to have 5 or more"
07:13:30 [MartinJ]
Jo: Let's put "(or any other format)" with an editor's note that it is still under discussion
07:14:19 [MartinJ]
... Point 2: it is significant that a web application is primarily declarative in form, which relates to the DOM
07:15:02 [MartinJ]
DKA: a common practice is a procedural application that creates a DOM
07:15:45 [MartinJ]
chaals: centrality of the DOM is key, not declarative/procedural form
07:16:27 [MartinJ]
Jo: Point 3. May or may not use CSS per se but uses the same model to manipulate the DOM
07:16:40 [MartinJ]
chaals: Use of CSS is a common feature
07:17:00 [MartinJ]
jo: don't want to excude apps that don't use CSS
07:17:31 [MartinJ]
chaals: typical web applications use CSS, DOM, HTTP, etc. These are indicative characteristics
07:17:51 [MartinJ]
DKA: would go with "uses CSS for styling"
07:18:32 [Rotan]
As opposed to "using CSS for security" perhaps? ;)
07:18:39 [wonsuk]
wonsuk has joined #bpwg
07:19:19 [MartinJ]
Jo: Point 4 - seems pretty central. Only worry is that we are talking in general about offering autonomous control to the client - should be talk about ECMAscript in particular
07:19:39 [MartinJ]
chaals: so "uses a client-side scripting language"
07:20:19 [MartinJ]
Jo: so what the ECMAscript achieves is autonomous user interaction and autonomous network communication
07:21:06 [MartinJ]
DKA: could use "generally uses ECMAscript", etc.
07:21:32 [chaals]
s/language"/language, typically ECMAscript for autonomous behaviour in the client"/
07:21:56 [Rotan]
5. "can operate successfully on client devices that are designed primarily for use while moving or being carried"
07:22:09 [jo]
5. can operate successfully on client devices which may move
07:22:23 [Bryan_Sullivan]
offers autonomous interaction with the user and network, typically by use of a scripting language (often ECMAScript or a derivative)
07:22:42 [chaals]
[/me suggests "can operate successfully on mobile devices"]
07:22:43 [Bryan_Sullivan]
previous one was edited as "uses Cascading Style Sheets properties for styling"
07:22:44 [Rotan]
I can move my server. It's not really a mobile device though, is it?
07:23:22 [Rotan]
Something that is designed primarily for use while moving would generally have a small screen. It's a natural inference.
07:23:31 [Rotan]
You don't need to say it.
07:23:36 [DKA]
07:23:44 [Rotan]
Yes, Jo, from the charter.
07:24:16 [Rotan]
Yes, I agree Jo.
07:24:33 [MartinJ]
Jo: the bit that is missing is that a user's context may be significantly different from time to time
07:25:25 [rob]
"can operate successfully on client devices that are designed primarily for use while moving or being carried"
07:25:38 [MartinJ]
Bryan: is the point "contextual variance"?
07:26:01 [Rotan]
"for use while moving" says a little about contextual variance.
07:26:11 [jo]
can operate successfully on client devices that are designed primarily for use while moving or being carried and where the user can be expected to be in a range of different contexts
07:26:25 [Rotan]
That looks like good text to me.
07:26:28 [DKA]
07:26:40 [Bryan_Sullivan]
OK, replaced that one
07:27:04 [Rotan]
(You don't really need the "a range of")
07:27:31 [MartinJ]
DKA: Point 6 is redundant
07:27:54 [Rotan]
Automotive Web device is not handheld.
07:28:06 [jo]
7. can operate successfully in a networking environment
07:28:08 [jo]
which may involve intermittent, relatively slow, and relatively
07:28:09 [jo]
expensive connectivity
07:28:40 [Rotan]
The point is that the device moves around. Either it just moves (i.e. you move with it) or you carry it (i.e. it moves with you).
07:28:56 [MartinJ]
DKA: Point 7 - important to cover the network issues specifically as these issues are important
07:29:04 [Rotan]
No. 6 is redundant.
07:29:36 [Rotan]
If it is designed for use while moving, you can infer that the i/o is limited.
07:29:50 [Rotan]
Unless you like carrying your plasma TV.
07:30:03 [DKA]
07:30:20 [Rotan]
Let's not worry about the edge cases.
07:30:42 [MartinJ]
DKA: Point 7, want to change "networking" to "networked"
07:30:52 [Rotan]
"relatively expensive" means relative to what exactly?
07:31:44 [Rotan]
Could just say "expensive".
07:31:52 [MartinJ]
DKA: relative to desktop broadband access
07:32:05 [join]
join has joined #bpwg
07:32:13 [Rotan]
The expense could be cost, or could be use of scarce resources (e.g. bandwidth).
07:32:15 [MartinJ]
Bryan: Key point is "limited resources"
07:32:42 [DKA]
07:33:27 [MartinJ]
DKA: likes the "limited resources" term
07:33:28 [wonsuk]
wonsuk has joined #bpwg
07:33:47 [DKA]
07:34:14 [JonathanJ]
I'd like to suggest this sentence: "can be supported the best mobile web user experience" - phone OEM function call, Touch web interface, Gesture web interface
07:34:54 [MartinJ]
Jo: how about "resource constrained environment with consequent impact on the user"
07:36:08 [MartinJ]
DKA: I think "expensive" is an appropriate word for this
07:37:03 [DKA]
07:37:20 [jo]
can operate successfully in a resource constrained networked environment with consequent impact on user experience, delay and cost
07:38:25 [jo]
can operate successfully in a intermittently connected resource constrained networked environment with consequent impact on user experience, delay and cost
07:40:06 [MartinJ]
Jo: Jonathan can we broaden your statement to include making use of mobile features, eg. touch screen
07:44:28 [Seungyun__]
Seungyun__ has joined #bpwg
07:55:45 [francois]
Scribe: Francois
07:55:49 [francois]
ScribeNick: francois
07:57:39 [Seungyun__]
Seungyun__ has joined #bpwg
07:58:17 [francois]
Jo: Let's take up Jonathan's suggestion and take a look at it
07:58:22 [jo]
I'd like to suggest this sentence: "can be supported the best mobile web user experience" - phone OEM function call, Touch web interface, Gesture web interface
07:58:29 [Rotan]
Watch out for the backgound music!
07:58:31 [jo]
^^ from Jonathan
07:58:40 [Rotan]
07:59:16 [francois]
Bryan: the use of mobile features.
07:59:52 [francois]
DKA: I think something about mobile device "capabilities" would be good
08:00:34 [jo]
Can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces
08:00:38 [francois]
Bryan: so... the web applications that are designed to exploit mobile device capabilities?
08:00:39 [Rotan]
The unique and specific features associated with mobile devices.
08:00:46 [Bryan_Sullivan]
Prefix to the list "Web applications considered in scope for BP2 typically have many of the following characteristics:"
08:01:29 [abel]
abel has joined #bpwg
08:01:53 [Seungyun__]
Seungyun__ has joined #bpwg
08:01:55 [francois]
DKA: to have something consistent with that heading, something that uses mobile device capabilities
08:02:26 [jo]
Can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces and has a camera
08:03:15 [Rotan]
"various modes of input and data gathering"
08:03:21 [francois]
DKA: I would go for "use of a camera", comma, etc etc
08:03:47 [jo]
Can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces and has a camera
08:03:59 [jo]
and yada yada yada
08:04:16 [francois]
Jo: [yada-ing]
08:04:58 [DKA]
08:05:34 [francois]
DKA: OK, that concludes our discussion
08:05:48 [francois]
RRSAgent, draft minutes
08:05:48 [RRSAgent]
I have made the request to generate francois
08:06:27 [francois]
Bryan: next paragraph in the Scope section is mostly taken from BP1
08:07:47 [francois]
... I thought it was an important clarification of the focus
08:08:00 [francois]
... Focus is on the content and the applications themselves
08:08:32 [francois]
DKA: We should also say we're not telling "use Java, HTTP, ...".
08:08:47 [francois]
Jo: I think we should remove the ref to WCAG
08:09:10 [francois]
... First sentence is important. The rest should go.
08:09:55 [francois]
... but at some point we'll probably have to put ref to WCAG, internationalization rec and the like
08:11:12 [francois]
Bryan: I left the ref to the Scope document
08:11:29 [francois]
... A more detailed consistency revue would be good
08:12:08 [jo]
ACTION: rabin to raise issue on currency of the Scope document ref whether it should be reference drom BP2
08:12:08 [trackbot-ng]
Created ACTION-687 - Raise issue on currency of the Scope document ref whether it should be reference drom BP2 [on Jo Rabin - due 2008-03-10].
08:12:36 [francois]
... Then, 1.4.1 lists a set of practical criteria which may not be that practical
08:12:36 [jo]
08:12:53 [francois]
... Here's the list:
08:13:13 [francois]
- recommendations that are considered essential for successful deployment of web applications in common delivery contexts
08:13:28 [francois]
- recommendations are considered of fundamental importance to growth in the mobile web application market
08:13:36 [francois]
... which is a bit more fluffy
08:13:43 [jo]
ack me
08:13:49 [francois]
- recommendations that can be readily verified through compliance testing, either automated (preferred) or manual
08:14:02 [francois]
... Are we going to make recommendations that cannot be testable?
08:14:29 [francois]
Jo: We did have that discussion before, and decided testability was not a necessary criterium for the best practices
08:14:58 [francois]
... It would be consistent with BP1 to continue like this
08:15:17 [Rotan]
Thinking out loud: would it be useful to reference the recent work on the relationship between MW and Accessibility?
08:15:44 [francois]
... About the previous 2 points...
08:15:49 [chaals]
08:15:59 [francois]
... first, maybe not essential, rather good practice
08:16:15 [francois]
... I think the statements are both overstated
08:16:48 [francois]
Bryan: my point was there are probably many things we could write about
08:16:58 [jo]
q+ to comment on the work "great"
08:17:13 [francois]
... we need to be careful to draw a line between what would be useful and what is useful
08:17:16 [jo]
ack cha
08:17:22 [DKA]
08:17:47 [francois]
chaals: I agree with Jo, not "essential", rather "are going to improve"
08:18:10 [francois]
... some best practices should be something like "It's always worth doing this"
08:19:02 [francois]
... Second point, I was trying to understand what it really really means.
08:19:26 [jo]
a) its common practice that is harmful in our scope
08:19:27 [jo]
b) it would improve the experience in our scope but is rarely practices
08:19:28 [francois]
... A BP leads in an improvement in user experience
08:19:29 [jo]
c) it is in scope
08:19:46 [francois]
s/in an/to an
08:20:25 [Rotan]
Actually, an overall improvement. Some best practices (such as the hoops we have to go through to protect sensitive info) can be a nuisance in the experience, but overall are beneficial.
08:21:55 [francois]
DKA: I would qualify b) by saying it would improve user experience in our scope, but we need to find some quantified way to measure that such as "is implemented in a certain number of sites"
08:22:00 [francois]
Jo: Yes, it must exist
08:22:03 [francois]
DKA: right
08:22:18 [Rotan]
Thinks Dan's idea sounds nice, but could be open to challenge for being too subjective.
08:22:52 [DKA]
Subjectivity is objective.
08:23:24 [francois]
Bryan: I'll paste the 3 points I'm getting
08:23:30 [Bryan_Sullivan]
will improve chances of successful deployment for web applications in common delivery contexts
08:23:35 [DKA]
-Woody Allen
08:23:45 [Bryan_Sullivan]
if they address a specific mobile aspect
08:24:32 [francois]
Jo: On wording, I would prefer "refer to the mobile context"
08:24:50 [francois]
Bryan: yes, but it seems too generic
08:25:12 [Bryan_Sullivan]
if they are relevant but not limited to the mobile context
08:25:34 [Bryan_Sullivan]
if they are relevant to the mobile context
08:25:43 [jo]
08:25:45 [Bryan_Sullivan]
is implemented and recommended as a best practice
08:26:41 [francois]
DKA: do we want to precise the number of implementations?
08:26:55 [francois]
chaals: 2-3, that's nothing on the Web, so no
08:26:57 [Rotan]
And "enduring", meaning that where implemented, it tends to stay there and continue to be used.
08:27:40 [Bryan_Sullivan]
is implemented and recommended for broader use
08:27:49 [francois]
Jo: 2 things, one to include: if we find something not commonly implemented but useful
08:28:39 [Bryan_Sullivan]
1) will improve chances of successful deployment for web applications in common delivery contexts
08:28:47 [Bryan_Sullivan]
2) if they are relevant to the mobile context
08:28:55 [Bryan_Sullivan]
3) is implemented and recommended for broader use
08:29:08 [francois]
... One thing that seems to be missing is we're not saying anything about what people do today that is harmful
08:30:19 [Rotan]
Could be many reasons for something good not to be commonly implemented: it's hard to do, it's patented up to its eyeballs, it's very very new, it only works on certain platforms, the expert hasn't written the O'Reilly book yet, etc.
08:31:23 [DKA]
..or it hasn't had the stamp of approval from the W3C Mobile Web Best Practices working group.
08:31:23 [francois]
chaals: if we say "don't do something", then it meets our criteria and there's no need to create another use case
08:32:27 [Bryan_Sullivan]
promote avoidance of techniques considered harmful
08:33:01 [francois]
chaals: let's say you have a BP that says "don't write bad apps" (just an example).
08:33:07 [francois]
... it meets our criteria
08:33:13 [francois]
... so no need to add that criterium
08:33:18 [Rotan]
In some cases, doc.w can be faster than parsing a load of markup. generating complex tables for data, for example. But *in general* it might not be a good idea. Needs more testing to get hard data.
08:33:46 [francois]
Jo: I take your point, but still consider it useful.
08:34:15 [francois]
Bryan: alright, I'll make a note with that.
08:34:20 [DKA]
Updated agenda here: * Review Apple document
08:34:20 [DKA]
* Review Univ of Helsinki masters thesis on Mobile Ajax performance
08:34:20 [DKA]
* tel: URI (and other URI schemes)
08:34:20 [DKA]
* Review Frost Ajax library
08:34:21 [DKA]
* Korean input on BP 2.0 document (1 hr)
08:34:27 [DKA]
08:34:34 [Bryan_Sullivan]
will improve chances of successful deployment for web applications in common delivery contexts, by promoting adoption of good techniques and avoidance of techniques considered harmful
08:34:43 [DKA]
Trying again: Updated agenda here:
08:35:03 [francois]
Jo: Yes, that captures it nicely for me
08:35:08 [francois]
Bryan: OK
08:35:10 [jo]
08:35:16 [DKA]
08:35:25 [jo]
+1 to Dan's +1
08:35:41 [francois]
chaals: successful deployment?
08:35:54 [francois]
Bryan: yes, softening of my previous "essential" statement
08:36:09 [Rotan]
For many these days, successful simply means it makes you lots of profit.
08:36:17 [DKA]
+2 to JO'S +1 of my +1
08:36:41 [Bryan_Sullivan]
will improve web applications in common delivery contexts, by promoting adoption of good techniques and avoidance of techniques considered harmful
08:36:42 [jo]
making a profit is important to the ecosystem
08:36:56 [Rotan]
Plenty of rubbish apps out there making a load of money. Lack of decent competition in many cases.
08:36:59 [francois]
chaals: yes, that actually looks good to me
08:37:26 [francois]
Bryan: 1.5 and 1.6 are templates
08:37:57 [francois]
... Follow in the steps of BP1, period. OK?
08:38:22 [francois]
Jo: I think we can continue to have this note on DIWG, except we have to rename it to UWA
08:38:43 [francois]
08:39:30 [francois]
08:41:42 [francois]
Bryan: 20mn left, let's go through the requirements
08:42:11 [francois]
... What I have in the requirements is I got requirements structures around a number of aspects.
08:42:40 [francois]
... There was this whole list we came up with in an email. So I took it and broke it up in sections
08:43:17 [francois]
... Now the list is down at the end of the document
08:44:06 [francois]
Jo: Are we skipping Requirements?
08:44:28 [francois]
Bryan: no, but Dan wanted to go the Tel Uri thing
08:45:01 [francois]
Jo: OK, I think the requirements need some more work
08:45:16 [francois]
... Personalization, Security and privacy are not mobile-specific
08:45:40 [francois]
DKA: I think the most valuable to spend our time is to take a look at BPs
08:46:18 [francois]
... so I would start with tel URI because I had the feeling it was not controversial
08:46:48 [francois]
Bryan: OK, so about section 5
08:47:33 [DKA]
08:47:41 [francois]
... the BP is to use URI schemes (tel, sms, wtai, mailto)
08:47:59 [francois]
DKA: I don't think we can give all of these things equal weight
08:48:04 [jo]
ack dka
08:48:20 [francois]
... Is sms: implemented, sip: implemented?
08:48:40 [francois]
... I know tel: is implemented, more than the rest at least
08:49:17 [francois]
Jo: Use Uri schemes when they are known to be supported
08:49:29 [francois]
DKA: that gets a bit wishy washy, doesn't it?
08:49:37 [Bryan_Sullivan]
08:50:07 [francois]
Jo: The advice's got to be: find what schemes are supported and use them
08:50:56 [DKA]
08:50:59 [DKA]
\ack jo
08:51:00 [DKA]
ack jo
08:51:00 [Zakim]
jo, you wanted to comment on the work "great"
08:51:26 [DKA]
q+ to suggest we need specific best practices addressing each of tel:, wtai:, -- specific BPs are more useful to developers.
08:51:33 [DKA]
ack jc
08:51:37 [francois]
Jo: We should include wtai, sms, tel... even if they are not properly standardized
08:52:06 [Bryan_Sullivan]
SMS URI scheme draft
08:52:35 [francois]
Jose: the point is not recommending the use of URI schemes but when.
08:53:02 [DKA]
08:53:04 [francois]
DKA: when you're presenting a number that you want the user to call, use tel:
08:53:05 [DKA]
ack brya
08:53:35 [francois]
Bryan: to capture this... when you intend to specifically have the user make a phone call, use this
08:53:44 [jo]
Where possible use formal hyperlinks for non-Web actions.
08:55:11 [francois]
Jo: we should not restrict to "tel:" as Bryan says
08:55:31 [Bryan_Sullivan]
08:55:33 [francois]
DKA: from the developer's point of view, use schemes is a completely useless statement
08:56:08 [francois]
... I think we got a lot of feedback on BP1 saying that BPWG knew what they mean but not the person that reads the doc
08:56:31 [francois]
... I would like us to err on the side of these statements be simple
08:56:33 [jo]
Where possible use hyperlinks to indicate actions such as initiating a phone call
08:56:54 [chaals]
08:56:58 [DKA]
08:57:01 [jo]
ack d
08:57:01 [Zakim]
DKA, you wanted to suggest we need specific best practices addressing each of tel:, wtai:, -- specific BPs are more useful to developers.
08:57:14 [DKA]
ack bry
08:57:18 [francois]
Bryan: I added to Jo's statement a prefix.
08:57:54 [jo]
08:57:55 [Bryan_Sullivan]
Where possible use formal hyperlinks for non-Web actions. Given that the device is often also a telephone, use of such URI schemes help the user to use non-web capabilities in a range of applications such as listings, contact and so on.
08:58:01 [DKA]
08:58:25 [DKA]
ack cha
08:58:27 [francois]
DKA: I don't think techie is the problem
08:58:36 [francois]
chaals: I'm with Dan
08:58:59 [francois]
... Basically, if we say "use formal hyperlinks for non-Web actions", the guys would just say "whatever..."
08:59:02 [jo]
Where possible use hyperlinks to indicate actions such as initiating a phone call
08:59:17 [francois]
... BPs should be a short simple sentence that makes sense
08:59:37 [francois]
... Use tel: wtai: for phone calls. Period.
08:59:48 [francois]
... and refine it in "What it means?"
09:00:38 [francois]
Jo: I take all the points on board, but I also think they need to be accurate
09:01:10 [francois]
... if we say use tel: wtai: brackets whatever other URI schemes you know the phone supports, then we haven't done much
09:01:32 [francois]
... The point is about what the user wants to do
09:01:54 [francois]
... mention something such as wtai: or tel: in the short description line is too specific
09:01:59 [francois]
DKA: I disagree.
09:02:05 [francois]
Jo: you'll want to add sms:
09:02:11 [Bryan_Sullivan]
09:02:12 [francois]
DKA: we'll have another BP!
09:02:35 [DKA]
09:02:55 [francois]
Jo: Our motivation is "if you want the user to perform an action, then hyperlink it for god's sake!"
09:02:59 [DKA]
ack jo
09:03:10 [DKA]
ack bry
09:03:10 [jo]
ack me
09:05:35 [francois]
DKA: why don't we leave it to Bryan to work on this and call it a day?
09:06:51 [francois]
RRSAgent, draft minutes
09:06:51 [RRSAgent]
I have made the request to generate francois
09:08:26 [rob]
rob has left #bpwg
09:09:29 [soonho]
soonho has left #bpwg
09:11:06 [jo]
09:11:20 [Seungyun__]
Seungyun__ has joined #bpwg
09:11:23 [Rotan]
Rotan has left #bpwg
09:15:01 [Seungyun__]
Seungyun__ has joined #bpwg
09:33:12 [francois]
francois has joined #bpwg
10:32:13 [abel]
abel has left #bpwg