- From: Francois Daoust <fd@w3.org>
- Date: Tue, 04 Mar 2008 10:30:49 +0100
- To: public-bpwg@w3.org
Hi guys, here are the minutes of Day 1 of Seoul's F2F:
http://www.w3.org/2008/03/03-bpwg-minutes.html
... and copied as text below.
Lots of work done :)
Lots of actions created ;)
(see the summary of new actions at the end of the email)
François.
03 Mar 2008
[2]Agenda
[2] http://docs.google.com/Doc?docid=dd3jk8v_89f6vrqk9w&hl=en
See also: [3]IRC log
[3] http://www.w3.org/2008/03/03-bpwg-irc
Attendees
Present
DKA, Jo, MartinJ, jcantera, rob, SeanP, Bryan, francois,
wonsuk, JonathanJ, SeungyunLee, KangchanLee, Minkyo, SungHan,
Soonho_Lee, SunYoung, chaals
Regrets
Chair
DKA, Jo
Scribe
Dan, Rob, SeanP, MartinJ, Francois
Contents
* [4]Topics
1. [5]Agenda
2. [6]CT - Introduction/Guidelines (1 and 2)
3. [7]CT - no-transform directive in Request (3.1.1)
4. [8]CT - Proxy decision to Transform (3.1.2)
5. [9]CT - Proxy indication of its presence to server (3.1.3)
6. [10]CT - Altering header values (3.1.4)
7. [11]CT - editor's meeting/wrapup
8. [12]BP2.0 - Scope
9. [13]BP2.0 - Criteria for BP recommendations
10. [14]BP2.0 - Best Practices
* [15]Summary of Action Items
_________________________________________________________
<DKA> SL: First time having a W3C meeting in Korea.
Agenda
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
CT - Introduction/Guidelines (1 and 2)
<francois> [16]CT draft
[16]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080227
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
[17]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.
CT - no-transform directive in Request (3.1.1)
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
[18]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
[19]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].
CT - Proxy decision to Transform (3.1.2)
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
[20]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
[21]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
[22]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 [23]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
[24]http://groups.google.com/group/modwsgi/msg/289730b262df5bca
[24] 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>
[25]http://osdir.com/ml/apache.mod-perl/2003-01/msg00192.html
[25] 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
[26]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
[27]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
[28]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
[29]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
[30]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>
[31]http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2
[31] 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]
CT - Proxy indication of its presence to server (3.1.3)
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.
CT - Altering header values (3.1.4)
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
[32]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> [33]HTTP mime types
[33] http://tools.ietf.org/html/rfc2616#section-19.1
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
[34]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
CT - editor's meeting/wrapup
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 [35]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
[36]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 [37]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
[38]http://www.w3.org/2008/03/03-bpwg-minutes.html#action18]
<trackbot-ng> Sorry, couldn't find user - Francois
BP2.0 - Scope
<jo> > ACTION: daoust will organise the next CTTF Editors' meeting
<jo> ACTION: daoust will organise the next CTTF Editors' meeting
[recorded in
[39]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> [40]BP 2 Draft
[40]
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080303
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> [41]Scope discussion
[41] http://lists.w3.org/Archives/Public/public-bpwg/2008Feb/0116.html
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
[42]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].
BP2.0 - Criteria for BP recommendations
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:
[43]http://docs.google.com/Doc?docid=dd3jk8v_89f6vrqk9w&hl=en
[43] 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
BP2.0 - Best Practices
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
[44]http://www.tools.ietf.org/html/draft-wilde-sms-uri-14
[44] 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]
Summary of Action Items
[NEW] ACTION: daoust to ask aaron kemp for clarification of the
character encoding issue [recorded in
[45]http://www.w3.org/2008/03/03-bpwg-minutes.html#action06]
[NEW] 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
[46]http://www.w3.org/2008/03/03-bpwg-minutes.html#action14]
[NEW] ACTION: daoust will organise the next CTTF Editors' meeting
[recorded in
[47]http://www.w3.org/2008/03/03-bpwg-minutes.html#action19]
[NEW] ACTION: finean to provide a pseudo-code example of form
transformation for CT document. [recorded in
[48]http://www.w3.org/2008/03/03-bpwg-minutes.html#action05]
[NEW] 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
[49]http://www.w3.org/2008/03/03-bpwg-minutes.html#action12]
[NEW] ACTION: Francois to write some simple tests for well-known
server environments for how they deal with HEAD requests. [recorded
in [50]http://www.w3.org/2008/03/03-bpwg-minutes.html#action07]
[NEW] ACTION: Francois will organise the next CTTF Editors' meeting
[recorded in
[51]http://www.w3.org/2008/03/03-bpwg-minutes.html#action18]
[NEW] ACTION: Jo to include a note that we think it is bad practice
to strip the comment from downstream via header fields [recorded in
[52]http://www.w3.org/2008/03/03-bpwg-minutes.html#action13]
[NEW] ACTION: Jones to propose text for para 2 of 3.1.1 [recorded in
[53]http://www.w3.org/2008/03/03-bpwg-minutes.html#action03]
[NEW] ACTION: Jones to write a proposal on the HEAD request
handling. [recorded in
[54]http://www.w3.org/2008/03/03-bpwg-minutes.html#action11]
[NEW] ACTION: Martin Jones to write a proposal on the HEAD request
handling. [recorded in
[55]http://www.w3.org/2008/03/03-bpwg-minutes.html#action10]
[NEW] ACTION: Martin to propose text re browser identification: para
2 of sectio 3.1.1 [recorded in
[56]http://www.w3.org/2008/03/03-bpwg-minutes.html#action02]
[NEW] ACTION: Martin to write a proposal on the HEAD request
handling. [recorded in
[57]http://www.w3.org/2008/03/03-bpwg-minutes.html#action08]
[NEW] ACTION: Martinj to write a proposal on the HEAD request
handling. [recorded in
[58]http://www.w3.org/2008/03/03-bpwg-minutes.html#action09]
[NEW] ACTION: Patterson to raise and issue on the distinction
between a CT proxy and (say) Opera Mini [recorded in
[59]http://www.w3.org/2008/03/03-bpwg-minutes.html#action01]
[NEW] ACTION: rabin to raise issue on currency of the Scope document
ref whether it should be reference drom BP2 [recorded in
[60]http://www.w3.org/2008/03/03-bpwg-minutes.html#action20]
[NEW] ACTION: Rob to provide a pseudo-code example of form
transformation for CT document. [recorded in
[61]http://www.w3.org/2008/03/03-bpwg-minutes.html#action04]
[NEW] ACTION: Soonho Lee to provide feedback on CT document
[recorded in
[62]http://www.w3.org/2008/03/03-bpwg-minutes.html#action16]
[NEW] ACTION: Soonho to provide feedback on CT document [recorded in
[63]http://www.w3.org/2008/03/03-bpwg-minutes.html#action15]
[NEW] ACTION: soonho to provide feedback on CT document [recorded in
[64]http://www.w3.org/2008/03/03-bpwg-minutes.html#action17]
[End of minutes]
Received on Tuesday, 4 March 2008 09:31:05 UTC