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

[minutes] Tuesday March 10 teleconf

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 10 Mar 2009 16:33:27 +0100
To: public-bpwg@w3.org
Message-Id: <1236699207.6399.323.camel@localhost>
Hi,

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

The group took the following resolutions:
* RESOLUTION: a CT proxy SHOULD NOT transform a page that matches
well-known mobile heuristics (to be defined) unless the user has
explicitly requested it
 * RESOLUTION: mobile doctypes (XHTML MP and Basic, WML, iMode) is a
recognized mobile heuristic
 * RESOLUTION: <link rel="alternate" media="handheld" href=""/> is a
recognized mobile heuristic
 * RESOLUTION: MIME Types defined in
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-Example-Content-Types minus application/xhtml+xml are mobile heuristics
 * RESOLUTION: a mobileOK claim is a mobile heuristic, but marked as a
"feature at risk"
 * RESOLUTION: <meta name="viewport" /> is not a notransform-recognized
mobile heuristic, since it is not an explicit declaration of mobile
content
 * RESOLUTION: <meta name="mobileOptimized" /> is not a
notransform-recognized mobile heuristic, since it doesn't seem to
widely-deployed enough to deserve mention
 * RESOLUTION: including an editor's note on calling for more
mobile-specific heuristics

We also created two new issues:
 * ISSUE-288 discusses whether we want to have also a non-normative list
of non-mandated heuristics
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/288
 * ISSUE-289 to discus whether we want to mandate that CT proxies send
X-Device-* headers after having determined the content is not
mobile-optimized http://www.w3.org/2005/MWI/BPWG/Group/track/issues/289

The minutes are also copied below.

Dom

        Mobile Web Best Practices Working Group Teleconference

10 Mar 2009

   [2]Agenda

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

   See also: [3]IRC log

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

Attendees

   Present
          jeffs, Dom, achuter, EdC, DKA, rob, SeanP, dstorey

   Regrets
          Francois, Jo, Miguel, Manrique, Yeliz, Adam, Sangwhan, Abel,
          Nacho, Bruce, Tom

   Chair
          DKA

   Scribe
          Jeff, Dan

Contents

     * [4]Topics
         1. [5]Questionnaire on TPAC
         2. [6]BP Addendum
         3. [7]Mandatory Heuristics issues
     * [8]Summary of Action Items
     _________________________________________________________

   <DKA> ScribeNick: jeffs

