[minutes] BPWG F2F in Sophia, day 2


The minutes of our busy Mobile Web Application Best Practices day during 
the F2F are available at:

... and copied as text below.

In short:
- scope was refined and agreed
- we reviewed the document thoroughly and agreed on changes
- Scott proposed some more best practices and is to work on drafting 
text for these
- Once changes are included in the next version of the draft, the idea 
is to publish the document as First Public Working Draft, if at all 
possible at the same date as the publication of Mobile Web Best 
Practices as Recommendation.


17 Jun 2008


       [2] http://docs.google.com/Doc?id=dd3jk8v_114tkbg6kgj

    See also: [3]IRC log

       [3] http://www.w3.org/2008/06/17-bpwg-irc


           Ed, Jo, Adam, Zack, DKA, Kai, Sunghan, Jonathan, SeanP, Dom,
           Francois, Scott, Rob, Abel, Miguel, Manrique, PH, Rotan

           Dan, Jo

           Dan, Sean, edm, rob, francois


      * [4]Topics
          1. [5]On the agenda
          2. [6]MWABP - Scope
          3. [7]MWABP - Requirements
          4. [8]MWABP - Personalization
          5. [9]MWABP - Security and privacy
          6. [10]MWABP - User awareness and control
          7. [11]MWABP - Use of cookies and redirection
          8. [12]MWABP - Conservative use of resources
          9. [13]MWABP - One Web
         10. [14]MWABP - Interaction and presentation issues
         11. [15]MWABP - Handling device capability variation
         12. [16]MWABP - Separating structure, style, and behavior
         13. [17]MWABP - Publication as First Public Working Draft
         14. [18]mobileOK Checker
      * [19]Summary of Action Items

    NB: MWABP is an accronym for Mobile Web Application Best Practices.

On the agenda

    Jo: Today we have scheduled a full day of BP2. Summary of yesterday:
    we made good progress on CT.

    <jo> [20]Agenda

      [20] http://docs.google.com/Doc?docid=dd3jk8v_114tkbg6kgj&hl=en_GB

    Jo: Having spent an extra half-day on that, we need to reschedule
    the things we didn't do - mobileOK topics.
    ... We can try to fit that in tomorrow but it may mean running into
    the afternoon.
    ... Also tomorrow, we have a review of the accessibility document;
    we need to figure out how the checker is going; we need a report
    from the Korean task force; a report would be great.

    Abel: We rescheduled the mobileOK item - but we are leaving in the
    afternoon tomorrow.

    Jo: We can move the agenda around to accomodate that.

