See also: IRC log
<DKA> ScribeNick: jeffs
<dom> Whether BPWG will be at TPAC 2009 in Santa Clara, Nov 2009
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 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
<dom> 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
<dom> http://www.w3.org/2002/09/wbs/37584/BPWG-CT-heuristics/results
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> 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> 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 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
<rob> +1
jeffs: +1
<DKA> +1
<dstorey> +1
<EdC> +1
<SeanP> +1
<achuter> 0
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
<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> Definition of mobileOptimized in MSDN
<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 http://msdn.microsoft.com/en-us/library/ms890014.aspx
<dom> safari viewport
<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?
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: 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> 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