See also: IRC log
<trackbot> Date: 09 June 2009
<brucel> hi
<jo> scribe: tomhume
<jo> Agenda
jo: welcome to John, and welcome back to Phil Archer
phil: waves
jo: phil was co-editor of the initial mobile web document
phil: here mainly in my role as W3C team member, responsible for providing training around BPs
adam: we've had a smallish amount
of feedback, I have a long list of TODOs and haven't gotten
around to updating the doc yet
... we need to conclude on CSS spriting and multipart
... and possibly something around a BP on AppCache, which is
HTML5-specific - or at least technologies which involve
... not downloading an entire JS package when starting an app.
Not sure how to make a BP out of it.
<jo> ACTION-961?
<trackbot> ACTION-961 -- Tom Hume to investiagate multipart-mixed in the context of 3.4.6 and 3.4.7 of MWABP -- due 2009-05-19 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/961
jo: starting with multipart...
<Zakim> tomhume, you wanted to agree
tomhume: did some research, doesn't appear broadly supported but generally agreed to be a good sort of thing
jo: so shall we resolve as not suitable for a BP?
<jo> PROPOSED RESOLUTION: Multipart is not boradly enough supported to be a mobile best practice
chaals: say nothing, or explicitly reject it?
jo: say nothing I think.
chaals: agree
<jo> PROPOSED RESOLUTION: Multipart is not broadly enough supported to be a mobile best practice - so do not reference it
<jo> +1
+!
+1
<adam> +1
<yeliz> +1
<DKA> +1
RESOLUTION: Multipart is not broadly enough supported to be a mobile best practice - so do not reference it
adam: as a footnote... as part of Eduardo's discussion re spriting: it's broadly supported in a subset of mid/high-end subset devices. I'd say keep it in as they are. Is there support in the group for that?
<jo> Discussion on CSS Spriting
edC: the point is, spriting is supported but does it bring the benefit that it's supposed to bring?
jo: what do we need to do to determine this one way or another?
<jo> Eduardo's Point on Spriting
edC: entice Stephanie (Rieger) to provide figures wrt latency with and without sprites
adam: shall I take an action to follow up on this thread and follow up with her?
jo: yup
<jo> ACTION: Adam to follow up with Stephanie Rieger ref her comments and what the actual benefits are % terms [recorded in http://www.w3.org/2009/06/09-bpwg-minutes.html#action01]
<trackbot> Created ACTION-965 - Follow up with Stephanie Rieger ref her comments and what the actual benefits are % terms [on Adam Connors - due 2009-06-16].
adam: I've had some feedback, mainly internal, that AppCache is v v valuable to web applications (partic. mobile gmail). It feels odd to remain silent on it, although it is HTML5-specific - so a BP might generate complaints. But what do we think?
dka: strongly agree that it's important, but is it too early to talk about it? My view is that it's in the same bucket as some of the stuff in the web apps working group - I would like to see something come out which details how to use AppCache and other offline-web-app techniques, but it seems separate from this document.
<jo> ACTION-064?
<trackbot> ACTION-64 -- Rittwik Jana to submit a text for section 6.2.5 on user preferences -- due 2005-09-27 -- CLOSED
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/64
<jo> ACTION-964?
<trackbot> ACTION-964 -- Tom Hume to review AtomDB for potential inclusion/reference in MWABP -- due 2009-06-09 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/964
jo: is there something in general to say about using offline where available?
dka: yes, giving an example of appcache - though maybe not telling people to use it
jo: adam, can you do a small BP around emerging offline techniques?
<EdC> The tenor of the comments seems that appcache, atomdb, etc. are examples of offline application management. The BP should then be general.
tomhume: will have atomdb looked at by next week
<jo> ACTION: Adam to write a small BP on offline techniques citing AppCache as an example (and the outome of AtomDB as appropriate) [recorded in http://www.w3.org/2009/06/09-bpwg-minutes.html#action02]
<trackbot> Created ACTION-966 - Write a small BP on offline techniques citing AppCache as an example (and the outome of AtomDB as appropriate) [on Adam Connors - due 2009-06-16].
adam: I fwded some feedback to
the member list earlier today, re large complex web apps on mid
to high-end browsers... one limitation on fast startup is JS
parse time. We have a BP around minimising latency, but the
partitioning of large scripts might be more important according
to some feedback we had.
... I don't feel we need to go into technical details re how to
partition, but it is valid feedback - if you're about to write
a web app and do it well, follow all BPs, you'll hit problems
around parse time and JS. Splitting it up is the only way to
build a good scalable web app. Given this should we pull it out
into a BP?
jo: why pull it into a separate BP if we've nothing specific to say about it?
adam: to make it more prominent?
jo: a BP without anything actionable is a problem
adam: happy to leave as is right now, wanted to flag it as feedback I had...
jo: maybe insert a note to call out this point and say it's been discussed?
adam: feedback next week would be helpful...
jo: there was an editorial meeting to update some of it. I had actions to make further comments in the doc. Phil has stepped forward to act as an ongoing editor of the doc. Status now is that I've finished making comments to the google doc, we have an editors meeting tomorrow morning (open to anyone in the group)...
<jo> Current work in progress on BP 1.5
phil: led into a false sense of security here, schmoozed and seduced by appelquist :) There's a bit more to do than I thought. Want to get it to the point where the group can take a look without a need for further protracted discussion - if it's contentious, it comes out, if it can be smoothed over, it stays in. Should put it to bed in the next 2-3 weeks.
<PhilA> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/20090609
<PhilA> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/20090610
<jo> -> Jo's comments on MobileOK Scheme and the license
<jo> Jo's comments on mobileOK Scheme and the License
phil: changes hats. I'm involved with MobileOK scheme thanks to my work with the POWDER protocol. When talking about POWDER I take off my W3C hat. This doc bears my Greek affiliation. We've been through it, the license is the issue...
jo: with phils changes and Rigo
making basic changes and clarifications to the license, we're
done on it.
... we do need a correct copy of the license, despite the need
for speed
... Can the group review it, make any comments this week, and
we'll take a resolution next week.
edC: can you remind everyone what the main issues pending last time were on mobileOK?
jo: phil wanted to clarify the status on PNG
phil: we were implying that you should have a PNG format trustmark, just after we recommended not having unnecessary icons on the screen...
jo: anything else on mobileOK
scheme?
... we can't take a resolution until we have a corrected final
license. But we can action francois to ping Rigo.
<jo> ACTION: Phila to ask Rigo to consider Jo's comments and revise mobileOK license accordingly [recorded in http://www.w3.org/2009/06/09-bpwg-minutes.html#action03]
<trackbot> Created ACTION-967 - Ask Rigo to consider Jo's comments and revise mobileOK license accordingly [on Phil Archer - due 2009-06-16].
<jo> ACTION-929?
<trackbot> ACTION-929 -- Eduardo Casais to write an abstract for CT. -- due 2009-04-02 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/929
jo: first point is eduardo's action 929
<jo> Jo's comments on EdC's Proposal
jo: eduardo was asked to put together an abstract.I agree with his points but think rewording would be of benefit. Are you happy with my rewording?
edC: Yes
jo: it's now a bit lengthy, but calls out some important points.
<jo> PROPOSED RESOLUTION: Adopt text as proposed by EdC and amended by Jo for the Acbstract (cf ACTION-929)
<jo> +1
<EdC> +1
<achuter> +1
<DKA> +1
RESOLUTION: Adopt text as proposed by EdC and amended by Jo for the Acbstract (cf ACTION-929)
<yeliz> +1
jo: next point is much more contentious, francois' action-925
<jo> ACTION-925?
<trackbot> ACTION-925 -- François Daoust to ascertain the availability of tests that ensure that same origin policy conformance, when implemented in this way, can be tested -- due 2009-04-02 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/925
jo: would rather do this with
francois here, but let's talk about it now anyway, I doubt
we'll resolve it in one go
... francois has determined that there are no existing
conformance tests we can reference to show that same-origin
niceties are observed by a transforming proxy when rewriting
links
... The resolution we took was that in the absence of such
tests we couldn't condone link-rewriting at all, never mind
https.
... So if we stick to the previous resolution, we rewrite the
doc to say "link rewriting is not acceptable", meaning all
kinds of CT proxies cannot be conformant.
<DKA> -1 to that
chaals: i've been chatted to some
of our security and testing guys. we think we could make a test
for this. we possibly have one already, i couldn't find
it...
... I've just found one!
... around cross-site scripting
jo: and cookies?
chaals: yep. The cookie thing is a consequence, right?
jo: we wouldn't want passwords in cookies sent to the wrong site
chaals: the security risk is
cross-site scripting. with that you can get cookies out, or
whatever.
... I'll find a test.
jo: is this new technology or old
technology?
... Any objections to adopting this normatively, should it pass
all the tests we expect it to?
chaals: Luca does.
jo: he's not a member of this group, but we'll take his view into account.
edC: I'd immediately put an action to someone on what the status of taking over tests from external parties is. Who will maintain these tests, etc?
jo: interesting point. if charles
submits it to a group in contribution, there's no IP impediment
to the group in using it.
... on maintenance, isn't this in the normal run of maintenance
of the document? I'm not sure it's a different question.
chaals: the group has to agree this test is valid first of all. Subsequent to them agreeing, the group can go ahead and use it.
jo: what does anyone feel about us verifying the test is adequate?
edC: how do we do this?
... what do developers and contributors to it claim that it
covers?
chaals: The one I'm looking at right now covers the ability to do a cross-site request.
jo: irrespective of this, how do
we verify cookies are not sent between sites they shouldn't be
sent between?
... given that you're using transcoder.mobi and a browser will
think all cookies are for transcoder.mobi and not hte origin
site, how do we ensure transcoder.mobi intercepts cookies
correctly?
chaals: that's not the test I have right now, but I'll find out
jo: anyone else got
comments?
... for link rewriting, we can put chaals' tests into the
conformance requirements, if we agree with them, and we can
move ahead.
<DKA> +1 to this proposal.
<SeanP> Seems reasonable to me.
<jo> ACTION: Chaals to forward tests for Xss and cookie handling to group [recorded in http://www.w3.org/2009/06/09-bpwg-minutes.html#action04]
<trackbot> Could not create new action - please contact sysreq with the details of what happened.
<trackbot> Could not create new action - please contact sysreq with the details of what happened.
<jo> [from F2F and now at 4.2.9.3 of the CT doc:]
<jo> Interception of HTTPS and the circumstances in which it might be permissible is not a "mobile" question, as such, but is highly pertinent to this document. The BPWG is aware that interception of HTTPS happens in many networks today. Interception of HTTPS is inherently problematic and may be unsafe. THe BPWG would like to refer to protocol based "two party consent" mechanisms, but such...
<jo> ...mechanisms do not exist at the time of writing of this document.
<jo> The practice of intercepting HTTPS links is strongly NOT RECOMMENDED.
jo: next point is around https
rewriting. we resolved this at the F2F to say (see above)
... it turns out RFC2119 doesn't contain the term "NOT
RECOMMENDED" so we'll need to rewrite it
... the doc goes on to say what you must do if, nonetheless,
you rewrite links.
<jo> HTTPS Link Rewriting
<jo> qck t
<Zakim> tomhume, you wanted to wonder what NOT RECOMMENDED becomes
jo: NOT RECOMMENDED would become SHOULD NOT
<chaals> [would be "should not" as Jo says]
seanP: rfc2119 contains "NOT
RECOMMENDED" as a synonym for SHOULD NOT
... so no need to change.
phil: copying and pasting stuff can trip you up...
jo: so action is to add this to the keywords section of the document
<jo> ACTION: Jo to add NOT RECOMMENDED to the rfc2119 section of the document [recorded in http://www.w3.org/2009/06/09-bpwg-minutes.html#action05]
<trackbot> Created ACTION-968 - Add NOT RECOMMENDED to the rfc2119 section of the document [on Jo Rabin - due 2009-06-16].
jo: if there's no further comment
on this (and bearing in mind other comments from the list)
let's move on
... can people kindly review that document, only been out 2
days. I'd like to propose a resolution for next week that we
take it to last call a second time.
... it has a couple of dangling ends but not many. one of them
is francois recreating the conformance statement, we also need
to formally respond to the previous last call before we do a
new one, but that's a technicality.
... comments?
jo: anyone?
<francois> [I haven't seen the explicit list of new X-Device-<foo> HTTP headers in the doc, is it normal?]
<jo> [yes, francois, I think I inserted text, per the resolution]
<jo> [wel,, I *hope* so anyway]
<jo> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/open
<francois> [ok, I'll have a closer look and will follow up on the mailing-list if needed]
<jo> ACTION-694?
dka: this one was overtaken by events. I think this one needs closing.
<jo> close ACTION-694
<trackbot> Getting info on ACTION-694 failed - alert sysreq of a possible bug
<jo> ACTION-783?
adam: suspect this is obsolete. i think we talked about web 2.0 technologies and decided the term was naff, but have long ago replaced it.
<jo> close ACTION-783
<jo> ACTION-783?
dka: ACTION-787 not done. Still relevant, needs to be done. I'll do it.
<jo> ACTION-787?
dka: did this, it didn't result in anything useful. i think it needs closing.
<jo> ACTION-788?
<jo> Close ACTION-788
adam: suspect ACTION-794 relates to MVC for web apps
jo: we'll leave ACTION-794
open
... ACTION-796 on dan
<brucel> have a meeting - bye
dka: not yet complete. hasn't been the right time to do it.
jo: we'll leave 796 open
<jo> Close ACTION-820
jo: suggest we close 820 in jeffs
absence, because it's reaching a conclusion anyway. alan,
yeliz?
... hear no objection
<yeliz> no objection
<jo> ACTION-855?
jo: action-870
<jo> ACTION-870?
dka: not done. keep it open.
jo: action-873 on dan
dka: same as the other one.
<jo> Close ACTION-877
jo: 877 is francois' but I think
we can close it, done.
... 892 is on conformance, francois did this but it's pending
review.
<jo> Alan's list
<jo> ACTION-894?
jo: 894 is on adam.
adam: I reviewed this OOB. It's
about accessibility.
... probably still relevant.
<jo> brucel ... still on call?
<jo> ACTION-898
jo: 905 on dan.
dka: not done, leave it open.
jo: 906 on adam.
adam: I think those BPs have changed. I think this is done, it refers to the BPs as they were in a previous draft
jo: let's close it then.
<jo> Close ACTION-906
<jo> Close ACTION-909
yeliz: i think 909 can be closed
jo: 913 we can close?
<jo> Close ACTION-913
<chaals> [Bruce claims to have completed action 898, btw]
<DKA> um...
jo: 918... dan?
<brucel> sorry all, had to dash out
jo: 919, adam?
adam: done and resolved.
<jo> CLOSE ACTION-919
<brucel> there was an action on me, Chaals pinged to say
jo: 920 on dan...
dan: got bryan here now. this is related to mwabp? tempted to close it.
<jo> Close ACTION-920
<jo> Close ACTION-921
<jo> Close ACTION-923
<jo> Close ACTION-929
<jo> Close ACTION-952
<jo> Close ACTION-953
<jo> Close ACTION-954
<jo> Close ACTION-961
<jo> Close ACTION-963
<jo> Close ACTION-965
jo: aob?
<yeliz> bye
<jsmanrique> bye
<miguel> bye
bye all
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/euphemism/synonym/ Succeeded: s/Close ACTION-797/Close ACTION-820/ Succeeded: s/RRSAgent make logs public// Found Scribe: tomhume Inferring ScribeNick: tomhume Default Present: DKA, tomhume, +03531522aaaa, chaals, +0207881aabb, brucel, adam, Phil_Archer, miguel, yeliz, +41.31.972.aacc, achuter, EdC, jo, +1.630.414.aadd, SeanP, manrique Present: DKA tomhume +03531522aaaa chaals +0207881aabb brucel adam Phil_Archer miguel yeliz +41.31.972.aacc achuter EdC jo +1.630.414.aadd SeanP manrique Regrets: Francois Abel Kai Nacho Agenda: http://lists.w3.org/Archives/Public/public-bpwg/2009Jun/0016.html Found Date: 09 Jun 2009 Guessing minutes URL: http://www.w3.org/2009/06/09-bpwg-minutes.html People with action items: adam chaals jo phila[End of scribe.perl diagnostic output]