MWABP - Scope

    Jo: Adam as co-editor for BP2 has prepared some comments.
    ... Also a Vodafone submission.
    ... We will start with a document review and scope discussion.


      [21] http://docs.google.com/Doc?docid=dft77cn8_17dkz5wp8h&hl=en

    Adam: I've made notes on many of the BPs. Many of them are good but
    we need to reword parts of them. Rather than wordsmithing here we
    should get a feeling for intent.
    ... top of the doc is scope
    ... then section 2, which used to be the requirements section. Bryan
    took the content from that and absorbed into BPs. Do we want to now
    remove that section?
    ... I've highlighted the ones that I feel need most attention.
    ... there's a few more BPs we can add. We should go through those.
    ... scope?

    Jo: yes.

    <dom> [I think 4.11 (Applicability to Non-Browser Web Runtime
    Environment) should probably be moved to scope, 1.4.2 ("Web

    adam: I've took the original scope, pasted in Jo's comments and
    removed wording on widgets. We need to flesh out the mobile context
    bit and describe what's unique about the mobile context.

    kai: in reading the document, it's focused on web applications - how
    does it tie together? I felt a disconnect with the static properties
    of mobile content. Discuss!

    jo: are you saying it's missing bits on static content that are
    missing in bp1?

    kai: yes - I was thinking there would be some more expansion on the
    topics in bp1

    scott: I agree. Some of my input is in this area.

    kai: I don't have any specific inputs in this area.

    adam: It feels like a very big doc to me so I agree we should add
    some more but also we need to cut out items.

    jo: we need to categorize comments under the headings of missing,
    wrong, extra, typographic and unclear.

    kai: we need to have references to bp1 - a stronger linkage.

    jo: what is missing is a stronger tie-in to bp1 - needs to be higher
    level than bp1 but lower level than "applications."

    kai: yes

    jo: i think there are things missing from bp1 like the one I
    suggested yesterday. For example, we don't say that it's a bp for
    hosts to offer a choice of presentation where they have one. Would
    you say that's a candidate for bp2?

    kai: potentially.

    jo: I have in mind a mental model of how these documents fit
    together [goes to white board].
    ... BP1 is a foundation document, on which is built mobileOK basic,
    on which is built mobileOK pro.
    ... now we are creating a new foundation document - bp2. In this
    model, all the documents should refer to bp1 as the foudnation.

    kai: the tests document show you adhere to the best practices. with
    bp2 there is a gap.

    jo: if so, then the answer is to fill that chasm in and increase the
    linkage back to bp1.

    adam: yes - I'd like to see that expressed in concrete best

    jo: to return to the discussion of scope -

    adam: there are 3 sides to the scope - what's bp, what's a web app
    and what's the mobile context? Preface that with some intro wording.
    ... some requests to add more material to the mobile context have
    come in.
    ... I'm happy with it in its current state.
    ... signifigant concerns?

    jo: I've made the point that I don't think think that "great web
    applications" is meaningful.

    adam: I like it - I found it grounding - I think it's been dropped
    out of the scope.

    DKA: I like it because it speaks to web developers.

    Jo: is it possible to be precise and also populist? Would it be
    better to make it precise and then make it populist?

    adam: It needs to be useful.

    Jo: To be useful it has to be correct. To be correct it has to be

    Dom: I think the question is a good one. I'm not sure there's a
    direct correlation between this issue and whether the phrase "great
    web applications" should be in the document.

    Jo: If you advertise in the scope that it's about great web
    applications then you . I think we should remove it and then make a
    pass at the end.
    ... I think it's about ineroperability at its heart.

    Ed: I regarding the audience should we be more percise, saying that
    this is for web developers as opposed to programmers?
    ... are we talking about markup technologies primarily?

    Jo: under 1.3 what would need to change there?

    Ed: People who build java applications I consider to be programmers,
    people who do markup are web developers [in my view].

    DKA: It's all a sliding scale.

    Jo: in what respect should this text change to reflect that

    Ed: the last sentence - can we make it positive...
    ... Please add "Web developers"

    adam: I'm happy with that.

    <Zakim> dom, you wanted to suggest 4.11 be integrated in scope 1.4.2

    Dom: currently applicability to web-runtimes is in 4.11. I think it
    should be in the scope of 1.4.2.

    adam: I agree.

    <Zakim> Kai, you wanted to say that since BP 2 is supposed to be a
    specification it should be precise. We should avoid marketing

    kai: I wanted to get back to wording - since it's intended to be a
    specification it should be percise. Specifications don't have any
    room for marketing-type-speech.

    Jo: We have 2 competing objectives - one is to make it accessible as
    possible, the other is to make it tight and correct.

    Kai: I think "great web applications" have no meaning.

    Jo: How about "web applications" rather than "great web

    DKA: I think having prose-type text at the beginning of a document
    does not take away from percise text later in the document.

    Alan: I agree with Kai that "great" isn't an appropriate term to use
    in this document - but might be better in an outreach document. Also
    "Web 2.0" is ill-defined.

    Kai: I agree.

    DKA: I agree.

    Jo: rather than trying to define "Web 2.0" perhaps someone would
    like to take an action to propose text for that section.

    Kai: "Interactive web technologies"

    <Kai> ACTION: Dan to come up with alternative phrasing for Web 2.0
    [recorded in

    <trackbot> Created ACTION-783 - Come up with alternative phrasing
    for Web 2.0 [on Daniel Appelquist - due 2008-06-24].


      [23] http://docs.google.com/Doc?docid=dd3jk8v_116pb2r6cfw&hl=en

    [reviewing Vodafone submission]

    scott: two main areas are user interface and performance - mainly
    around using client side scripting.
    ... there may be some overlap [with the current doc]

    jo: Ok - this looks "great"
    ... it looks like it's fairly easy to weave into the structure of
    the document.

    scott: some bits at the end not sure where they fit - such as

    adam: as we fix in the existing BPs these should slot in nicely.
    Some references to minimizing network access. We need to tighten up
    how that's presented and worded.

    jo: back to a line by line review.

    adam: this document is 9000 words long
    ... 1.4.4 and 1.4.5 - now obsolete. Are there bits we need to
    preserve or can we delete them?

    [some discussion on wording of this section]

    jo: should there be an expression of what the document is not?
    ... as far as I'm concerned that's "great"

MWABP - Requirements

    adam: section 2- this contains all the text now absorbed into
    section 4.
    ... propose to remove section 2.

    jo: I wasn't happy but I can see the rationale and the consensus
    view is to remove it so let's move on

MWABP - Personalization

    <Zakim> Kai, you wanted to say something on legal issues of

    kai: some of the text encourages using automated means to collect
    usage patterns but in Germany this can be illegal. So some of the
    stuff we're saying needs to be looked at because it might be

    adam: the intent is to say if you have a relationship with the
    operator you can...

    kai: it needs a careful read-through with this point in mind.

    jo: we touched on this - should we be seen to be encouraging illegal
    ... but not sure what to do to the document...

    kai: there's a difference between permission data and automated data
    - that's one area where we have to be careful.

    adam: is it safer just to talk about sign-on?
    ... there's manual signon and automated signon... so rather than
    personalization talk about sign-on?

    kai: I can take an action...

    <dom> ACTION: Kai to review 4.1 Personalization with privacy
    regulations in mind [recorded in

    <trackbot> Created ACTION-784 - Review 4.1 Personalization with
    privacy regulations in mind [on Kai Scheppe - due 2008-06-24].

    DKA: do we need specific wording about privacy and legal
    implications (e.g. european data protection, etc...)

    Jo: that could be a slippery slope....

    <Kai> ACTION: Kai to check the personalization section for specific
    parts that seem to imply combination of personal information with
    usage patterns [recorded in

    <trackbot> Created ACTION-785 - Check the personalization section
    for specific parts that seem to imply combination of personal
    information with usage patterns [on Kai Scheppe - due 2008-06-24].

    Ed: to be very generic - legality is important. Something like
    "privacy regulations and legal constraints."

    adam: on the back of this conversation - should we focus on login
    instead of personalization?
    ... "use automated means for obtaining personalization information"
    seems inflamatory.

    kai: the current phrasing [could be construed] as encouraging
    illegal behavior.

    jo: add a note that it needs to be clarified.

    <dom> ACTION-784: dup of ACTION-785

    <trackbot> ACTION-784 Review 4.1 Personalization with privacy
    regulations in mind notes added

    <dom> close ACTION-784

    <trackbot> ACTION-784 Review 4.1 Personalization with privacy
    regulations in mind closed

    adam: I suggest removing yexy "in the pc environment...is acquired"
    in para 1 of 4.1. Doesn't add value - document will be more
    accessibile if it's more percise.

    jo: suggests "personalization often increases user value."
    ... [digressing] we have in a number of occations tripped across the
    differences between "mobile ISPs" and traditional ISPs. Some of the
    things we would like to advocate as best practices are not obvious
    to the uninitiated.
    ... for the exampe of push - it's a good idea, but in order to do
    that you must have a relationship with a "push provider" of some
    kind or you can't do it - so other elements need to exist besices a
    clear internet connection between the device and the origin server.
    ... so we need to note that there are things you need to know about
    the ecosystem that you may not know.

    adam: we cover the case where you have a relationship with a service
    provider of some kind first and then where you don't - should we
    reverse this order?

    jo: yes and then we can have some additional wording on who can act
    as a service provider [eg aggregators]

    <jo> ACTION: Jo to draft wording for an appendix that identifies the
    aggregators and operator roles that are different in the mobile
    ecosystem. [recorded in

    <trackbot> Created ACTION-786 - Draft wording for an appendix that
    identifies the aggregators and operator roles that are different in
    the mobile ecosystem. [on Jo Rabin - due 2008-06-24].

    adam: suggest cutting out text on "other user information..."

    <achuter> +

    alan: occurs to me that personal information might include
    accesability preferences.

    adam: i'm proposing removing the enumeration all-together.

    alan: ok

    dom: comment on editorial process question - this is a good process
    today but in the normal process we don't have to go through all your
    proposed changes.

    <Kai> ScribeNick: Kai

    adam: [explaining his reasoning for a comment on cookies]
    ... that hidden information is not retained across sessions
    ... need to remove the cookie part
    ... as for security don't store personal infomation in cookies and
    adjust security to what is necessary

MWABP - Security and privacy

    adam: 4.2.1...is the wording ok?
    ... what is the intent of this BP?

    jo: not sure if this is particular mobile specific

    adam: not sure

    dom: this may be interesting for web developers in this context

    jo: i am not sure that using secure hashes is a BP

    adam: should we remove this section?

    is there a document we can refer to, since it is not specifically

    jo: what do the present think?
    ... is this sufficiently mobile?

    dom: if you only develop apps for the pc then this may pose
    different challenges since it is a mobile environment
    ... recommending not use HTTPS is certainly not a good practice, but
    you have to take the mobile context into account

    jo: should we say do not use HTTPS unnecessarily?
    ... if we were to say use a secure hash somebody might ask what is
    that exactly?

    francois: you want to just say use https if you have secure

    SeanP: isn't it the same on the PC?

    jo: but it is in scope
    ... there are certainly harmful effects in a mobile environment

    SeanP: but don't overuse it, right?

    adam: so we should change this from protecting personal information
    to balance the measures chosen?

    jo: can you come up with seomthing?

    dka: can we have explicit examples?
    ... instead of leaving it open, give specific alternatives
    ... we should not say these are the MOST secure alogrithms or
    somethign like that

    adam: I agree. We would then have to worry about that too.

    edm: rather than just say "use HTTPS
    ... use "performance implications of using HTTPS"

MWABP - User awareness and control

    adam: 4.3

    Inform user about personal information? how and what?

    adam: [explainin this proposed changes]
    ... perhaps the BP is good and we need to reword it a bit
    ... informing the user means there are some browsers that show
    personal information, such as contacts etc.
    ... you should allow users to opt out
    ... I think we need to come up with a coherent view of what this
    sections means and says

    dom: maybe this should have a caveat if the device does not allow
    the opt out the app should do so

    adam: the app may not know if a dialog has popped up (?)

    dka: the implementation are not out there yet
    ... access to the address book from the scripting layer would surely
    prompt the user

    jo: we should something to catch poor app design
    ... harmonzing access with underlying systems

    dom: if you get this prompt but don't the app will get access to
    your addressbook you will be surprized

    adam: make the request for personal information an active choice?

    dom: yes.
    ... we need to keep the user aware of what might trigger access to
    personal information

    jo: prior to running the app for the first time it should inform the
    user about all the information it will access

    adam: CP may not necessarily want to do that

    jo: it can be done in a number of ways

    edm: i think it would be good have statement of balancing security
    with sensitivity
    ... context does matter a lot, but taking advantage of that context
    is a trade off
    ... user experience may improve but there is a price to pay
    ... don't ask for everything if you make do with less
    ... should we recommend DCCI or so?

    jo: I think we have had problems with this before and would say no

    dom: I think we can't say it is a BP
    ... there will be a geolocation API and if this work is going ahead
    fast enough, it might become interesting

    jo: at the end of this section we will take a break
    ... 4.3.4 - Brian is keen on redirection

    [break for 20 min]

    [We're baaack]

MWABP - Use of cookies and redirection

    adam: provide control for app behavior
    ... use of cookies and redirection
    ... this might be a bit turned around. Should be robust against loss
    of cookie information

    <DKA> +1

    jo: the amount in infos should be minimized is the focus here
    ... use only the user id key

    adam: minimize redirects
    ... use landing pages

    Kai: actually landing pages tend to annoy users

    jo: we don't want to interrupt user flow
    ... we need to balance the two

    <Zakim> DKA, you wanted to wonder out-loud on whether there should
    be a bp on use of client-side database?

    dka: there are at least two implementation of client side databases
    ... would it be useful to write something about this in this

    jo: so to minimize client side storage is not a BP?

    dka: in the mobile context you probably don't want to store lots of

    jo: so the amount of information is important
    ... the amount of offline operation needs to be taken into account
    ... and multi channel access services
    ... speed of access is important

    adam: where does this fit in?

    jo: control of the app is really the point taking this into account

    adam: does this fit into this section on cookies and redirects?

    jo: no

    Kai: what about redirects, latency etc. Is that still timely for
    this document?

    jo: we need to get to this, but let's finish this first

    adam: so which BPs do we need?

    jo: I think we need a how to do it
    ... also need to add the thing on size of client side storage

    adam: move redirects to use of resources

    Kai: we should not focus too much on redirects, latency and realted

    jo: Bryan has a similar stance
    ... I am not sure how much more we are saying here that hasn't been
    said in BP1 already

    adam: we should mention it, but it doesn't really add much

    jo: we should have a coherent policy on when to mention BP1

    dka: we had said earlier we need a stronger linkage between BP1 and
    BP2. Here we can do that. would help to clear up that BP1 is not
    encouraging lowest common denominator

    jo: so where possible we should make reference to BP1
    ... we could have a preamble "refer also to..."

    adam: web applications increase demands for redirects for

    jo: I am not sure "need" is the right

    Kai: sometimes redirects really are overdone but they do have an
    important role to play
    ... is there are web app specific part that we could mention?

    adam: well the authentication part may be one

    jo: so let's ref BP1 on redirection as preamble for 4.5

    dom: there is no real BP that says minimize server redirection

    jo: so yes, then we should call out the fine points
    ... but we perhaps should not mention specific numbers on redirects

    <SeanP> Scribe: Sean

    <SeanP> Scribenick:Sean

MWABP - Conservative use of resources

    Jo: on to 4.5

    Adam: Transfer compression makes sense
    ...not sure what we want to recommend for app level compression

    Kai: Everyone thinks that compression will speed things up; when you
    go to binary on a fast network it sometimes slows things down.
    ...not sure if this is always true in mobile environment

    DKA: Makes Vodafone joke

    Rob: Use text-based compression

    Jo: How can we capture point of efficiency gain of compression vs.
    loss of battery life, etc.

    Kai: restrict to text based compression

    Dom: Don't compress 1k files and be careful with other bad
    compression techniques; is there a way we can get data on this?
    ...If you are going to send 1M of a text file, it should be
    ...Where is the line?

    Adam: Could publish a table with thresholds of data sizes to

    Kai: Can show a table of compression data.

    Jo: 4 dimensions of compression: 1. type of network, 2. type of
    processor, 3. size of data to be transferred, 4. likely benefits of
    carrying out compression/decompression

    Rob: In practice you tell it what mime types to compress

    Kai: [Puts up a table about compression on the screen]

    Kai: [Describing table] Many times don't see much benefit from
    compression of binary content on ISDN and broadband
    ...Compression makes a big difference however on text based content

    Adam: Simple message: compression of text is good, compression of
    binary data is bad

    Kai: [another spreadsheet is projected] [Shows a case where
    compression has a negative effect]
    ...A lot of variation in benefits of compression for different files

    Rob: Given normal developer tools, it is difficult to configure to
    compress different size files

    Scott: After doing all of the BP1 stuff like removing whitespace,
    etc, the impact of compression may not be that much.

    Adam: Javascript compresses well.

    Adam: Can change the compression BP by: a vague mention of being
    careful with compression, mention binary files or text files, or do
    some work to find out which files should be compressed or not

    Kai: Obfuscating JavaScript makes the files smaller

    Adam: yes, should we call it tokenizing?

    <dom> [An ajaxian article referring to the lack of benchmark on the


    Jo: Open question: Do some work to find out what files and sizes are
    best to compress.

    <dom> [another related article:
    rds-packer-compression-tool/ ]


    Adam: There is a section on app compression which I thought we
    should remove.
    ...I think it is covered elsewhere.

    Jo: Can we put something in about preprocessing JavaScript?

    DKA: There is a mention of EXI; I think this is out of scope for
    this document.

    <DKA> +1

    Jo: EXI is not a done deal; we usually don't refer to things that
    aren't done deals. Also WAP is out of scope.

    Kai: Shouldn't we refer to asynchronous methods to reduce transport?

    Adam: I agree; we should refer to that.

    Jo: Should it be in this section or another section?

    Kai: Maybe in another section.

    Jo: Moving to "Minimize Automatically Issued Network Requests"

    <dom> [an apparently very relevant IEEE paper on compression:
    /00945195.pdf?arnumber=945195 "In this paper, we define the total
    delay as the time for both the transfer and the decompression of a
    compressed file. To minimize the total delay, a mobile program
    should be compressed in the best format for minimizing the delay.
    Since both the transfer time and the decompression time are
    dependent upon the current un


    <dom> derlying resource performance, selection of the "best" format
    varies and no one compression format minimizes the total delay for
    all resource performance characteristics. We present a system called
    Dynamic Compression Format Selection (DCFS) for the automatic and
    dynamic selection of competitive compression formats based on the
    predicted values of future resource performance. Our results show
    that DCFS reduces the total delay imposed by the compressed transfer
    of Jav

    Adam: 2 main points: Batch requests together and Back off during
    periods of inactivity

    <dom> a archives (.jar files) by 52% on average for the networks,
    compression techniques and benchmarks studied"]
    ...Make these two things the focus of this section.

    Dom: How do you do this?

    Adam: Combine your XHR requests; configure your server to be in
    chunked mode so that you are not making continuous XHR requests--not
    sure if this is actually better however

    Kai: Would sections like this benefit from listing bad examples?
    ...If we can't come up with concrete problems that we are trying to
    solve, maybe we don't actually have a good BP.

    Jo: A good idea, but verges on the idea of techniques.

    DKA: Actually different than techniques; with techniques we would
    come up with a Wiki and the community would come in and add
    ...Come up with example applications--this would be a new work item

    Kai: If you show a good way and a bad way to do things, you can see
    the difference.

    Adam: From the view of developer, the good way would be more useful.

    Jo: Back to "Minimize Automatically Issued Network Requests"

    Jo: Is there anything to say about roaming here?

    Adam: No way to tell if you are roaming.
    ...Good reason to give users more control

    Scott: Are we talking about a low bandwidth version and a high
    bandwidth version?

    Adam: Do we want to make a BP for this?

    Jo: I think we should do this.

    DKA: Refer to BP1.

    DKA: Example of Twitter: m.twitter.com is a really stripped down
    version of Twitter; the iPhone version of Twitter is a much richer
    user experience.
    ...I use both of them.

    Adam: If it makes sense to your app, provide a low bandwidth

    Jo: We're going off on a tangent...we're talking about automatic
    network requests.
    ...I think we want to say offer a low bandwidth version if you can.
    ...some apps may not be able to offer a low bandwith version.

    Adam: Should be able to switch network off if possible.

    Kai: Is this low bandwidth stuff really relevant for this
    document--we're not really talking about saving money.
    ...it's about a comfortable application; sometime you have to spend
    more money.

    Jo: We're talking about value--an app
    ...shouldn't use bandwidth unnecessarily.

    Adam: Moving to "Push Methods"

    Jo: generated a lot of discussion on list

    Adam: Reference to MIDP seems out of scope; but I like the idea of
    the BP.

    Jo: What we lack standardized or commonly accessible push methods.
    Hard to recommend a specific Push method.

    DKA: What about WAP push? Is it the same as OMA push?

    Adam: I think they are the same?

    Rob: That is the problem. Where does a developer go to find out
    about this stuff?

    <dom> [30]OMA Push specs


    <dom> [31]WAP Push in wikipedia


    Jo: This is where mobile is different from classic Web..some things
    are no longer bilateral. Push is an example where you have to
    through a mediator.
    ...since mediation is required with Push, it requires extra
    administrative actions.

    Adam: We have some examples; we should remove the part about MIDP.

    Jo: Should we remove "vendor-specific mechanisms"? Is that too

    Jo: How is WAP push different from a text message?

    DKA: WAP push sends a special SMS. Hasn't been popular because the
    user experience differs greatly across handsets.

    Rob: Yes, the user experience varies.

    Jo: Is it worth capturing this point about the user experience

    Ed: Are people still using it?

    Rob: Old spec, but people still do use it.

    Adam: On to Minimize Application Size
    ...There is a long part with examples that should be removed.

    <DKA> [32]http://www.w3.org/TR/mobile-bp/#MINIMIZE

      [32] http://www.w3.org/TR/mobile-bp/#MINIMIZE

    ...Should we just focus on tokenizing scripts?

    Jo: There are ways to increase CSS speed by using selectors in a
    different way; use selectors that match the semantic shape of the
    document instead of class names.
    ...the CSS suggestion was by Martin.
    ...disadvantage is that the stylesheets cannot be shared easily
    between documents.

    Adam: Suggestion is to remove the stuff about CSS selectors and make
    this BP about tokenization of scripts.

    Jo: Maybe we put something in that is more bland about using CSS
    selectors, but not include the detailed example.

    <edm> [33]http://my.opera.com/Andrew%20Gregory/blog/

      [33] http://my.opera.com/Andrew%20Gregory/blog/

    [Time for lunch; back at 1:15]

    <adam> [34]http://docs.google.com/Doc?id=dft77cn8_17dkz5wp8h

      [34] http://docs.google.com/Doc?id=dft77cn8_17dkz5wp8h

    <edm> scribe: edm

    <scribe> scribenick: edm

    <DKA> Of interest:


    <edm2z> scribe: edm

    <edm2z> scribenick: edm2z

    adam: back to 4.5.5 Minimize DOM Manipulation

    <achuter> Is there some way people can measure if they are doing
    this efficiently?

    Scott: parsing the javascript to initialize the doc slows things

    Jo: practice should be about limiting DOM manipulation required
    before initialization of the page
    ... limit dynamic/scripting portions where possible

    adam: we have not measured the cost of dynamic vs. static - need
    ... may also need new BP to minimize network requests

    dka: in general this makes sense

    adam: e.g., do not require additional request for JSON packet...

    jo: should we discuss progressive rendering - page rendered as
    ... all points discussed are really about snappier user experiences
    ... e.g., contacts as JSON rather than fully-rendered HTML

    Scott: this is about more general presentation issues - not just DOM

    DKA: need to provide immediate feedback and keep user aware of what
    is going on - e.g., animation for loading in case of delays

    adam: e.g., notification thta your app is coming down ...

    Jo: is there anyting in particular to preserve re efficient DOM

    dka: who would do some testing?
    ... if presentation related BPs cover this, we could drop this for

    adam: 4.5.6 Minimize External Script Files
    ... ...could be absorbed into other sections...
    ... ...e.g., minimize network requests
    ... topic of minimizing external script files would benefit from
    some benchmarking data
    ... deferred binding of device specific bits seems to be a good idea

    Kai: re - question on diminishing efficiency of caching?

    adam: need to discuss the benefits of deferred binding vs.

    jo: points out the difference between static pages vs. dynamic
    applications - re value of caching

    adam: 4.5.7 Use Power-Efficient Methods
    ... ... need some benchmarking data - to show specific cost

    Scott: no specific data to offer on this yet

    adam: valid point in general - but there are other power efficiency
    issues other than usage

    Jo: ... leave this as a placeholder for now - need more details and
    specific examples of power efficient techniques
    ... perhpas somebody should draft some specific text for the

    <scribe> ACTION: Scott to draft text re power efficiency by June 25
    [recorded in

    <trackbot> Created ACTION-787 - Draft text re power efficiency by
    June 25 [on Scott Hughes - due 2008-06-24].

    ISSUE: how to keep the screen alive (re null gestures) - what to

    <trackbot> Created ISSUE-263 - How to keep the screen alive (re null
    gestures) - what to recommend? ; please complete additional details
    at [37]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/263/edit .

      [37] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/263/edit

    <jo> ACTION: Dan to communicate with OpenAjax Alliance about the
    backlighting issue and null gestures [recorded in

    <trackbot> Created ACTION-788 - Communicate with OpenAjax Alliance
    about the backlighting issue and null gestures [on Daniel Appelquist
    - due 2008-06-24].

MWABP - One Web

    adam: 4.6 One Web

    jo: invites Jonathan and Sunghan to comment on this - in the context
    of using application when switching devices

    Sunghan: e.g., using mobile web application and switching over
    seamleassly to PC at home...

    adam: e.g, pushing personalization to the server would enable this

    jo: is it worthwhile to design mobile web apps to work across
    multiple devices - possibly simultaneously

    adam: 4.6.1 may require some rewording to cover support for range of
    devices AND simultanueos or serial use across multiple devices

    Sunghan: agrees - but need to define specific APIs

    kai: does this include switching devices within session?

    dka: need to add a specific app and use case example - e.g.,
    homepage app

    Kai: what is meant by sharing consistent app state (in

MWABP - Interaction and presentation issues

    adam: 4.7 Presentation Issues - still a placeholder, but some
    specific examples were discussed earlier
    ... may need to cut dowm the preamble and add details

    <rob> Scribe: rob

    scribenice: rob

    <scribe> scribenick: rob

    <DKA> Apple guidelines:
    (specifically "Optimize for Page Readability").

      [39] http://developer.apple.com/webapps/designingcontent.php

    <Zakim> DKA, you wanted to gush about iPhone

    dka: since we're discussing presentation issues, i've an action for
    recs gleaned on this Apple doc
    ... some may be only appliccable to iPhone browsers but may be more
    widely appliccable if say Android's webkit browser also follows suit

    scott: you've got the browser that browses the whole web

    but built-in a bunch of commands that allow iPhone-aware apps to
    control the viewport and zoom in/out

    adam: is it pure Apple-only?

    scott: think it's Apple-only but would be interesting to see when it
    came into Safari
    ... lots of things are handled automatically, the controls mostly
    disable inappropriate automatic actions for your iPhone app
    ... Not sure if Apple are submitting those viewport controls
    anywhere for others to use.

    jo: so what are the generalisable good practices?

    dka: there's not much, but I've transferred the action to Scott!
    ... interesting info about a finger being 44x44px

    Scott: you do make different assumptions for focus-based /
    pointer-based / touch-based devices

    adam: continuing on 4.7.1
    ... just noting about touch-based devices
    ... what about WTAI links for making phone calls?

    Scott: back to 3 different interfaces:
    ... 1) focus-based is moving over controls
    ... 2) pointer-based is moving a cursor around a screen, a bit like
    a mouse but probably with a joystick or D-pad
    ... 3) touch-based is with a touch-screen and stylus or finger
    ... so in 2 and 3 it's essential to know what parts of the screen
    are "clickable"
    ... Both focus-based and touch-based you can move about a page very
    ... wheras pointer-based interfaces can be quite slow if you have to
    move from side-to-side of the screen a lot

    dka: eg controls at the top and bottom of the screen where you have
    to use both a lot

    scott: and you might deliberately do that with a touch-screen to
    avoid chance of pressing wrong button by accident
    ... there are some valuable BP1s that are relevant
    ... but these 3 input-modes have a huge effect building apps.

    jo: we need Scott to add more text around this

    <jo> ACTION: Scott to propose text for different interaction modes
    in discussion with Adam [recorded in

    <trackbot> Created ACTION-789 - Propose text for different
    interaction modes in discussion with Adam [on Scott Hughes - due

    adam: and after that we might change the heading to reflect the

    Scott: already discussed helping users to see what's changed in a
    page (eg "yellow-fade technique")
    ... that works well for text and if you need to change the view in
    response to an update, sliding the content in helps orientating the
    ... You need to understand which bits of the page are visible to
    avoid wasting CPU on invisible changes.
    ... One of the top-level reasons to do this is to speed up the
    apparent responsiveness of the user experience -
    ... providing immediate feedback (eg animation) while waiting for

    jo: it's making more small things happen instead of just

    adam: recants these ideas in section 4.7

    Scott: About text-entry, many browsers won't allow you to see labels
    around a textbox while you enter text in it.

    dom: the inputmode attribute is defined on <input> to tell the
    browser what type of input you are expecting

    jo: it's particularly interested in predictive text

    Scott: Consider impact of CPU on the interface. You don't want jerky
    ... This will vary a lot between devices.

    adam: I'll leave a placeholder here for Scott's contribution.
    ... Another potential BP: enabling the browser history by updating
    the URL with #viewname
    ... this also allows the user to bookmark a view within the page

    jo: how common is this?

    adam: Google uses it all the time

    jo: solves a problem, so it's a useful BP

    <francois> Scribe: francois

    <scribe> ScribeNick: francois

    [end of break]

MWABP - Handling device capability variation

    Adam: On handling device capability variation (4.9)

    jo: what do we want to say here?
    ... 1. determine whether the device supports scripting at all
    ... 2. determine the level of script support
    ... The first think may be statistically determined through a DDR,
    whereas the second may not be.

    Scott: from our perspective, we test each possible device to see if
    our application works

    adam: there's device capability and device compliance
    ... Initial intent was more: if the device exposes Javascript in
    some way, what can be done?
    ... There's a very standard pattern listed in the doc to detect
    whether a feature/object is supported

    jo: the static detection, the dynamic detection, and to what extent
    you may design your application to use the dynamic detection

    scott: dynamic may be useful for cases where you only want to update
    the behavior of an application, but where it's not entirely required

    scott: So we can use profiles of Javascript support, and dynamic
    detection within each profile

    <Zakim> Kai, you wanted to ask about script interpretation /

    <inserted> Following is a message from Heiko connecting remotely to
    the IRC channel

    <hgerlach> I think since I just have 1 item (action 761) and
    regarding the allowlist to allow CT engine to setup a Desktop
    useragent we can discuss this either next Tuesday or you could gimme
    a call when you like to discuss it. So I won't need to join all time

    Kai: are we confident that the interpretation of Javascript is
    standardized enough to tell that dynamic detection will be enough?

    adam: probably not.
    ... should we be referencing the DDWG work?

    jo: excellent idea, indeed

    dka: we should make it clear it's not the only way. There's also
    WURFL and proprietary means to do such things

    <hgerlach> ok,

    adam: there's also the question of Gears for example, where you
    actually install something on a browser that doesn't have the
    capability at first

    jo: are we through enough on this before we move on?

    adam: I'd prefer to craft some text around this, and see the result

    SeanP: There's another document we could reference: the Content
    Transformation guidelines with the X-Device header.

    There could be a content transformation proxy between the origin
    server and the client

    scribe: It's thus possible that the Javascript is not executed

    jo: Can we put a placeholder in whatever text you'll be crafting on
    the role of CT proxies

    adam: ok
    ... 4.9.3 Device Classification to simplify content

    jo: I think it qualifies as a best practice. It's about telling
    people that they don't have to do an instance by instance
    ... that they may use classification

    Kai: it's not an easy issue
    ... not easy to classify devices.

    jo: I agree, but depending on the features required by your
    application, you need to classify accordingly: if your application
    uses location, then you want to know the devices that support such

    Rotan: I think an attempt to create a global way to classify devices
    is just a complete waste of resources

    jo: we need a placeholder in there IMO to reference DD Structures

    rotan: imagine an ad company that provides banners. They need to
    provide the structures that are used to categorize the capabilities
    of the devices that may display each device.
    ... The whole intent is to have structures that may be passed across
    different organizations.
    ... hey, wait a minute, I just spot "the" DDR on screen in the doc.
    I think it's dangerous, because it gives the impression that there
    is only one global DDR, which is just plain wrong.

    adam: OK, I'll change that to "a" DDR.
    ... About alternative to client-side scripting

    jo: I think this fits in the "One Web" section
    ... it seems to me that people whether the application they develop
    requires a non-javascript implementation
    ... We should be aware that the Accessibility and I18n folks may
    have things to say about Javascript use in Web Applications.

    adam: It seems to me that a Javascript application is not always
    less accessible for instance

    jo: that's true, but Flash for instance is often cited as not

    rotan: the ability to deliver an application that doesn't rely on
    Javascript may be connected to the device capability AND the user's
    ... so far, a DDR only talks about device capabilities, but may
    include users capability in the future

    achuter: the accessibility of javascript. Generally it's accessible,
    but it usually depends on the assistive technology available on the
    ... I'm not sure there is an accessibility API for mobile devices


    jo: it seems to me that we could probably do with some draft around
    that point if you could take care of that

    <scribe> ACTION: alan chuter to produce some text around
    accessibility of Javascript for Web Application Best Practices
    [recorded in

    <trackbot> Sorry, amibiguous username (more than one match) - alan

    <trackbot> Try using a different identifier, such as family name or
    username (eg. achuter, atai)

    <scribe> ACTION: chuter to produce some text around accessibility of
    Javascript for Web Application Best Practices [recorded in

    <trackbot> Created ACTION-790 - Produce some text around
    accessibility of Javascript for Web Application Best Practices [on
    Alan Chuter - due 2008-06-24].

    kai: should we emphasize the point even more?

    jo: let's see what comes out of the draft when it's updated
    ... Anything else on 4.9.4?

    adam: there's a section on progressive enhancement, which looks very
    ... but I'm not so sure it's a good idea. I wonder whether it's not
    too low-level to be a BP.

    DKA: Someone presented on this at Over The Air. I wondered if it can
    be reduced to something more BP-friendly

    jo: yes, a big blob of html and javascript is probably not clear
    ... I suggest we raise an issue on this

    ISSUE: How to rephrase progressive enhancement to make it fit as a

    <trackbot> Created ISSUE-264 - How to rephrase progressive
    enhancement to make it fit as a BP? ; please complete additional
    details at
    [43]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/264/edit .

      [43] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/264/edit

    adam: 4.11, I think we agreed to move to the Scope section

    jo: problem with 4.10, not clear what purpose it serves as we don't
    have any specific BP related to it. I suggest we move it to
    somewhere else

    scott: GPRS, UMTS, Wifi... It's a nice idea, but in practice we
    don't do it
    ... there are other things you need to consider before we move to
    this point

    jo: some of it may be moved to minimize use of network typically

    <Zakim> abel, you wanted to add a comment related to section 4.9.5
    (that i think we have skipped)

    abel: about 4.9.5, I wonder if we could mention SVG. It's widely
    deployed in the mobile industry today. I have an example of a
    statistics chart that degrades gracefully based on the capabilities
    of the device.

    jo: very good point.

    dka: If we do that, then we should also reference WICD, because it
    was built with mobile web applications in mind
    ... The problem of course is that it's not implemented in any
    browser today.
    ... I agree to take an action to draft some text

    <jo> ACTION: dan to draft some text on WICD [recorded in

    <trackbot> Created ACTION-791 - Draft some text on WICD [on Daniel
    Appelquist - due 2008-06-24].

    [abel projects some statistics chart demonstrating the use of SVG on
    desktop and mobile browsers]

    abel: first of all, this chart uses SVG FULL, with animations and
    the like.
    ... second version, the same chart for an E61: you still have
    animations. The links are made by means of XLink.
    ... and then the same example, where animations were removed.
    ... and eventually, if SVG is not supported, you may want to display
    a table for instance
    ... The idea would be to complete the practice we have to degrade
    Javascript apply to SVG.

    DKA: you mean figure out what level of SVG the device has? How do
    you do that on the client-side?

    abel: sometimes via a DDR, but some can be determined by scripting.

    DKA: hmmm. Seems like a BP that reads: use SVG when available.

    <dom> [charts being demoed:

      [45] http://idi.fundacionctic.org/bk/E61/barras.svg

    kai: tangential point. To detect device capabilities... If an
    application does that again and again, then it suddenly comes with a
    cost in terms of processing.

    <jo> -> tjamm.mobi svg dublin mobile traffic info

    scott: about the Javascript doing the checks: you do that on the
    first page, and that's about it.

    <jo> s/tjamm.mobi/[46]http://tjamm.mobi/

      [46] http://tjamm.mobi/

    <abel> desktop version->

      [47] http://idi.fundacionctic.org/bk/Desktop/barras.svg

    kai: ok. I was thinking for instance on detecting bandwidth because
    you may typically do that using Javascript and sending/receiving
    chunks over the network, but that's not something you want people to
    do often.

    <abel> Nokia e61

      [48] http://idi.fundacionctic.org/bk/E61/barras.svg

    <abel> raster

      [49] http://idi.fundacionctic.org/bk/Raster/barras.html

    jo: thanks abel for the demo.

    <scribe> ACTION: abel to propose some text on SVG [recorded in

    <trackbot> Created ACTION-792 - Propose some text on SVG [on Abel
    Rionda - due 2008-06-24].

    jo: Anything else from anybody else?

    scott: I felt there was not much on caching. Maybe it was in BP1.
    Even if you have content that changes often, you still have images
    that may be cached.

    kai: good point. There's something we can do: modification-based
    caching which is not commonly done instead of access-based caching.
    ... With that, you can increase the expiration a lot because all
    that matters is the last modification date.
    ... There's a caveat based on the memory of the device, if you cache
    too much.

    jo: There is stuff on caching on BP1.
    ... Again, I'd like to ask for more specific text. I think it's a
    good point.
    ... I would add that we have observed, within Content
    Transformation, that HEAD requests often get turned into GET
    requests which is not exactly good in terms of caching.

    <jo> ACTION: Kai to work with Scott to produce proposed text on
    caching that goes beyond BP 1 [recorded in

    <trackbot> Created ACTION-793 - Work with Scott to produce proposed
    text on caching that goes beyond BP 1 [on Kai Scheppe - due

    kai: agree to take an action

    jo: anything else?

    scott: things often can be done using multiple techniques in
    javascript, and you probably want to identify those that are more
    widely supported. We've found in general the most simple things are
    more likely to work, sometimes to the cost of elegance

    adam: my concern is that it could be too presprictive in terms on
    how people develop their apps

    dka: I know there is a document at OpenAjax which we could probably

    kai: one think that I think is missing is GUI design.
    ... We have this top-left navigation problem. Should we comment on
    what a GUI should look like?

    jo: are GUI in mobile world stable enough to comment on that? I
    think not.
    ... I suggest not. But we may put a placeholder to reconsider that
    later on.

MWABP - Separating structure, style, and behavior


      [52] http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/0053.html

    <dom> [53]http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn

      [53] http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn


    <trackbot> ACTION-695 -- Jonathan Jeon to extract BP statements from
    K MWBP 1.5 document for consideration in BP 2.0 -- due 2008-04-17 --


      [54] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/695

    jonathan: my proposal is about ACTION-695 separating structure,
    style and behavior

    <dom> [model/view/controller pattern]

    adam: so this is like an MVC (model view controller) for the mobile?

    jo: why don't we raise an issue on this?

    <jo> ISSUE: Discussion of Jonathan's Submission ref separation of
    structure presentation and behavior at

      [55] http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn

    <trackbot> Created ISSUE-265 - Discussion of Jonathan's Submission
    ref separation of structure presentation and behavior at
    [56]http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn ; please
    complete additional details at
    [57]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/265/edit .

      [56] http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn
      [57] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/265/edit

    <jo> ACTION: Adam to lead off discussion on ISSUE-265 following
    completion of next draft BP2 [recorded in

    <trackbot> Created ACTION-794 - Lead off discussion on ISSUE-265
    following completion of next draft BP2 [on Adam Connors - due

    jo: [closing the discussion on BP2]

MWABP - Publication as First Public Working Draft

    dom: schedule for publication as FPWD?

    adam: once I've updated the doc, by the end of the week hopefully, I
    think we should review the doc again, and then see how it goes

    jo: I think we should not postpone for too long. What about saying
    not to last more than 4 weeks on this?

    dom: it would be fairly nice if we could talk about this in the
    press release that will come with publication of Best Practices 1.0
    as Rec when it's done

    adam: I can commit to have a new draft of this for next week,
    provided Scott does his actions as well.

    jo: I think the reason for postponing the publication was mostly in
    regards of the scope, and I think we're clear enough now on that.

    DKA: +1

    dom: +1

    jo: so I don't see why we should postpone that any further once the
    document is updated.
    ... I suggest we do checker now

    [some talks on the schedule for the rest of the day and tomorrow's

    <rob> Scribe: rob

    <scribe> scribenick: rob

mobileOK Checker

    Miguel: summary of what we've done since beta release
    ... fixing bugs, completed tests, performance enhancements and test

    jo: how complete is test-coverage?

    miguel: an example, taking into account media in linked CSS was
    missing and added
    ... so test suite coverage is complete
    ... Updates to LC happening now: grammar validation and object
    ... and of course fixing bugs (from test-suite, Bugzilla and other
    testing in the wild)
    ... Also doing some refactoring and documenting of code and
    ... Roadmap is Proposed Rec in 3 weeks' time

    and Rec a month later

    jo: synchronising with the mobileOK Basic Rec would be good?

    dom: mid-July is proposed date

    <jo> PROPOSED RSOLUTION: Checker 1.0 to be announced July 15 or 16
    to coincide with announcement of BP to rec (and mobileOK Basic to

    <dom> +1 (if possible)

    <DKA> +1

    RESOLUTION: Checker 1.0 to be announced July 15 or 16 to coincide
    with announcement of BP to rec (and mobileOK Basic to PR?)

    jo: process is we need a plan showing a go/no-go decision week
    before this
    ... and go/no-go criteria (eg no critical bugs)
    ... eg all test-suite passed; no issues of checker returning false
    ... and it's stable (doesn't crash)

    <jo> PROPOSED RESOLUTION: BPWG acceptance criterion for Checker is
    that the TF asserts that the test suite is complete and that no
    false positives or false negatives are known

    jo: We don't want a WG plenary to approve this, the go/no-go
    decicion should be technical

    <jo> PROPOSED RESOLUTION: TF Delegates responsibility for Go/No Go
    decision to TF based on acceptance criterion being met and no
    show-stopper bugs

    <jo> PROPOSED RESOLUTION: BPWG Delegates responsibility for Go/No Go
    decision to TF based on acceptance criterion being met and no
    show-stopper bugs

    <dom> +1

    <DKA> +1

    <adam> +1

    <Kai> +1

    RESOLUTION: BPWG acceptance criterion for Checker is that the TF
    asserts that the test suite is complete and that no false positives
    or false negatives are known

    <DKA> yipee!

    RESOLUTION: BPWG Delegates responsibility for Go/No Go decision to
    TF based on acceptance criterion being met and no show-stopper bugs

    <dom> [this I think resolves ISSUE-228]

    <dom> ISSUE-228?

    <trackbot> ISSUE-228 -- What Criteria for Checker Approval? -- OPEN


      [59] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/228

    jo: how will TF get there by that date? Do you have enough
    ... would it help to muster more resources?

    dom: yes

    jo: Google?

    Abel: would help to have more people testing certainly

    adam: We personally don't have the time

    dom: we'll keep working on this, we don't need specific promises now
    ... long-term maintenance plan is also needed

    jo: yes, will be non-maintenance stuff to be done post-1.0 too

    dom: core charter of TF is to get to 1.0

    jo: we should at least plan documentation ready with 1.0 so that
    others might be able to help post-1.0

    Abel: there is documentation and it is being updated

    dka: writing to Voda R&D colleagues in Spain for potential help

    <dom> ACTION: Dan to see if R&D colleagues from Spain can help for
    developing/maintening mobileOK checker [recorded in

    <trackbot> Created ACTION-795 - See if R&D colleagues from Spain can
    help for developing/maintening mobileOK checker [on Daniel
    Appelquist - due 2008-06-24].

    Miguel: we should also think about advertising and publicity

    jo: yes, that's the point of synchronisation with mobileOK Basic

    Miguel: looking at Bugzilla now, there are two important stylesheet
    ... Meta refresh bug is a question about following meta refresh

    dom: mobileOK doesn't suggest to do this, so should be out-of-scope
    for Checker

    jo: suggest leave it open as low-priority, may crop up in FAQs

    dom: update priority of image/object source bug to critical

    jo: documentation and internationalisation aren't required for 1.0 -
    they can follow post-1.0
    ... and there are no accessibility requirements because there is no
    user interface!

Summary of Action Items

    [NEW] ACTION: abel to propose some text on SVG [recorded in
    [NEW] ACTION: Adam to lead off discussion on ISSUE-265 following
    completion of next draft BP2 [recorded in
    [NEW] ACTION: alan chuter to produce some text around accessibility
    of Javascript for Web Application Best Practices [recorded in
    [NEW] ACTION: chuter to produce some text around accessibility of
    Javascript for Web Application Best Practices [recorded in
    [NEW] ACTION: Dan to come up with alternative phrasing for Web 2.0
    [recorded in
    [NEW] ACTION: Dan to communicate with OpenAjax Alliance about the
    backlighting issue and null gestures [recorded in
    [NEW] ACTION: dan to draft some text on WICD [recorded in
    [NEW] ACTION: Dan to see if R&D colleagues from Spain can help for
    developing/maintening mobileOK checker [recorded in
    [NEW] ACTION: Jo to draft wording for an appendix that identifies
    the aggregators and operator roles that are different in the mobile
    ecosystem. [recorded in
    [NEW] ACTION: Kai to check the personalization section for specific
    parts that seem to imply combination of personal information with
    usage patterns [recorded in
    [NEW] ACTION: Kai to review 4.1 Personalization with privacy
    regulations in mind [recorded in
    [NEW] ACTION: Kai to work with Scott to produce proposed text on
    caching that goes beyond BP 1 [recorded in
    [NEW] ACTION: Scott to draft text re power efficiency by June 25
    [recorded in
    [NEW] ACTION: Scott to propose text for different interaction modes
    in discussion with Adam [recorded in

    [End of minutes]

Received on Wednesday, 18 June 2008 07:00:26 UTC