See also: IRC log
<DKA> SL: First time having a W3C meeting in Korea.
DKA: for BP2, propose to use the
sessions for live editing
... BP2 will likely spill over to 2nd day
... any other changes to agenda?
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.
<JonathanJ> sunghan
<francois> CT draft
Francois: update on the status,
overview of goals
... 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
... So W3C started a program to set expectations on CT proxy
behavior
... After a year, we need decisions, e.g. on the scope re use of
new technologies e.g. new HTTP headers
... 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.
... "Summary of requirements" section is an overview for all
entities in the delivery chain.
... 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.
<jo> [note to editor to correct section 2.1 where it says HTTP between user and user agent
<jo> thanks to DKA and francois for pointing this out!]
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.
... "Types of Proxy" are what HTTP defines, included here to
establish the terms.
Jo: Wonders if we can revisit the decision on the CT entity being a "proxy".
<jo> [the proxy is indeed a proxy not a user agent extension or a gateway]
Francois: We do not view the CT proxy as an user-agent extension (masquerader), but as a simple intermediary.
Sean: Are we leaving the specialized client/'server solutions e.g. Opera Mini, out of the scope of these guidelines?
Jo: We are addressing how HTTP path entities should behave.
Francois: We could consider Opera
Mini as two different parts.
... Opera Mini is both.
Dan: It is a different animal, an integrated system built in a special way.
<Zakim> DKA, you wanted to suggest it is out of scope
<DKA> jo
<DKA> jo beep
Bryan: Opera Mini is an application with specialized behavior, and does not necessarily use HTTP.
<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
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.
Jo: We should ask Chaals about his
attitude on this.
... 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).
<jo> ACTION: Patterson to raise and issue on the distinction between a CT proxy and (say) Opera Mini [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action01]
<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].
Jose: Guidelines of the CT TF should cover all the cases including specialized cases and normal browsers.
Jo: Doesn't disagree, just wants to discuss it later.
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.
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.
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.
Francois: We don't mention those special types of transformation later.
<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]
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.
... Leaving "controlled by the server" as is for the time
being.
Francois: In Section 3, the most
common control is to use "no-transform" to affect CT proxy
behavior.
... We can't expect this from legacy browsers, but there could be
out-of-band arrangements to control the behavior.
Jo: Re section 3.1.1, we have an issue for the CT proxy to act transparently for non-browsers.
Bryan: Use of proxies for non-browsers is a common deployment, and must be addressed.
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.
Robert: Its a difficult problem, but does need to be addressed since all HTTP is likely going thru the proxy.
<Zakim> jo, you wanted to suggest that Martin and to add should take an action to express his point as a proposed text
<MartinJ> ACTION: Martin to propose text re browser identification: para 2 of sectio 3.1.1 [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action02]
<trackbot-ng> Sorry, amibiguous username (more than one match) - Martin
<trackbot-ng> Try using a different identifier, such as family name or username (eg. mharris2, mjones4)
Jo: Suggests that Martin take an action to propose text for 3.1.1 based upon the discussion,
<jo> ACTION: Jones to propose text for para 2 of 3.1.1 [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action03]
<trackbot-ng> Created ACTION-679 - Propose text for para 2 of 3.1.1 [on Martin Jones - due 2008-03-10].
Francois: Moving on to 3.1.2 "proxy decision to transform", these are the ways the proxy can know what to do.
Jo: As editor, unclear how to take the section forward.
Francois: It's just a collection of options on how to control the behavior.
Rob: It's a SHOULD, thus there is a list of things to consider, and the overall is helpful.
Francois: About the editorial note, its similar to what we would write if we were considering the browser extension role for the CT proxy.
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.
Jo: Not altering the headers is mandated unless its essential to what the user wanted.
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.
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.
... Not convinced there is a real problem to be mentioned here.
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
Bryan: See this as a corner case, not a normal proxy behavior, and maybe something for specialized service access.
Francois: Suggests we ask Aaron for more input,.
Jo: We could say that the body should not be altered unless there is a specific mobile use case being addressed.
Rob: The proxy may modifying a form as needed, e.g. to break a page into subpages.
Francois: How does that work in practice, e.g. the pages and form functions are split up?
Rob: Yes, that's how it happens.
Ron: The handset sent form may be modified by the CT proxy if necessary for adapting the page.
Francois: Other notes need to be considered re breaking a page into subpages which are locally served by the proxy.
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).
<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.
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.
Dan: Would like to see if any CT discussions we are having resonates for the Korean market, and what input they will have.
<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... :)
<jo> [coffee break]
<DKA> Scribe: Dan
<DKA> ScribeNick: 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.
... So you're basically changing the form on the way down and
changing it back to the original on the way up.
<jo> [francois asks for examples of this behavior]
Francois: could we have an example of that?
Sean: I think we can do it.
Rob: I could do a pseudo-code example.
<jcantera> jcan'ttera has joined #bpwg
Francois: to see what's being done in practice
<scribe> ACTION: Rob to provide a pseudo-code example of form transformation for CT document. [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action04]
<trackbot-ng> Sorry, couldn't find user - Rob
<jo> ACTION: finean to provide a pseudo-code example of form transformation for CT document. [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action05]
<trackbot-ng> Created ACTION-680 - Provide a pseudo-code example of form transformation for CT document. [on Robert Finean - due 2008-03-10].
Jo: We need more text - we need something from Aaron.
<jo> ACTION: daoust to ask aaron kemp for clarification of the character encoding issue [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action06]
<trackbot-ng> Created ACTION-681 - Ask aaron kemp for clarification of the character encoding issue [on François Daoust - due 2008-03-10].
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.
... 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.
... 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.
... My POV on that would be to forget the HEAD requests.
... 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].
... 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.
... 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.
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.
<Rotan> This is the case for Apache.
Francois: You want to check that a HEAD request would be processed on the server as if it were a GET request.
<Rotan> Apache generates the content, then throws it away as it responds to HEAD.
Jo: Yes - Although we probably need to kick this one upstairs to the TAG.
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...
<scribe> ACTION: Francois to write some simple tests for well-known server environments for how they deal with HEAD requests. [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action07]
<trackbot-ng> Sorry, couldn't find user - Francois
<Zakim> jo, you wanted to explain why the HEAD request is there
<Rotan> WSGI systems replace HEAD with GET when passing on requests.
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.
Bryan: Are we assuming that the head request is coming from the client?
Francois: No it's from the proxy.
Bryan: because HEAD requests sometimes do come from the client - should the CT proxy simply pass these through?
<Rotan> See 3. at http://groups.google.com/group/modwsgi/msg/289730b262df5bca
Jo: That's an open question.
Bryan: What's the intervention in the case of HEAD then?
Francois: CT proxy with a HEAD request - it should do nothing on a HEAD request - just add the VIA header.
<Rotan> Please read 3. on the link above.
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.
Francois: I don't think the CT proxy should do anything with a HEAD request.
Bryan: Other than potentially changing the user agent header - to maintain consistency.
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.
<Rotan> I agree. Have observed HEAD/GET equivalence in many Web servers.
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.
... I think the two-phase approach - tasting the content - is
beneficial.
Francois: The cool thing about about that is we wouldn't need to change the user agent.
Rob: There's still the business about tokenizing URLs so you might change requests just not user agents.
Martin: I'd like to echo what Rob
said about the two-phase approach [content tasting].
... 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.
... So there's a valid use case for converting a HEAD into a GET in
the proxy.
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).
... Are you saying it would be the optimized form the user agent
would store?
Martin: yes.
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.
Martin: right.
Bryan: But the statefulness effect of issuing a GET could be signifigant.
Martin: the CT proxy could help do this by not issuing another GET request when the user agent actually did GET the content.
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.
... This should be in scope - we need to do something about such a
comon case.
DKA: Let's try to bottom out the first discussion and action someone to write a proposal on the HEAD issue.
<Rotan> http://osdir.com/ml/apache.mod-perl/2003-01/msg00192.html
<scribe> ACTION: Martin to write a proposal on the HEAD request handling. [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action08]
<trackbot-ng> Sorry, amibiguous username (more than one match) - Martin
<trackbot-ng> Try using a different identifier, such as family name or username (eg. mharris2, mjones4)
<scribe> ACTION: Martinj to write a proposal on the HEAD request handling. [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action09]
<trackbot-ng> Sorry, couldn't find user - Martinj
<scribe> ACTION: Martin Jones to write a proposal on the HEAD request handling. [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action10]
<trackbot-ng> Sorry, amibiguous username (more than one match) - Martin
<trackbot-ng> Try using a different identifier, such as family name or username (eg. mharris2, mjones4)
<scribe> ACTION: Jones to write a proposal on the HEAD request handling. [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action11]
<trackbot-ng> Created ACTION-682 - Write a proposal on the HEAD request handling. [on Martin Jones - due 2008-03-10].
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.
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.
Francois: Yes if that's what we agree.
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.
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/
<Rotan> You can force a 406 on Apache with a particular pattern in POSTed HTML when mod_security is present in its default config.
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.
Jo: I think that this case is carved
out above [in the Note above]
... 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.
<Zakim> jo, you wanted to add wondering if the two approaches can work in parallel
<Rotan> +1 to Martin
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.
... 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.
<Kangchan> s/besice/beside/
Jo: We need to come back to a point - about the a priori knowledge it has of server preferences.
<Zakim> jo, you wanted to wonder if the two approaches can work in parallel
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.
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.
Jo: Just because it's one web doesn't mean you don't have varrying representations.
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.
Jo: It could be easily
extended.
... I don't think it's harmful but I don't know if it would be
useful.
... send the alternative user agent as the alternative...
DKA: [speaks in support of sending the dual headers]
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.
Sean: Why is it necessary to know how the decision was made.
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.
Sean: you could always put them in though.
Jo: good point.
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.
Francois: I agree with Bryan.
<jo> PROPOSED RESOLUTION: Under 3.1.2 drop the HEAD request
<MartinJ> +1 to Bryan
Francois: We agree with what is written here except for the HEAD request.
Jo: We should probably still have a justification for having removed it [but I suggest we remove it anyway.]
<rob> +1
<francois> +
<MartinJ> +1
<francois> +1
<SeanP> +1
<jo> RESOLUTION: Under 3.1.2 drop the HEAD request
<Rotan> (Just observing, but I also agree)
Francois: 2 remaining points -
emphasis on a priori knowledge
... should we say something about a request to a URI may mean
something about a request of a document "close to" that URI.
<Rotan> What does "close to" mean?
<Rotan> URIs are supposed to be opaque.
Jo: We should move on to that - what inference could be made...
<Rotan> www.example.com/?id=12345
<Rotan> I could build a whole set of sites all using that example URI.
<Rotan> You have NO WAY to know what is or is not close.
<Rotan> You cannot assume that a URI has a "path" in it.
<jo> jo points out the authentication model which contradicts Rotan
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.
<Rotan> Respectfully disagree.
DKA: I think the concept of user session comes into it.
Jo: Um
... 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...
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.
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."
... 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.
... the service provider should know what sites are sensitive - for
example regexp-specified URIs.
Jo: both Rob and Martin said thought that inferences of a sort could be made - the question remains open what are those inferences.
Rob: They are - that there either is a mobile edition suitable for the user agent or there isn't.
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?
... 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 other a
priori information.
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.
Bryan: I agree - the non CT-aware servers are the richest use case.
Jo: From the POV of the guidelines to CT proxies, what inferences are reasonable to make?
<scribe> Scribe: Rob
<scribe> ScribeNick: rob
Francois: I've no answer and we definitely need one...
<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 [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action12]
<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].
Bryan: eg if I request content in 2 forms and my hand gets slapped in 2nd form, what should I infer?
Francois: eg example.com/x and then example.com/x/y -- are they really connected?
<Rotan> (Has anyone ever considered the HTTP 1.1 "OPTIONS" request? It was designed to be extensible.)
<Rotan> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2
Sean: it's possible a solution works for all - but it's more likely vendors will come up with different solutions
Jo: if we want to tell CT-aware content something then perhaps POWDER is the answer
Bryan: what's the advantage of
inferring future behaviour?
... minimising n of hits? making it work at all?
Jo: specifically it's bullet "any a priori knowledge"... in sec 3.1.2
Bryan: and might we note the a priori knowledge is user-specific
Dan: and note it could be vendor-specific and needn't be detailed too much here
Bryan: most valuable a priori
knowledge will be pre-configured by operators and vendors
... and by content authors with POWDER
Sean: I don't see a particular way to describe this other than say it's up to vendors
Dan: 2 specific use-cases come to
mind:
... one is you think you know about a website then a different
User-Agent works differently
<Rotan> +1 to Dan (we're seeing demand for iPhone-specific responses)
<jo> [The server should have a vary:* in that case, Dan]
Dan: (eg iPhone-aware site)
... the other one is where the user has a "mobile/desktop edition
preference" that the origin server knows about but the CT proxy
doesnt
<Rotan> The "vary" should indicate all the headers upon which it made its response decisions.
<jo> or *
s/that the origin server has no knowledge of/with the ORIGIN website
<Rotan> But user prefs might be outside of the HTTP interaction. E.g. customer-specific knowledge held in an Operator's database.
scribe: a user preference with the origin website that the CT-proxy has no knowledge of
<Zakim> jo, you wanted to sya that surely this is a general caching problem
Martin: we should conentrate on a set of warning notes instead of a description of how it works
Jo: how about an informational point
about this is what you can expect a CT-proxy to do
... and note the issue of cachability is generally appliccable
Bryan: at the very least this is inferred on a User-Agent by User-Agent basis
<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]
Martin: it's appropriate other CT-vendors outside this WG will be interested in these guidelines
Jo: agree with Martin, the level of discussion indicates it isn't obvious
<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]
Francois: on to sec 3.1.3
... and talking about POWDER
<DKA> I wanted to highlight a newly-lauched mobile web site - m.linkedin.com - 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.
Francois: according to HTTP the
CT-proxy must add a Via header
... and we can reference a URI to describe CT capabilities in the
Via string
... POWDER is only a 1st working draft at present
... but sounds like it will be an ideal format to use
... Question is does anyone know enogh to define this guideline
yet?
Dan: does it make sense to wait until POWDER is more ground?
Sean: it seems to make the Via
information useful you need to go into some detail about
capabilities
... so fact it is a moving target is a problem
Bryan: isn't it helpful just to know
there is a CT-proxy in the 1st place?
... even with no additional knowledge of its exact
capabilities?
... maybe we're getting ahead of ourselves trying to define a
capabilities specification yet
<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,
<Zakim> jo, you wanted to say that we should avoid repeating UA PROF
Jo: we shouldn't repeat the UAprof style of specifying a URI and saying "go figure"
<Rotan> The "here be dragons" flag.
<jo> [adjourn for lunch]
<SeanP> scribenick: SeanP
<scribe> scribe: SeanP
DKA: m.linkedin.com does a lot of the
MobileOK stuff
... m.linkedin.com does a lot of the MobileOK stuff
Francois: Before lunch we said that
maybe only a flag that CT was taking place was necessary.
... I tend to think that a URI is kind of harmless and would be a
good thing.
Bryan: The parameter would represent a flag.
Francois: The question about Powder still exists but we'll come back to that. The POWDER description may not be needed for now.
Francois: 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.
Rob: That my be too far. Mandating that the first request has the original UA is too much.
Francois: That's what we said earlier. I don't see the reason to provide the original headers in the second request.
Rob: I don't see why we should prohibit sending the original headers.
Jo: There may be administrative
arrangement between user and operator--the content provider still
needs to get the original header values.
... In some cases it will have sent the original headers but not
all cases.
Francois: In that case we need to
find a way to provide the original headers.
... The main point is the UA header. Not too many possible ways to
do that. Need to use a new header.
Bryan: Are we just talking about the Accept headers.
Francois: Talking about UA and Accept.
Bryan: Sometimes UA Profile header is
changed. Going down the path of providing original headers gets
into the new technology territory.
... 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.
Jo: A chicken and egg situation. Not providing original headers removes incentive to make mobile sites.
<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.
Martin: Mobile content providers use headers for statistics, etc. Seems like a good idea to provide original headers.
Bryan: Simply suffixing the original
UA header to the end of the new UA is common technique for WAP
gateways.
... Saying a request comes from 2 different user agents will
confuse content providers.
... 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.
Rob: Agree. Two UAs in a request could confuse Content servers.
Francois: Hard to append original headers to end of existing headers. Need to create new header.
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.
Francois: Could add a new header that has all of the original information that we need.
Jo: There are no good answers. Need the least bad answer. A possibility is to include a URI to the original headers.
Bryan: Put a content-type in the message body. That's lighter weight.
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.
... Could look at things that are added downstream from CT
proxy.
Sean: Could put original headers in Via header.
Francois: That sounds dirty.
<jo> ACTION: Jo to include a note that we think it is bad practice to strip the comment from downstream via header fields [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action13]
<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].
Rob: If you change the header provide the original, otherwise don't worry about it. Provide the original header in Original-xxx.
Martin: Use the Warning header--can be used in requests.
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.
<Rotan> Are CT chains in scope? Could be a very tricky issue, as hinted at by Jo.
Bryan: Are we addressing efficiency here?
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.
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.
<jo> HTTP mime types
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.
Jo: Should have investigatory actions on this topic.
Francois: Need everyone to look into this.
<Rotan> Could also introduce a security threat if the headers were available at a location external to the path between client and server.
<jo> good point Rotan
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
<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.
<DKA> brb
Jo: In HTTP spec the content type I was referring to is message/HTTP.
<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 [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action14]
<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].
Bryan: I was talking about application/External-Body.
Jo: Warning would at least provide an indication that headers have been modified.
Francois: Warning is a general
header--can be used in request.
... Can't take any resolutions yet. Need to settle the use of
POWDER in the response from the server.
... Do we want to use it? Need details for it to be useful. For now
we should just mention that POWDER could be used.
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.
Jo: We can't leave it to POWDER since
they aren't chartered for that.
... Not really part of the Delivery Context either.
... 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.
Francois: We're not ready to publish a first public working draft.
<wonsuk> zzz
<jo> s/.../server preferences /#
Jo: We can publish a FPWD with a dangling reference to POWDER.
Francois: I think that is OK.
<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.
<francois> +1
<jo> +1
<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.
+1
<MartinJ> scribe: MartinJ
<scribe> scribenick: MartinJ
Chaals: Opera will implement the
recommendations. Will investigate hosting a CTTF meeting in
Prague
... (Opera has an office there)
Jo: It would be an editor's
meeting
... so would not need 8 weeks' notice
... thinking of a couple of weeks
DKA: There will be a MobileOK Pro editors' meeting in London about that time
Dan: will try to find out when
... is there anythinh happening in the Korean Market that would
help to inform the work of the CT Task Force?
... e.g. are any Korean operators implementing CT proxies?
Soonho: Yes SK implemented one last year. It is in-house software.
DKA: It would be very interesting to get some feedback on the CT document
<scribe> ACTION: Soonho to provide feedback on CT document [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action15]
<trackbot-ng> Sorry, couldn't find user - Soonho
<scribe> ACTION: Soonho Lee to provide feedback on CT document [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action16]
<trackbot-ng> Sorry, couldn't find user - Soonho
<jo> trackbot, list
<jo> trackbot-ng, list
<jo> trackbot-ng, list users
<scribe> ACTION: soonho to provide feedback on CT document [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action17]
<trackbot-ng> Sorry, couldn't find user - soonho
<jo> trackbot, status
<jo> trackbot-ng, status
<DKA> trackbot-ng, reload
<DKA> trackbot-ng, status
Francois: If necessary ERCIM could host the editor's meeting
<Zakim> francois, you wanted to note that W3C/ERCIM could host the editor's meeting if needed
<scribe> ACTION: Francois will organise the next CTTF Editors' meeting [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action18]
<trackbot-ng> Sorry, couldn't find user - Francois
<jo> > ACTION: daoust will organise the next CTTF Editors' meeting
<jo> ACTION: daoust will organise the next CTTF Editors' meeting [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action19]
<trackbot-ng> Created ACTION-686 - Will organise the next CTTF Editors' meeting [on François Daoust - due 2008-03-10].
DKA: We should have a discussion to
nail down the scope of the document
... this will help to inform the review of the other
documents
... including input from the Mobile Web 2.0 Forum (Korea)
... Bryan please take us through the current document including
scope and sticking points
Jo: Let's do scoping first
<jo> BP 2 Draft
Bryan: ref section 1.4 Scope..
... doesn't attempt to recreate the same focus as BP1.0
... focuses on mobile web *applications*
... not the client type or the specific content types
... keeping in the overall framework of web technologies
... focus on the browser as the main example of a web application
"engine"
... there is ongoing discussion about the accessibility part
(WCAG)
... the mobile environment hasn't changed dramatically but BP2 goes
further to encompass more advanced technologies including both
browser and non-browser based interaction.
Jo: should we spend more time talking
about scope or just throw ideas around to find the appropriate
ones
... problem is to define the basis on which we decide which to
leave in or throw out
... what I think is that we should look at the Sondheim 7
points.
<jo> Scope discussion
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 as used to develop richer "web applications"
Dan: strongly agrees - there is a
statement about "advanced web technologies" already in the
document
... so should we just describe what they are
Bryan: the current definition is deliberately non-prescriptive
<Zakim> jo, you wanted to comment on the word advanced, which is time limited
Bryan: it is an evolving thing.. not sure we can define too rigidly what an advanced web technology is
Jo: I agree but we are chartered only
to look at certain things
... 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
... e.g. Flash Lite would not be in scope
Bryan: But let's be careful not to be too prescriptive
<Rotan> Are there criteria for deciding what is in scope? Apart from being a "Web technology", which is quite a lot these days.
Jo: we should be careful about the word "advanced"
DKA: looking for suggested non-controversial text..
<jo> 1. uses the Internet and the Web to access data,
<jo> generally provided in XML form
<jo> 2. models the data on the client device in the form of a
<jo> Document Object Model
<jo> 3. uses Cascading Style Sheets to presesent the data
<jo> on the client device
<jo> 4. uses a scripting language (often ECMAScript or a
<jo> derivative) to control the data and view on the client
<jo> device
<jo> 5. can operate successfully on client devices which may move
<jo> 6. can be presented successfully on handheld client devices
<jo> 7. can operate successfully in a networking environment
<jo> which may involve intermittent, relatively slow, and relatively
<jo> expensive connectivity
Jo: Point 1 is obvious but should say
"XML form or HTML form"
... or the other way around
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".
<Rotan> "can operate successfully on client devices that are designed primarily for use while moving or being carried"
chaals: would say a "web application typically have many of the following characteristics" rather than "has to have 5 or more"
Jo: Let's put "(or any other format)"
with an editor's note that it is still under discussion
... Point 2: it is significant that a web application is primarily
declarative in form, which relates to the DOM
DKA: a common practice is a procedural application that creates a DOM
chaals: centrality of the DOM is key, not declarative/procedural form
Jo: Point 3. May or may not use CSS per se but uses the same model to manipulate the DOM
chaals: Use of CSS is a common feature
jo: don't want to excude apps that don't use CSS
chaals: typical web applications use CSS, DOM, HTTP, etc. These are indicative characteristics
DKA: would go with "uses CSS for styling"
<Rotan> As opposed to "using CSS for security" perhaps? ;)
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
chaals: so "uses a client-side scripting language, typically ECMAscript for autonomous behaviour in the client"
Jo: so what the ECMAscript achieves is autonomous user interaction and autonomous network communication
DKA: could use "generally uses ECMAscript", etc.
<Rotan> 5. "can operate successfully on client devices that are designed primarily for use while moving or being carried"
<jo> 5. can operate successfully on client devices which may move
<Bryan_Sullivan> offers autonomous interaction with the user and network, typically by use of a scripting language (often ECMAScript or a derivative)
<chaals> [/me suggests "can operate successfully on mobile devices"]
<Bryan_Sullivan> previous one was edited as "uses Cascading Style Sheets properties for styling"
<Rotan> I can move my server. It's not really a mobile device though, is it?
<Rotan> Something that is designed primarily for use while moving would generally have a small screen. It's a natural inference.
<Rotan> You don't need to say it.
<DKA> :)
<Rotan> Yes, Jo, from the charter.
<Rotan> Yes, I agree Jo.
Jo: the bit that is missing is that a user's context may be significantly different from time to time
<rob> "can operate successfully on client devices that are designed primarily for use while moving or being carried"
Bryan: is the point "contextual variance"?
<Rotan> "for use while moving" says a little about contextual variance.
<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
<Rotan> That looks like good text to me.
<DKA> +1
<Bryan_Sullivan> OK, replaced that one
<Rotan> (You don't really need the "a range of")
DKA: Point 6 is redundant
<Rotan> Automotive Web device is not handheld.
<jo> 7. can operate successfully in a networking environment
<jo> which may involve intermittent, relatively slow, and relatively
<jo> expensive connectivity
<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).
DKA: Point 7 - important to cover the network issues specifically as these issues are important
<Rotan> No. 6 is redundant.
<Rotan> If it is designed for use while moving, you can infer that the i/o is limited.
<Rotan> Unless you like carrying your plasma TV.
<Rotan> Let's not worry about the edge cases.
DKA: Point 7, want to change "networking" to "networked"
<Rotan> "relatively expensive" means relative to what exactly?
<Rotan> Could just say "expensive".
DKA: relative to desktop broadband access
<Rotan> The expense could be cost, or could be use of scarce resources (e.g. bandwidth).
Bryan: Key point is "limited resources"
DKA: likes the "limited resources" term
<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
Jo: how about "resource constrained environment with consequent impact on the user"
DKA: I think "expensive" is an appropriate word for this
<jo> can operate successfully in a resource constrained networked environment with consequent impact on user experience, delay and cost
<jo> can operate successfully in a intermittently connected resource constrained networked environment with consequent impact on user experience, delay and cost
Jo: Jonathan can we broaden your statement to include making use of mobile features, eg. touch screen
<francois> Scribe: Francois
<scribe> ScribeNick: francois
Jo: Let's take up Jonathan's suggestion and take a look at it
<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
<Rotan> Watch out for the background music!
<jo> ^^ from Jonathan
Bryan: the use of mobile features.
DKA: I think something about mobile device "capabilities" would be good
<jo> Can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces
Bryan: so... the web applications that are designed to exploit mobile device capabilities?
<Rotan> The unique and specific features associated with mobile devices.
<Bryan_Sullivan> Prefix to the list "Web applications considered in scope for BP2 typically have many of the following characteristics:"
DKA: to have something consistent with that heading, something that uses mobile device capabilities
<jo> Can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces and has a camera
<Rotan> "various modes of input and data gathering"
DKA: I would go for "use of a camera", comma, etc etc
<jo> Can take advantage of specific mobile capabilities, such as the ability to make phone calls, (haptic and) gestural interfaces and has a camera
<jo> and yada yada yada
Jo: [yada-ing]
DKA: OK, that concludes our discussion
Bryan: next paragraph in the Scope
section is mostly taken from BP1
... I thought it was an important clarification of the focus
... Focus is on the content and the applications themselves
DKA: We should also say we're not telling "use Java, HTTP, ...".
Jo: I think we should remove the ref
to WCAG
... First sentence is important. The rest should go.
... but at some point we'll probably have to put ref to WCAG,
internationalization rec and the like
Bryan: I left the ref to the Scope
document
... A more detailed consistency revue would be good
<jo> ACTION: rabin to raise issue on currency of the Scope document ref whether it should be reference drom BP2 [recorded in http://www.w3.org/2008/03/03-bpwg-minutes.html#action20]
<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].
Bryan: Then, 1.4.1 lists a set of
practical criteria which may not be that practical
... Here's the list:
- recommendations that are considered essential for successful deployment of web applications in common delivery contexts
- recommendations are considered of fundamental importance to growth in the mobile web application market
scribe: which is a bit more fluffy
- recommendations that can be readily verified through compliance testing, either automated (preferred) or manual
scribe: Are we going to make recommendations that cannot be testable?
Jo: We did have that discussion
before, and decided testability was not a necessary criterium for
the best practices
... It would be consistent with BP1 to continue like this
<Rotan> Thinking out loud: would it be useful to reference the recent work on the relationship between MW and Accessibility?
Jo: About the previous 2
points...
... first, maybe not essential, rather good practice
... I think the statements are both overstated
Bryan: my point was there are
probably many things we could write about
... we need to be careful to draw a line between what would be
useful and what is useful
chaals: I agree with Jo, not
"essential", rather "are going to improve"
... some best practices should be something like "It's always worth
doing this"
... Second point, I was trying to understand what it really really
means.
<jo> a) its common practice that is harmful in our scope
<jo> b) it would improve the experience in our scope but is rarely practices
chaals: A BP leads to an improvement in user experience
<jo> c) it is in scope
<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.
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"
Jo: Yes, it must exist
DKA: right
<Rotan> Thinks Dan's idea sounds nice, but could be open to challenge for being too subjective.
<DKA> Subjectivity is objective.
Bryan: I'll paste the 3 points I'm getting
<Bryan_Sullivan> will improve chances of successful deployment for web applications in common delivery contexts
<DKA> -Woody Allen
<Bryan_Sullivan> if they address a specific mobile aspect
Jo: On wording, I would prefer "refer to the mobile context"
Bryan: yes, but it seems too generic
<Bryan_Sullivan> if they are relevant but not limited to the mobile context
<Bryan_Sullivan> if they are relevant to the mobile context
<jo> +1
<Bryan_Sullivan> is implemented and recommended as a best practice
DKA: do we want to precise the number of implementations?
chaals: 2-3, that's nothing on the Web, so no
<Rotan> And "enduring", meaning that where implemented, it tends to stay there and continue to be used.
<Bryan_Sullivan> is implemented and recommended for broader use
Jo: 2 things, one to include: if we find something not commonly implemented but useful
<Bryan_Sullivan> 1) will improve chances of successful deployment for web applications in common delivery contexts
<Bryan_Sullivan> 2) if they are relevant to the mobile context
<Bryan_Sullivan> 3) is implemented and recommended for broader use
Jo: One thing that seems to be missing is we're not saying anything about what people do today that is harmful
<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.
<DKA> ..or it hasn't had the stamp of approval from the W3C Mobile Web Best Practices working group.
chaals: if we say "don't do something", then it meets our criteria and there's no need to create another use case
<Bryan_Sullivan> promote avoidance of techniques considered harmful
chaals: let's say you have a BP that
says "don't write bad apps" (just an example).
... it meets our criteria
... so no need to add that criterium
<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.
Jo: I take your point, but still consider it useful.
Bryan: alright, I'll make a note with that.
<DKA> Updated agenda here: * Review Apple document
<DKA> * Review Univ of Helsinki masters thesis on Mobile Ajax performance
<DKA> * tel: URI (and other URI schemes)
<DKA> * Review Frost Ajax library
<DKA> * Korean input on BP 2.0 document (1 hr)
<DKA> Gah!
<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
<DKA> Trying again: Updated agenda here: http://docs.google.com/Doc?docid=dd3jk8v_89f6vrqk9w&hl=en
Jo: Yes, that captures it nicely for me
Bryan: OK
<jo> +1
<DKA> +1
<jo> +1 to Dan's +1
chaals: successful deployment?
Bryan: yes, softening of my previous "essential" statement
<Rotan> For many these days, successful simply means it makes you lots of profit.
<DKA> +2 to JO'S +1 of my +1
<Bryan_Sullivan> will improve web applications in common delivery contexts, by promoting adoption of good techniques and avoidance of techniques considered harmful
<jo> making a profit is important to the ecosystem
<Rotan> Plenty of rubbish apps out there making a load of money. Lack of decent competition in many cases.
chaals: yes, that actually looks good to me
Bryan: 1.5 and 1.6 are
templates
... Follow in the steps of BP1, period. OK?
Jo: I think we can continue to have this note on DIWG, except we have to rename it to UWA
Bryan: 20mn left, let's go through
the requirements
... What I have in the requirements is I got requirements
structures around a number of aspects.
... There was this whole list we came up with in an email. So I
took it and broke it up in sections
... Now the list is down at the end of the document
Jo: Are we skipping Requirements?
Bryan: no, but Dan wanted to go the Tel Uri thing
Jo: OK, I think the requirements need
some more work
... Personalization, Security and privacy are not
mobile-specific
DKA: I think the most valuable to
spend our time is to take a look at BPs
... so I would start with tel URI because I had the feeling it was
not controversial
Bryan: OK, so about section 5
... the BP is to use URI schemes (tel, sms, wtai, mailto)
DKA: I don't think we can give all of
these things equal weight
... Is sms: implemented, sip: implemented?
... I know tel: is implemented, more than the rest at least
Jo: Use Uri schemes when they are known to be supported
DKA: that gets a bit wishy washy, doesn't it?
Jo: The advice's got to be: find what schemes are supported and use them
<DKA> \ack jo
<Zakim> jo, you wanted to comment on the work "great"
Jo: We should include wtai, sms, tel... even if they are not properly standardized
<Bryan_Sullivan> SMS URI scheme draft http://www.tools.ietf.org/html/draft-wilde-sms-uri-14
Jose: the point is not recommending the use of URI schemes but when.
DKA: when you're presenting a number that you want the user to call, use tel:
Bryan: to capture this... when you intend to specifically have the user make a phone call, use this
<jo> Where possible use formal hyperlinks for non-Web actions.
Jo: we should not restrict to "tel:" as Bryan says
DKA: from the developer's point of
view, use schemes is a completely useless statement
... 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
... I would like us to err on the side of these statements be
simple
<jo> Where possible use hyperlinks to indicate actions such as initiating a phone call
<Zakim> DKA, you wanted to suggest we need specific best practices addressing each of tel:, wtai:, -- specific BPs are more useful to developers.
Bryan: I added to Jo's statement a prefix.
<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.
DKA: I don't think techie is the problem
chaals: I'm with Dan
... Basically, if we say "use formal hyperlinks for non-Web
actions", the guys would just say "whatever..."
<jo> Where possible use hyperlinks to indicate actions such as initiating a phone call
chaals: BPs should be a short simple
sentence that makes sense
... Use tel: wtai: for phone calls. Period.
... and refine it in "What it means?"
Jo: I take all the points on board,
but I also think they need to be accurate
... if we say use tel: wtai: brackets whatever other URI schemes
you know the phone supports, then we haven't done much
... The point is about what the user wants to do
... mention something such as wtai: or tel: in the short
description line is too specific
DKA: I disagree.
Jo: you'll want to add sms:
DKA: we'll have another BP!
Jo: Our motivation is "if you want the user to perform an action, then hyperlink it for god's sake!"
DKA: why don't we leave it to Bryan to work on this and call it a day?
<jo> [adjourned]