W3C home > Mailing lists > Public > public-bpwg@w3.org > January 2009

[minutes] Tuesday 27 January 2009

From: Francois Daoust <fd@w3.org>
Date: Tue, 27 Jan 2009 17:37:37 +0100
Message-ID: <497F3851.1020403@w3.org>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>

Hi,

The minutes of today's call are available at:
  http://www.w3.org/2009/01/27-bpwg-minutes.html

... and copied as text below.

In short:
- We will have a f2f in London 25-27 March 2009, probably hosted by Google.
- Jeff and Dan were actioned to do some outreach on MWABP within mobile 
communities.
- BPWG supports inclusion of lang attribute in XHTML and of upgrading 
checker to take into account
- On CT, we need to rationalize thoughts on HTTPS. Jo to do it.
- On CT, we "almost" agree on mandating explicit mobile heuristics. 
Let's have a final round on the mailing-list before we resolve!


Francois.


-----
27 Jan 2009

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0071.html

    See also: [3]IRC log

       [3] http://www.w3.org/2009/01/27-bpwg-irc

Attendees

    Present
           DKA, tomhume, Francois, jo, Dom, Jeff, achuter, adam, miguel,
           yeliz, SeanP, EdC, manrique, rob, bruce

    Regrets
           abel, DavidStorey, Kai, SangwhanMoon, VicquiChan

    Chair
           DKA

    Scribe
           Jo

Contents

      * [4]Topics
          1. [5]Next F2F
          2. [6]MWABP Update
          3. [7]The "lang" attribute in XHTML Basic 1.1
          4. [8]Best Practice on security
          5. [9]HTTPS qua CT
          6. [10]Mandatory Heuristics
      * [11]Summary of Action Items
      _________________________________________________________

Next F2F

    <DKA>
    [12]http://www.w3.org/2002/09/wbs/37584/BPWG-StillPossible-F2F-March
    -2009/results

      [12] 
