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

[minutes] Tuesday 3 March 2009

From: Francois Daoust <fd@w3.org>
Date: Tue, 03 Mar 2009 17:56:05 +0100
Message-ID: <49AD6125.4090901@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/03/03-bpwg-minutes.html

... and copied as text below.

In short:
1. We're targeting another public working draft on MWABP to gather 
feedback from the developers community
2. I'll prepare a review questionnaire for the addendum on BP, so that 
we may resolve to publish the doc next week.
3. Discussion on X-Device-* HTTP Header fields for the Content 
Transformation Guidelines. Eduardo to propose some text that captures 
the essence of the discussion.
4. I'll prepare a poll on the question of mandating respect of 
heuristics so that we may eventually resolve ISSUE-286.

Francois.


-----
03 Mar 2009

    [2]Agenda

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

    See also: [3]IRC log

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

Attendees

    Present
           jeffs, Bryan_Sullivan, DKA, rob, francois, yeliz, brucel,
           SeanP, EdC, adam, Kai_Dietrich, manrique, achuter

    Regrets
           DavidStorey, chaals, dom, jo, miguel, nacho, tomhume

    Chair
           DKA

    Scribe
           rob

Contents

      * [4]Topics
          1. [5]Update on MWABP
          2. [6]Update on BP Addendum
          3. [7]CT: X-Device HTTP Header fields
          4. [8]Update on F2F logistics
          5. [9]CT: Mandating respect of heuristics
      * [10]Summary of Action Items
      _________________________________________________________

Update on MWABP

    DKA: looking at traffic on the list, Adam says there's another draft
    pending

    francois: Adam's working on it, he's doing it this week

    <jeffs> adam: francois asking on voice if you are on the call

    adam: I've had another pass through the doc making changes agreed
    and hope to post this draft this week.
    ... hope to have another draft before the F2F as well

    DKA: Can we be in a position to address Last-Call comments at the
    F2F? Is this possible still?

    francois: I don't think we have any choice except to have a few more
    iterations, the document needs to be pretty much finished before
    Last Call

    <jeffs> what has happened with the whole transcoding/https issue,
    please??

    <francois> jeffs, the whole transcoding/https issue is still on, but
    for the Content Transformation Guidelines, not for MWABP.

    adam: Abel (who submitted the SVG BPs) suggested that these are not
    stand-alone BPs but support existing BPs

    adam: so we propose to remove the SVG section itself

    DKA: If there is no expertise in the WG then we should try to get
    feedback from elsewhere

    adam: I assume feedback will come to the public list? We've asked
    there.

    <jeffs> would you like me to try to get our RIT SVG-nut to take a
    look??

    DKA: may need some outreach work if there's no response on the list

    <jeffs> +1 on including canvas...

    adam: I've also asked about Canvas experience

    DKA: these drawing mechanisms fall under the same umbrella

    <jeffs> would you like me to try to get our RIT SVG-nut to take a
    look?? and would you like me to look at canvas materials??

    DKA: should we release another public draft now then?

    <jeffs> dan & adam: would you like me to try to get our RIT SVG-nut
    to take a look?? and would you like me to look at canvas materials??

    <DKA> Jeffs - yes and yes please.

    <jeffs> okay

    <DKA> :)

    adam: if public drafts encourage more feedback then maybe we should
    have more of them. We need more feedback.

    brucel: I'll see ifOpera has more SVG experience to share

    <jeffs> dan: do you want to make me an action re canvas? or just
    report back more informally??

    francois: I agree we should publish publically as often as possible
    to get more feedback but it does delay work a bit because of the
    window for comments

    adam: Abel asks "It is going to be incorporated as concrete use
    cases for specific BPs?"

Update on BP Addendum

    <Kai>
    [11]http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0066.htm
    l

      [11] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0066.html

    <Kai>
    [12]http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/att-0066
    /ED-mobileOK-pro10-tests-20090210.html

      [12] 
