See also: IRC log
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?"
<Kai> http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0066.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
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> Eduardo's proposal on X-Device-* HTTP headers
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].
<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> Results of the F2F questionnaire
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
<francois> 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
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> 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