W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2008

[minutes] Seoul F2F Day 1 - Thursday 3 March 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 04 Mar 2008 10:30:49 +0100
Message-ID: <47CD16C9.2020905@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 March 2008 09:31:05 GMT