http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/att-0066/ED-mobileOK-pro10-tests-20090210.html

    Kai: several changes have gone into this doc...
    ... have adopted the format that Dom suggested reducing the
    information to the minimum requireed
    ... Doc is self-explanatory
    ... Abstract and Intro now conform to Jo's text

    DKA: Is there anything else needed now (References, appendicies
    etc)?
    ... some of the text is pretty telegraphic!

    Kai: that's intentional. This doc never had explanatory text in its
    scope

    <EdC> small question: in the "evaluation procedures": are the bullet
    points always to be checked sequentially as specified, or is the
    order not that strict?

    Kai: Some of the devaluations need review, eg Device Properties
    ... Did anybody read this doc?

    DKA: Apparently! We intent to publish this doc before the F2F so
    timely review is essential

    <jeffs> +1 get docs out for reading well in advance of the f2f

    francois: Maybe 1 week for comments and resolve next week to publish
    or redraft?

    Kai: That'd be good

    francois: a questionnaire forces membes to respond and is a good way
    to ensure the document is reviewed

    DKA: can you do that Francois?

    francois: yes

    Kai: Thanks. I've got one small typo to correct, shall i do that now
    or just comment on it?

    francois: references section needs updating to match the style guide
    but isn't essential for the review

    Kai: OK, so these 2 points can be comments along with everything
    else from the questionnaire

    <Kai> Thanks to Manrique for helping out with the document!

    DKA: Good, hopefully there will be Champagne at the F2F then

CT: X-Device HTTP Header fields

    francois: Haven't made much progress this past few weeks

    francois: still uncertain about HTTPS link rewriting and security,
    Jo is working on new wording to move the discussion on

    <jeffs> ACTION jeffs to get review canvas tag materials and suggest
    how/if to address in BP

    <trackbot> Created ACTION-910 - Get review canvas tag materials and
    suggest how/if to address in BP [on Jeffrey Sonstein - due
    2009-03-10].

    <jeffs> ACTION jeffs to get Prof. Bogaard at RIT to review SVG
    materials and suggest how/if to address in BP

    <trackbot> Created ACTION-911 - Get Prof. Bogaard at RIT to review
    SVG materials and suggest how/if to address in BP [on Jeffrey
    Sonstein - due 2009-03-10].

    francois: Also X-Device- prefix headers is an open issue

    <francois> [13]Eduardo's proposal on X-Device-* HTTP headers

      [13] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0001.html

    francois: Eduardo's proposal is to stick with X-Device headers
    because there is no practical benefit in moving to registered
    headers

    <jeffs> -1 to X-Device- prefix headers... as I read IETF stuff, this
    would be "taky"

    francois: but there might be trouble ahead proposing "experimental
    headers" in the Rec

    <Bryan> there is a low buzz on my phone - analog noise - some wiring
    issue

    <Bryan> i can switch to mobile if needed

    jeffs: reading the IETF stuff it's definitely against using X-Device

    DKA: is there a middle way? To pursue registering a Device- header
    but in the Rec make it clear that X-Device is in widespread use?

    EdC: what is the practical benefit of registering?

    DKA: If you want to play nice in the Internet then the IETF who
    define HTTP set the rules and they say X- "experimental" headers
    need to be depricated eventually

    <brucel> goodbye all; vaccination time

    Bryan: Registration and deprication takes a long time, so
    practically makes little difference

    francois: If we formally register the Device headers, then we need
    to be clear exactly why we need them and it's been argued it's a
    hack of arguable value it the CT Guidelines are followed as a whole.
    ... So we really need to tidy the use-case if we are going to
    register the header

    <EdC> I refer to my comments regarding long migration phase, HTTP
    header overhead, and temporary character to be replaced by a
    solution as POWDER.

    SeanP: the use-case is to allow an origin-server to log or vary it's
    behaviour even when content is being transformed

    francois: then the CT-proxy should not alter these HTTP headers

    <EdC> But we are not allowed to make standards in this group...

    DKA: there is a contradiction: do we need it at all? vs it's in such
    widespread use we can't depricate it
    ... is the use-case of content-selection (eg which J2ME download) vs
    content-transformation one that justifies X-Device use?

    SeanP: the use-case is where the user has asked for desktop content
    (and spoofed the User-Agent). X-Device-User-Agent then allows the
    origin server to log or trace information

    EdC: The CT-proxies that systematically alter the User-Agent seem to
    regardless of the content. So maybe there isn't strong ground for
    registering this with the IETF

    DKA: Do you mean ask IETF if to register the header or ask IETF if
    we should be using the overall Device- header scheme at all?

    EdC: Yes

    <jeffs> +1

    DKA: purely from IETF perspective, the only way forward is to say
    X-Device is used if User-Agent is altered, it is real advice to
    content providers. But don't propose registering the header because
    it's not seen as being a widely used use-case moving forwards

    <jeffs> from RFC 2076 (I think this is the right one) :
    '"experimental" This header is used for newly defined headers, which
    are to be tried out before entering the IETF standards track.'

    francois: then we'd have a normative problem - "a CT-Proxy MUST use
    X-Device-"

    <EdC> Jeffs: in practice X- has been interpreted as eXtension rather
    than eXperimental, and this for a long time...

    francois: the only solution I see is to move it to an informative
    section for content-providers
    ... without mandating the CT-Proxies all use it

    <EdC> -1

    francois: I agree with Eduardo that if it is useful then registering
    with IETF would only make the mess greater

    SeanP: I'd prefer it to be normative to avoid variations that we
    have at the moment

    <jeffs> agree w Dan's idea, put folks on notice in this doc and
    formally consult w IETF

    DKA: working with IETF does give notice that this will be deprecate
    at some stage, is that useful?
    ... Is that acceptable? or a block to publication?

    francois: It won't block publication as a Last-Call

    DKA: I want to decouple publication of the 1.0 document from IETF
    discussion

    <DKA> "may be deprecated"

    <jeffs> agree w "may be", more real

    EdC: Depricated doesn't mean replace X-Device- with Device- - it
    might mean change the scheme altogether

    DKA: Ed, can you sugest some new wording keeping the normative
    meaning but noting that we're working with IETF that may depricate
    this in the future?

    <francois> ACTION Eduardo to suggest some new wording on X-Device-*
    HTTP header fields keeping the normative meaning but noting that
    we're working with IETF and may deprecate this in the future

    <trackbot> Created ACTION-912 - Suggest some new wording on
    X-Device-* HTTP header fields keeping the normative meaning but
    noting that we're working with IETF and may deprecate this in the
    future [on Eduardo Casais - due 2009-03-10].