Questionnaire on TPAC

   <dom> [9]Whether BPWG will be at TPAC 2009 in Santa Clara, Nov 2009

      [9] http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0020.html

   simultaneous TPAC and AC meeting 2-6 November in Santa Clara

   Dan: do we really think the Group's work will be competed by then?

   <DKA> Yes, Ed, there is a BPWG.

   Dom: it appears unlikely both CT and MWAppsBP completed by the end
   of june

   <dstorey> i've joined the call, not sure how to match my number to
   my irc name though

   Dom: would not be surprised if it took us until the end of this
   calenda year.

   Dan: wondering how many people from EU will be able to attend

   Dom: plan at this time is to add $50/day fee to cover meeting costs
   for TPAC/AC in Nov

   <dom> "The current plan is to hold Group meetings on Monday 2,
   Tuesday 3, Thursday 5, and Friday 6 November. The Technical Plenary
   Day would be held all day Wednesday 4 November. The AC Executive
   Session would start on the evening of Tuesday 3 November and will be
   continued in the afternoon of Thursday 5 November. We also plan to
   charge a registration fee of $50/day to defray a portion of the
   expenses (more details forthcoming)."

   Dan: can we do a quick poll on the Web?

   Dom: can we do a quick round on this call

   +1 for me to be there

   <DKA> +1

   <dstorey> probably +1 too

   <dom> [I probably would go, whether or not BPWG meets there]

   <SeanP> +1

   Dan: if there is a reason to meet, Dan will be there too (probably
   maybe)

   <rob> +0.5 for me

   <EdC> -1

   <achuter> +1 probably

   <achuter> I may also have other WG meetings then

   Dan: wants conditional Web-based poll - to determine if we should
   reserve a spot

   Dom: will send out a poll
   ... maybe this will have to be decided by the Chairs on the basis of
   the poll

   Dan: let us do a poll and ask ppl to respond by friday

   <dom> ACTION: Dom to create a poll to check who would attend at a
   F2F in TPAC [recorded in
   [10]http://www.w3.org/2009/03/10-bpwg-minutes.html#action01]

   <trackbot> Created ACTION-914 - Create a poll to check who would
   attend at a F2F in TPAC [on Dominique Hazaƫl-Massieux - due
   2009-03-17].

   Dan: Francois created a face-to-face mtg logistics page

BP Addendum

   <dom>
   [11]http://www.w3.org/2002/09/wbs/37584/BPWG-addendum-feedback/resul
   ts

     [11] http://www.w3.org/2002/09/wbs/37584/BPWG-addendum-feedback/results

   Dan: we still need ppl to respond to the poll, ASAP (today)
   ... discussion deferred awaiting more responses

   Dom: let us look at the current responses

   Dan: poll referred to is addendum on the MWAPB

   Dom: comments need to be taken into account

   Dan: how should we orchestrate the additional work which needs to be
   accomplished?
   ... would a focused editorial session on this topic work?
   ... another option would be focused time or a breakout at the f2f
   focused on MWApps
   ... teleconf attendance at mtg should not be a problem
   ... moving on to next item

Mandatory Heuristics issues

   <dom>
   [12]http://www.w3.org/2002/09/wbs/37584/BPWG-CT-heuristics/results

     [12] http://www.w3.org/2002/09/wbs/37584/BPWG-CT-heuristics/results

   [13]http://www.w3.org/2002/09/wbs/37584/BPWG-CT-heuristics/results

     [13] http://www.w3.org/2002/09/wbs/37584/BPWG-CT-heuristics/results

   Dom: running problem - should we mandate things ref to transcoding
   madating yes/no
   ... most say "yes, no transcoding" with comments in other direction
   from Sean
   ... pls express opinion via poll ASAP

   Dan: thinks we should take a resolution on this as it is a SHOULD
   requirement

   Sean: there seems to be some agreement that it should be a
   SHOULD-level requirement, unless the user has requested that the
   transformation be allowed
   ... would be okay with that

   Dom: can I take this as meaning you would not raise a formal
   objection?

   Sean: I would not raise a formal objection

   Dan: asks Dom to raise formal resolution

   Dom: okay

   <dom> PROPOSED RESOLUTION: a CT proxy SHOULD NOT transform a page
   that matches well-known mobile heuristics (to be defined) unless the
   user has explicitly requested it

   <DKA> +1

   <SeanP> +1

   <dom> +1

   jeffs: +1

   RESOLUTION: a CT proxy SHOULD NOT transform a page that matches
   well-known mobile heuristics (to be defined) unless the user has
   explicitly requested it

   <dom> ISSUE-268?

   <trackbot> ISSUE-268 -- Test cases to illustrate mobile web
   application best practices -- OPEN

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

     [14] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/268

   Dan: are there additional sub-issues?

   <dom> 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

   <EdC> +1

   Dan: my impression we need more discussion on the heuristics
   themselves

   <dom> PROPOSED RESOLUTION: mobile doctypes (XHTML MP and Basic, WML,
   iMode) is a recognized mobile heuristic

   jeffs: +1

   <DKA> +1

   <EdC> +1

   <rob> +1

   <SeanP> +1

   RESOLUTION: mobile doctypes (XHTML MP and Basic, WML, iMode) is a
   recognized mobile heuraretic

   <dom> PROPOSED RESOLUTION: <link rel="alternate" media="handheld"
   href=""/> and <link rel="alternate" media="all" href=""/> are a
   recognized mobile heuristic

   <DKA> +1

   jeffs: +1

   <EdC> +1

   Dan: to be clear, are we limiting the allowed heuristics to what we
   list

   Dom: media="all" means page is for all defined media types

   Sean: if media="all" is there def a handheld page?

   Dom: "all" is supposed to include "handheld"

   <dom> PROPOSED RESOLUTION: <link rel="alternate" media="handheld"
   href=""/> is a recognized mobile heuristic

   Dan: this also relates to my issue, are we telling ppl you SHOULD
   use these heuristics and NOT any others?

   <rob> +1

   <SeanP> +1

   Dom: we are saying you have to respect these heuristics, but are not
   constrained from using your own in addition

   <DKA> +1

   jeffs: +1

   RESOLUTION: <link rel="alternate" media="handheld" href=""/> is a
   recognized mobile heuristic

   <dom> PROPOSED RESOLUTION: MIME Types defined in
   [16]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-draf
   ts/Guidelines/081107#sec-Example-Content-Types minus
   application/xhtml+xml are mobile heuristics

     [16] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-Example-Content-Types

   <rob> +1

   jeffs: +1

   <DKA> +1

   <dstorey> +1

   <EdC> +1

   <SeanP> +1

   <achuter> 0

   RESOLUTION: MIME Types defined in
   [17]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-draf
   ts/Guidelines/081107#sec-Example-Content-Types minus
   application/xhtml+xml are mobile heuristics

     [17] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-Example-Content-Types

   <dom> PROPOSED RESOLUTION: a mobileOK claim is a mobile heuristic

   Dan: let us make an informative note that vendors may also wish to
   respect a mobileOK client
   ... let our document not be gated by POWDER

   <dom> PROPOSED RESOLUTION: a mobileOK claim is a mobile heuristic,
   but marked as a "feature at risk"

   jeffs: +1

   <dom> +1

   <DKA> +1

   <SeanP> +1

   Ed: is that just at the level of an idea or defined in doc?

   Dom it is defined but insufficient implementation experience

   <rob> +1

   <EdC> +1

   RESOLUTION: a mobileOK claim is a mobile heuristic, but marked as a
   "feature at risk"

   Dan: can we then close ISSUE-286, chorus of "no"

   <EdC> Microsoft-specific meta-tag

   <EdC> "MobileOptimized" intended to identify Mobile-IE optimized

   <EdC> content.

   <EdC> <meta name="MobileOptimized" content="nnn">

   <EdC> where nnn is a number of pixels.

   <dom> -1 on MobileOptimized

   Dan: asks Ed for URI to document about this issue on MSDN

   <dom> [18]Definition of mobileOptimized in MSDN

     [18] http://msdn.microsoft.com/en-us/library/ms890014.aspx

   <dstorey> If it a IE thing, it may risk Pocket IE optimised stuff

   Dom: not very widely deployed so does not need to be on the list

   <EdC> It is defined here
   [19]http://msdn.microsoft.com/en-us/library/ms890014.aspx

     [19] http://msdn.microsoft.com/en-us/library/ms890014.aspx

   <dom> [20]safari viewport

     [20] http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/chapter_4_section_5.html

   <dstorey> So far WebKit, Opera Mobile, and I think Opera Mini

   Dan: asking what should be on the list
   ... does it make sense to be more permissive now and cut down later
   based on community feedback?

   Rob: these things tend to be designed for small devices anyway

   <dom> +1 on keeping the list as short as possible for next draft

   Dan: becomes an issue with higher-res/browser-capability smartphone

   Rob: difficult to distinguish when represented as HTML

   Dom: tends towards keeping list as short as possible and looking for
   feedback on what to include in the end

   Dan: what about including these 2 as editorial note

   <EdC> Unsure or in section E?

   would vote for including Viewport

   Dan: asking for proposed resolution

   <dom> PROPOSED RESOLUTION: <meta name="viewport" /> is a proposed
   mobile heuristic, as an editors note

   jeffs: +1

   <EdC> Where do editors' notes appear in the document?

   <dstorey> tentatively +1 but wil lhave to look at what params are
   set in the viewport

   <SeanP> 0 (because I don't know enought about it right now)

   Dom: include a note saying asking for feedback on including Viewport
   in the list of heuristic

   <DKA> +1

   <EdC> Is viewport specifically iPhone specific, or more generally
   WebKIT? If the latter, found in desktop browsers?

   [21]http://developer.apple.com/safari/library/documentation/AppleApp
   lications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref
   /html/const/viewport

     [21] http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref/html/const/viewport

   for all the viewport properties

   Dom: works on a number of smartphone browsers

   <rob> 0

   <EdC> 0 (what about the parameters that distinguish viewports for
   mobiles?)

   for Apple docs on Viewport attributes and uses:
   [22]http://developer.apple.com/safari/library/documentation/AppleApp
   lications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref
   /html/const/viewport

     [22] http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref/html/const/viewport

   Dan: thinks we should take a resolution

   dstorey: this is not mobile-specific

   <dom> PROPOSED RESOLUTION: <meta name="viewport" /> is not a
   proposed mobile heuristic, since it is not an explicit declaration
   of mobile content

   <EdC> +1

   hmmmmm, think I am a -1 on this right now

   <SeanP> +1

   <DKA> +0

   why does a heuristic have to be solely about mobile? can it not be
   about displays and germane to mobile?

   Dom: WRT jeffs question - scope of CT document is only to regulate
   things about mobile

   <DKA> Scribe: Dan

   <DKA> ScribeNick: DKA

   Jeff: We're talking about regulating within the mobile domain - I
   don't see how this (viewport) is out of scope.

   Dom: [rephrasing] meta name=viewport could be used for a tv screen
   where resolution is limited but you don't have other mobile
   limitations - as such it's not an explicit indication that a page is
   intended for mobile.

   <EdC> This seems a similar issue as the media="all" for CSS.

   Jeff: Seems to me that just because it can be used for other display
   devices doesn't mean it can't be used as an explicit heuristic in a
   mobile context. We're talking about what the mobile browser will or
   won't do when it hits this tag.

   Dom: in the case where you're designing a tv-specific page and
   you're using heavy images, you use meta name=viewport to say that
   the expected width is 600 pixesl wite but that doesn't mean your
   page is designed for mobile - so a proxy in this specific case
   should transform the content.

   Jeff: Just looking at one thing doesn't make sense...

   Dom: We're not saying ct proxies must not used meta-name=view port
   as a heuristic. What we're saying is that it's not sufficient.
   ... We are also saying that as soon as you encounter one of the
   heuristics you shoul not transform.

   Jeff: OK
   ... Will you not mention viewport at all?

   Dom: Yes.

   <dom> PROPOSED RESOLUTION: <meta name="viewport" /> is not a
   notransform-recognized mobile heuristic, since it is not an explicit
   declaration of mobile content

   Jeff: I'm not happy.
   ... Makes sense to mention [viewport] somewhere.

   Dom: Could be in an appendix but could create confusion.

   <dom> ScribeNick: jeffs

   <EdC> Could be in section E, but then there should be a mention that
   the attributes associated to the tag must be analyzed to try to
   figure out whether the target is mobile or not.

   Dan: personally inclined to include it as a note, feedback from
   community will tell us if we need to mandate other heuristics

   <SeanP> +1

   <DKA> +1 to not including viewport as a recognized heuristic

   <EdC> +1

   jeffs: 0

   <dom> +1

   <rob> 0

   <EdC> so what about mobileoptimized ?

   RESOLUTION: <meta name="viewport" /> is not a notransform-recognized
   mobile heuristic, since it is not an explicit declaration of mobile
   content

   <dom> PROPOSED RESOLUTION: including an editor's note on calling for
   more mobile-specific heuristics

   Dan: *now* can we close that issue?

   <achuter> 0

   <DKA> +1

   <EdC> +1

   jeffs: +1

   RESOLUTION: including an editor's note on calling for more
   mobile-specific heuristics

   <dom> PROPOSED RESOLUTION: <meta name="viewport" /> is not a
   notransform-recognized mobile heuristic, since it doesn't seem to
   widely-deployed enough to deserve mention

   <DKA> +1

   jeffs: 0

   <dom> PROPOSED RESOLUTION: <meta name="mobileOptimized" /> is not a
   notransform-recognized mobile heuristic, since it doesn't seem to
   widely-deployed enough to deserve mention

   jeffs: +1

   <SeanP> +1

   <EdC> -1 (but...)

   <rob> 0

   EdC: on the one hand, could decide this is taken as a not-heuristic,
   on the other hand, could be in appendix

   Dom: we are just addressing mandated heuristics

   <EdC> +1 (not in mandated heuristics)

   RESOLUTION: <meta name="mobileOptimized" /> is not a
   notransform-recognized mobile heuristic, since it doesn't seem to
   widely-deployed enough to deserve mention

   Dom: should we adress non-mandated heuristics now or later?

   Dan: let us look for community feedback first

   <EdC> What about an editorial note mentioning consideration for the
   mobileoptimized and calling for feedback?

   Dom and Dan: back and forth on whether we should be working with
   non-normative (or potentially so) heuristics

   Dom: the Q for me is: should we have it or will it get outdated very
   quickly? do not wish to create confusion about the heuristics

   Dan: suggests not having such a section unless enormous community
   feedback to deal w this

   <dom> PROPOSED RESOLUTION: we do not include a list of non-mandated
   heuristics in the document

   <EdC> -1

   Sean: this could be useful to content providers

   Dom: don't think it's useful to content providers if they can't rely
   on it to make decisions

   I for one think such a list is useful

   Dan: who supports that resolution, pls?

   Dom: wants to create a new issue on this specific point

   Dan: wants to close larger issue we have and open new issue specific
   to this topic

   <dom> close ISSUE-286

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

   jeffs: +1

   <EdC> +1

   TOPIC remaining CT issues

   Dan: suggests we close the call if no burning issues

   <DKA> ACTION-897?

   <trackbot> ACTION-897 -- Eduardo Casais to establish what best
   current practice is with regard the withrawal of use of X- once the
   non X- form is agreed -- due 2009-01-20 -- OPEN

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

     [23] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/897

   <EdC> lists.w3.org/Archives/Public/public-bpwg/2009Feb/0000.html

   Dom: shouldn't we talk about the larger topic before we close the
   issue?

   Dan: okay
   ... wants to talk over in last 15 mins of mtg

   EdC: addressing the larger point of the X-Device field
   ... some proxies modify the header sent by the terminal, but then
   put in again as x-device- but x-headers are experimental only
   according to IETF
   ... current IETF practice allows registering both X-field and
   non-X-field headers for transition period
   ... this does not bring any benefits to proxy providers etc
   ... requires programming and communications overhead
   ... proposal is keep X-device header fields for the moment and
   indicate in CT guidelines these may become deprecated

   Dom: another proposal is to not say anything about additional
   headers to be sent

   <dom> PROPOSED RESOLUTION: we mandate sending X-device headers, and
   say they may get deprecated in the future

   <dom> PROPOSED RESOLUTION: we do not mandate sending X-device
   headers

   EdC: we had already discussed some time ago and current version of
   the guidelines should say proxies should not modify, and if do
   should save original values in X-header fields
   ... is this 2 resolutions or 1?

   Dom: choice of one or the other

   SeanP: didn't we settle on the 1st version last week?

   I also remember settling on #1

   Dom: checking minutes

   EdC: my issue is that if we go for 2nd resolution, what do proxies
   send? original values or modified values?

   <DKA> +1 on number 1

   +1 on number 1

   EdC and Dom: back and forth

   <SeanP> +1 on 1

   Dan: I don't think we can take a resolution on this today

   <rob> +1 to #1 as well

   Dan: we need to record strong support for mandating, but we need to
   defer

   <dom> close ACTION-897

   <trackbot> ACTION-897 Establish what best current practice is with
   regard the withrawal of use of X- once the non X- form is agreed
   closed

   Dan: has draft agenda for f2f almost done, will try to get it out
   tomorrow

   <EdC> bye.

   Dan: time to say goodbye

   (waves at dom) thanks for all the work

   <dom> ISSUE-288 and ISSUE-289 created

Summary of Action Items

   [NEW] ACTION: Dom to create a poll to check who would attend at a
   F2F in TPAC [recorded in
   [24]http://www.w3.org/2009/03/10-bpwg-minutes.html#action01]

   [End of minutes]
 
Received on Tuesday, 10 March 2009 15:33:56 UTC

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