http://www.w3.org/2002/09/wbs/37584/BPWG-StillPossible-F2F-March-2009/results

    dka: London roolz
    ... but we need to discuss a bit
    ... people from US may not be able to attend if we hold in London
    ... I'm going to be there anyway for the AC meeting as is Kai
    ... plus as David Storey notes SxSW is also ..
    ... it's a trade off
    ... balance of opinion is on London then I am happy with that (25-27
    March)
    ... no clear decision ref Boston, London seems to be the winner

    Francois: what about Adam?

    Adam: I'd prefer London, could make Boston though

    DKA: Can you host?

    Adam: sure but we may have a problem with NDA's being waived

    Dom: Can't be held in a place where an NDA is required
    ... but we did do it before at Google's office in LON

    Adam: so I will chase up and see if we can follow that precedent

    <DKA> PROPOSED RESOLUTION: We will have the next f2f in London 25-27
    March 2009.

    <dom> [13]Policy Regarding Non-Disclosure Agreements and W3C
    Meetings

      [13] http://www.w3.org/2004/06/NoNDAPolicy.html

    <dom> "W3C workshops, Technical Plenaries, Group meetings and other
    W3C-sanctioned events shall not be conducted on the premises of
    organizations that request W3C meeting participants to sign
    non-disclosure agreements in order to gain access to the host's
    facilities"

    dka: we'll leave the question of hosts open, and if Google can't do
    it then we should be able to do it at Vodafone

    <DKA> .

    RESOLUTION: We will have the next f2f in London 25-27 March 2009

    <francois> ACTION: daoust to setup a registration poll for next F2F
    in London [recorded in
    [14]http://www.w3.org/2009/01/27-bpwg-minutes.html#action01]

    <trackbot> Created ACTION-903 - Setup a registration poll for next
    F2F in London [on Fran├žois Daoust - due 2009-02-03].

    adam: need to have info on room sizes

    dka: francois, would you be so kind as to organise a poll?
    ... I would guess around 20

MWABP Update

    Adam: have gone through Jo's extensive comments
    ... I raised an Issue yesterday, and would like to go through it

    <francois> ISSUE-287?

    Adam: I'll keep raising issues as I trip across things over the
    forthcoming weeks

    <trackbot> ISSUE-287 -- Propose merging 3.1.1 and 3.1.2 in MWABP --
    OPEN

    <trackbot>
    [15]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/287

      [15] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/287

    dka: good plan, wan't to open a discussion on how to get Ajax
    developers looking at this and engaing with it
    ... anyone?
    ... developer portals and Web sites, where we can get better
    community feedback

    adam: don't know of anything mobile specific

    <jeffs> +1 on site to allow dev feedback fm AJAX/Javascript devs...
    makes easier to solicit input from non-members

    dka: where do people hang out who are working on iPhone Web apps

    adam: sure there are Ajax discussion groups that would be a good
    place to go

    <jeffs> suggest we est a site so we can publicize

    dka: need to think about where we are going to publicise
    ... any android sites?

    <dom> hmm... no point of raising an issue if nobody has a plan to
    submit?

    dka: (dan discusses raising an Issue)

    <jeffs> if group does not object, I will also start a thread on my
    "Center for the Handheld Web" blog [16]http://chw.rit.edu/blog

      [16] http://chw.rit.edu/blog

    dom: an issue with a plan to action it is like ...
    ... unly to get progressed

    <francois> +1 to jeffs

    dom: agree that we should get more feedback but think that someone
    needs to take an action to come back with a proposal or get on with
    some outreach

    dka: jeffs, you can do some outreach?

    jeffs: The idea of getting people to do outreach and gather stuff
    together makes sense
    ... I can do a post on the Center for the Handheld Web blog
    ... if you want other people to do outreach then they can point
    there or do their own

    <scribe> ACTION: Jeffs to initiate discussion on his blog ref
    feedback on the MWABP [recorded in
    [17]http://www.w3.org/2009/01/27-bpwg-minutes.html#action02]

    <trackbot> Created ACTION-904 - Initiate discussion on his blog ref
    feedback on the MWABP [on Jeffrey Sonstein - due 2009-02-03].

    <scribe> ACTION: appelquist to initiate discussion on betavine ref
    feedback on MWABP [recorded in
    [18]http://www.w3.org/2009/01/27-bpwg-minutes.html#action03]

    <trackbot> Created ACTION-905 - Initiate discussion on betavine ref
    feedback on MWABP [on Daniel Appelquist - due 2009-02-03].

    <francois> ISSUE-287?

    <trackbot> ISSUE-287 -- Propose merging 3.1.1 and 3.1.2 in MWABP --
    OPEN

    <trackbot>
    [19]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/287

      [19] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/287

    adam: ISSUE-287 ...

    <francois> [I note the issue was raised as "RAISED", which hides it
    deep in the list of issues. The "OPEN" state should be preferred. An
    email should have been sent to the mailing-list but was not. That's
    all dom's fault, for sure.]

    <jeffs> to clarify, asking for feedback on MWABP in general or
    ECMAScript in specific?

    adam: 3.1.1 Retain Info for Personsalization ... and 3.1.2
    Autoamtically identify users ...
    ... apart from Network Operators this is really the same thing
    ... kind of no-brainer ways of keeping track of users and their
    preferences
    ... the gist is basically to identify user and minimise the input -
    the difference from BP1 being that there are more ways to do that
    now

    dka: the how to do it can be merged if they are combined

    adam: they are basically sayiong the same thing, once they are
    combined though not sure of the difference to BP1

    <dom> [I have made sure new issues would appear as "open"; trying to
    figure out why issues aren't sent to the mailing list anymore]

    <DKA> Jo: I think we need to get to the bottom of authentication
    separately. I agree with Adam however on this point.

    <dom> [found why]

    adam: what does the team think we are trying to say with this best
    practice, i.e. what important info should be in here, rather than
    just adding details for the sake of it

    dka: can you do a proposal with a "before and after"

    adam: OK

    <scribe> ACTION: ref ISSUE-287 Adam to create a proposal for merge
    of 3.1.1. and 3.1.2 [recorded in
    [20]http://www.w3.org/2009/01/27-bpwg-minutes.html#action04]

    <trackbot> Sorry, couldn't find user - ref

    <scribe> ACTION: connors to create a proposal for merge of 3.1.1.
    and 3.1.2 ref ISSUE-287 [recorded in
    [21]http://www.w3.org/2009/01/27-bpwg-minutes.html#action05]

    <trackbot> Created ACTION-906 - Create a proposal for merge of
    3.1.1. and 3.1.2 ref ISSUE-287 [on Adam Connors - due 2009-02-03].

The "lang" attribute in XHTML Basic 1.1

    dom: basically ...
    ... I ran some MobileOK statistics and one of the biggest causes of
    error was the fact that XHTML Basic doesn't allow the lang attribute
    ... at the same time I18N strongly recommends that in text/html you
    use both lang and xml:lang
    ... so either you break good practice for mobileOK or for I18N
    ... and the new orthodoxy is that any version of XHTML can be served
    as text/html (rather than only XHTML 1.0)
    ... XHTML2 WG is considering adding the lang attribute
    ... by going through the "proposed edited rec" process
    ... they are interested in support and assistance from BPWG
    ... so are we interested in adding the lang attribute
    ... to XHTML Basic?

    <EdC> Fine with me, but as far as I know, most mobile devices
    supporting XHTML basic support XHTML basic 1.0, not 1.1.

    dka: <mumble mumble> non trivial

    dom: not difficult though proposed edited rec process, especially as
    limited in scope
    ... they want us to say we support

    dka: I am supportive ... but hink that we need to understand more
    ... if we support and they make a change will we make a change to
    the checker?
    ... and so more content will become mobileOK

    dom: yes they would release a new DTD and we'd make a trivial change
    to the checker and lots of sites would instantly become mobileOK

    dka: what is the time frame?
    ... if it goes beyond June we are not around to make the change

    dom: given that we have a normative dependency on XHTML Basic 1.1 we
    don't need a formal resolution to do it, so even if the process
    takes longer than the remaining time that is not a problem

    <dom> PROPOSED RESOLUTION: the BPWG supports adding the lang
    attribute in XHTML Basic

    <EdC> +1

    <DKA> +1

    <brucel> +1

    <francois> +1

    PROPOSED RESOLUTION: BPWG supports inclusion of lang attribute in
    all versions of XHTML and of upgrading checker to take into account

    <dom> +1

    <DKA> +1 to jo

    <EdC> All versions means those specified by W3C -- not XHTML mobile
    profile...

    <yeliz> +1

    [which one were people supporting? mine is broader than Dom's?]

    <EdC> (not = not necessarily)

    <DKA> +1

    PROPOSED RESOLUTION: BPWG supports inclusion of lang attribute in
    XHTML and of upgrading checker to take into account

    +1

    <DKA> +1

    <SeanP> +1

    <EdC> +1

    RESOLUTION: BPWG supports inclusion of lang attribute in XHTML and
    of upgrading checker to take into account

Best Practice on security

    francois: this discussion is on MWABP rather than than CT
    ... have had some feedback from the Web App Security Context group
    and think we will get feedback from them following their meeting
    tomorrow
    ... so suggest we postpone till next week

HTTPS qua CT

    francois: we need to rationalise the topic on content
    transformation, and Jo had an action but he hasn't done it yet
    ... we have everything on the table and we need to make a decision
    ... will we put something in the guidelines and if so what would it
    be

    rob: I started the discussion off on what should be done to address
    the question of what to do if you are the "man in the middle"

    <francois> [22]Rob's email on links rewriting

      [22] http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0023.html

    rob: ref security
    ... perhaps we should generalise the discussion rather than limiting
    to HTTPS
    ... that was my intention in kicking the discussion off
    ... but the discussion assumed the HTTPS context

    <EdC> and a third issue: general security considerations on
    transformations not necessarily dependent on URL rewriting, nor on
    HTTPS (cookies, referer, etc).

    francois: there are two questions, i) intercepting secure
    connections ii) rewriting links which triggers a number of cross
    site scripting problems
    ... and other security issues
    ... I think that we should have a "security consideration" section
    as proposed by Eduardo referencing what has been written by Rob
    ... I hope we are clear that we can't recommend to break the secure
    connection
    ... we can't endorse that as a best practice

    dka: what is the way out of this

    <rob> PROPOSED RESOLUTION: Include a section on General Security
    Considerations, which is appliccable to "man-in-the-middle"
    transformations, irrespective of SSL

    francois: I think there should be a security consideration topic, or
    rather a security alert section

    <scribe> ACTION: Jo to action his outstanding action [recorded in
    [23]http://www.w3.org/2009/01/27-bpwg-minutes.html#action06]

    <trackbot> Created ACTION-907 - Action his outstanding action [on Jo
    Rabin - due 2009-02-03].

    <dom> ACTION-902?

    <trackbot> ACTION-902 -- Jo Rabin to summarise current discussions
    on https link re writing -- due 2009-01-27 -- OPEN

    <trackbot>
    [24]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/902

      [24] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/902

    <dom> close ACTION-907

    <trackbot> ACTION-907 Action his outstanding action closed

    dka: anything else?

    francois: I think we already resolved to change the link rewriting
    section - especially to remove the MAY as this would be to endorse
    the practice, which we don't

    <EdC> There are editorial issues, to be done conformance statements,
    mandatory heuristics, at least.

    francois: we really need a crystallization of the topic as it has
    spilled over into so many other areas

Mandatory Heuristics

    <francois> ISSUE-286?

    <trackbot> ISSUE-286 -- Transformation of Mobile Content/Mandating
    some respect of some heuristics -- OPEN

    <trackbot>
    [25]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/286

      [25] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/286

    francois: sean - summary?

    sean: I raised this issue last week, but no email got sent out
    ... issue was raised about mandating heuristics around content-types
    and doctypes that are unambiguously mobile
    ... raised originally by Dom back in Nov
    ... we discussed a couple of weeks ago and I said that if you don't
    allow transformation on mobile pages then this prevents link
    rewriting
    ... and so you lose the proxy function
    ... so I wrote up the issue of user choice to allow users to choose
    mobile pages and EdC brought sup some points which I tried to answer
    ... and that is where we are

    <dom> (as I mentioned last week, this only applies to cases where
    the proxy rewrites links; when it does, we could allow only to
    rewrite links, so as to preserve the proxy function)

    francois: so we need to summarise where we agree and where we
    disagree
    ... so we need to agree that we say that those heuristics SHOULD be
    respected but with the caveat that the user can express the choice
    to continue link re-writing

    <Zakim> jo, you wanted to say that jo has the action already

    EdC: I don't think there is disagreement
    ... idea is simple
    ... if user doesn't want any kind of transformation then they get
    page untouched and they get links to non mobile sites
    ... but on the other hand if they allow transformed content then it
    is just a question of how the proxy works. Some will need to rewrite
    to keep users on mobile pages and others wont
    ... it is just a question of implementation
    ... saying SHOULD NOT is fine, you just need a reason to do
    otherwise

    dom: it's more complicated than that. If the Proxy works at netowrk
    level then requests get caught anyway
    ... but for link re-writing proxies it is more difficult.
    ... so this would prevent non netowrk level proxies from doing their
    job

    <francois> [Proxies SHOULD NOT transform explicit mobile content
    save links rewriting in Linked-mode proxies?]

    dom: so the CT guidelines could say that rewriting links is OK in
    this case
    ... we should be as strict as possible for network level proxies but
    for link rewriting proxies, restrict as much as possible

    edc: if you have to rewrite then you will rewrite and that is
    included in the SHOULD

    dom: but that's not restrictive enough - so we need to explicitly
    limit what can be rewritten in those circumstances

    edc: the question of saying which restrictions is a long topic - we
    could open too big a can of worms and we won't be able to resolve
    it.
    ... rewriting URLs in out of band proxies falls into that category

    dom: that would open the door to transforming everything

    edc: <scribe missed it>

    <francois> s/trasnforming/transforming

    seanp: you know where I am coming from, if a user allows it then we
    should be able to transform sites
    ... we gets lots of requests for this

    <EdC> In short:CT-proxies should not modify mobile content -- except
    as strictly necessary to make desktop content accessible to mobile
    devices. URL rewriting is unavoidable for out-of-band proxies (i.e.
    those that do not capture all HTTP traffic by default). Other
    transformations are in principle not admissible.

    <Zakim> jo, you wanted to say that it is allowed

    jo: we already say that users may request transformed content but
    that can't be the default assumption

    seanp: sounded like mobile was going to be treated differently to
    the mobile page

    jo: ah I see

    francois: doh?

    jo: I think that Sean was saying that we allow transformation of the
    request and therefore implicit requested transformation of the
    response (from desktop to mobile) but we haven't documented any
    facility for the user to request transformation of a mobile
    response. The one applies to the request and the other applies to
    the response irrespective of the request

    seanp: yes

    dka: jo can you scrivbe that as a resolution

    jo: no, not now I'm busy, dammit

    <francois> [Summary of what I think: we agree to mandate respect of
    explicit mobile pages, with 2 points to detail: 1. on the wording
    for proxies that operate in links-mode 2. user expression of choice
    for transformation of mobile pages]

    <dom> +1 to francois summary

    PROPOSED RESOLUTION: Introduce a section describing a
    non-defaultable user option to tranform responses irrespective of
    the transformation of the request, even where the response is
    apparently mobile according to the so-called mandatory heuristics

    <dom> on francois.2, I think we should keep it simple, and say your
    "deployment" doesn't conform when mobile page gets transformed

    <SeanP> What's meant by non-defaultable?

    <EdC> This seems to me splitting hairs. End-users are actually
    offered the following: leave everything untouched. Transform
    responses from desktop to mobile -- it might have some side effects
    on mobile pages depending on the implementation of the gateway, i.e.
    out-of-band might have to rewrite URL to external desktop sites.
    Transform mobile transactions for whatever other reasons.

    <dom> <dom> on francois.2, I think we should keep it simple, and say
    your "deployment" doesn't conform when mobile page gets transformed

    edc: stunned by proposal of defaultable: simply put the user can
    have 3 choices - a) no transformation at all b) access desktop sites
    and transform c) some additional transformation

    dom: problem with the approach is that you can say that the user
    signed a contract that says everything gets trasnformed, so this is
    really not a viable choice
    ... so we are really creating lots of loop holes [Emmental?]

    edc: didn't we say that these have to be opt-in

    dom: isn't signing a contract opting in?

    edc: no you have to check what you want

    jo: we say that preferences will be maintained on a site by site
    basis which goes some way to addressing Dom's point

    <dom> [but that doesn't match the everything/only desktop/nothing
    approach that eduardo proposed, does it?]

    seanp: ref dom's point ref the contract - I thought we moved it to
    an appendix to out of band means, and that we were going to an
    interstitial apporach - i.e. something you do on the phone and not
    something you do by contract
    ... and what about about the site by site thing
    ... thought it was on a session basis

    jo: we say site by site

    <dom> [26]Current section on user preferences

      [26] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-administrative-arrangements

    <DKA> PROPOSED RESOLUTION: Introduce a section describing a
    non-defaultable user option to tranform responses irrespective of
    the transformation of the request, even where the response is
    apparently mobile according to the so-called mandatory heuristics

    <EdC> Current version 4.2.2 User Preferences

    <EdC> Proxies must provide a means for users to express preferences
    for inhibiting content transformation. Those preferences must be
    maintained on a user by user and Web site by Web site basis.

    <dom> "Proxies must provide a means for users to express preferences
    for inhibiting content transformation. Those preferences must be
    maintained on a user by user and Web site by Web site basis. Proxies
    must solicit re-expression of preferences in respect of a server if
    the server starts to indicate that it offers varying responses as
    discussed under 4.2.6 Receipt of Vary HTTP Header."

    dom: I think this is too detailed. It should be non-conformant

    francois: I agree with Dom

    <EdC> The resolution proposal is convoluted.

    francois: isn't 4.2.2 enough?
    ... it's not limited to request or response
    ... let's leave 'as is'
    ... and mandate respect of explicit mobile site

    <DKA> PROPOSED RESOLUTION: leave 4.2.2 as is and do not say anything
    about transformation of mobile-friendly content.

    <EdC> Basically, you could have many other transformation options:
    filter for viruses, translate from * to English, add dancing bears,
    etc. All these are user-selectable.

    PROPOSED RESOLUTION: We will not offer an explicit carve out for
    transforming mobile content at user request, transformation of such
    content is non-conformant

    <dom> PROPOSED RESOLUTION: mandate respect of heuristics (as
    SHOULD), with caveat on links rewriting

    <francois> +1 to both

    seanp: liked the original one better
    ... are we saying in the proposed resolution that if you transform
    mobile content then you are non conformant?

    dom: yes

    dka: isn't there a middle way?

    dom: we need to take this to the list

    dka: thanks and good night

Summary of Action Items

    [NEW] ACTION: appelquist to initiate discussion on betavine ref
    feedback on MWABP [recorded in
    [27]http://www.w3.org/2009/01/27-bpwg-minutes.html#action03]
    [NEW] ACTION: connors to create a proposal for merge of 3.1.1. and
    3.1.2 ref ISSUE-287 [recorded in
    [28]http://www.w3.org/2009/01/27-bpwg-minutes.html#action05]
    [NEW] ACTION: daoust to setup a registration poll for next F2F in
    London [recorded in
    [29]http://www.w3.org/2009/01/27-bpwg-minutes.html#action01]
    [NEW] ACTION: Jeffs to initiate discussion on his blog ref feedback
    on the MWABP [recorded in
    [30]http://www.w3.org/2009/01/27-bpwg-minutes.html#action02]
    [NEW] ACTION: Jo to action his outstanding action [recorded in
    [31]http://www.w3.org/2009/01/27-bpwg-minutes.html#action06]
    [NEW] ACTION: ref ISSUE-287 Adam to create a proposal for merge of
    3.1.1. and 3.1.2 [recorded in
    [32]http://www.w3.org/2009/01/27-bpwg-minutes.html#action04]

    [End of minutes]
Received on Tuesday, 27 January 2009 16:38:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:59 UTC