- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 10 Mar 2009 16:33:27 +0100
- To: public-bpwg@w3.org
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