Update on F2F logistics

    <EdC> there was a last issue: mandatory "heuristics" for CT.

    adam: Still OK to use Google in Victoria

    <EdC> OK, there is another fourth one: conformance statements
    (longer term)...

    francois: we're 10 or 11 people

    <francois> [14]Results of the F2F questionnaire

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

    SeanP: can we have the address please for booking?

    <francois> ACTION Dan to start agenda discussion for upcoming F2F in
    London

    <trackbot> Created ACTION-913 - Start agenda discussion for upcoming
    F2F in London [on Daniel Appelquist - due 2009-03-10].

    <EdC> Will there be conference calls during the F2F? If so,
    coordination with agenda and numbers to call?

    adam: I'll send logistics info after this call

    <francois> [I think so Eduardo, yes, I'll put the info on the page]

    <jeffs> conf call facilities for WG f2f would be A Good Thing

CT: Mandating respect of heuristics

    <francois> ISSUE-286?

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

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

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

    francois: All the arguments are on the table but we still need
    consensus

    SeanP: the reason I disagreed is that there is a continuum of
    content from lowest-common-denominator content to full desktop
    content and some of it may benefit from adaptation on certain
    devices

    francois: the counter-argument is that the content-providers want
    control over how their content is presented to their customers

    SeanP: Cache-Control: no-transform provides that control

    francois: with other side-effects and it requires the content
    provider changing their websites

    EdC: Yes, we're recapping old arguments here

    <jeffs> +1 on SeanP's comment... when in doubt, leave up to
    page-server to specify if they so choose

    EdC: and remember some content providers don't have much control
    over the headers their hosting service provides

    DKA: Can we resolvethis with a poll?

    francois: yes, something like "Do we mandate the heuristics? -
    Yes/No"

    <jeffs> as long as I am out of mtg by 11:30am EST I can attend any
    day m-th now

    DKA: this call is scheduled on US-time
    ... and US moves to summer-time next week, 3 weeks before Europe
    does

    <jeffs> as long as I am out of mtg by 11:30am
    <whatever_East_Coast_time_is/> I can attend any day m-th now

    DKA: We also have some absentees next few weeks so we will discuss
    on this on the mailing list

    <jeffs> [16]http://www.timezoneconverter.com/cgi-bin/tzc.tzc

      [16] http://www.timezoneconverter.com/cgi-bin/tzc.tzc

    <jeffs> "spring forward"

    DKA: But for next week we keep to US-time which will mean moving to
    13:30 UTC next week

    <jsmanrique> see you

Summary of Action Items

    [End of minutes]
Received on Tuesday, 3 March 2009 16:56:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC