See also: IRC log
<trackbot> Date: 07 July 2010
<darobin> nstratford: welcome to the group! it'd be nice if you could introduce yourself a little at the beginning of the call
<enewland> p+ erica_newland
<darobin> Scribe: Paddy_Byers
<darobin> ScribeNick: paddy
<scribe> scribenick:paddy
<fjh> james question - initial configuration vs remote management
fjh: I sent out a draft agenda for the F2F.
... the F2F will be next week
... We have had logistics issues with the size of the room
... so far I think all latecomers have been accommodated
<darobin> F2F agenda draft
fjh: if you think you're coming, pls make sure Dom knows
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0042.html
dom: you absolutely need to be registered if you're coming
<fjh> please indicate if you have any comment or suggestions on the agenda
dom: we are again fitting in the maximum number that we can accommodate
<fjh> logistics page http://www.w3.org/2009/dap/wiki/LondonF2F2010
fjh: logistics page is up
... I think this has all the details you need
... Anything else to say about F2F?
... the timing: it is Weds-Fri
... different times each day so check the agenda
<fjh> http://www.w3.org/mid/503B5689-741F-437E-AE13-8E613ECCE84F@nokia.com
RESOLUTION: Minutes from 30 June approved
fjh: Just sent a reply to Dom to the list
... I understand where you're coming from but wonder if we are just going to reinvent XACML
... I guess you've suggested a couple of things in your email
<dom> Dom's reply to FJH's reply
fjh: then go from there, eg try to incrementally invent WARP
... but I think these things are so different
... on the other hand, we already have contributions that address these issues
... perhaps we have more of a model than we think we do
paddy: in BONDI tried to do something simple but ended up with XACML to avoid reinventing the wheel
fjh: as soon as there is any complexity, you will end up with something similar
dom: I agree, I replied to the message with clarifications
... waht i meant by suggestio n to extend WARP wasn't intended to substitute for policy framework
... but instead to address another part of the problem
... ie the part where authors declare what they want to do
... now, having looked more closely at WARP and how it is used for widgets
... I don't think that the framework we have fits very well with the kinds of restrictions we might want to impose
... .eg restrictions that are specific to the way an API works
... so I think we need to look at a representative sample of APIs
... before we can know whether or not the model is applicable
... but not questioning whether or not XACML is the might model approach
... still not convinced that we understand the space of restrictions well enough
... one of the things I sought to do in my reply is to take an action to look are one or two APIs more closely
... as exemplars
fjh: I think what you're saying is that it is hard to link the abstract model to actual APIs
... and I agree with this
<dom> ACTION: Dom to document a couple of APIs restrictions and see how it impacts policy work [recorded in http://www.w3.org/2010/07/07-dap-irc]
<trackbot> Created ACTION-205 - Document a couple of APIs restrictions and see how it impacts policy work [on Dominique Hazaël-Massieux - due 2010-07-14].
fjh: I will read the mail more carefully
... anyone else can help?
... also, is someone in a position to be able to approach the browser aspects as well?
James: I would like to review all of the APIs from a consumer perspective
... and look at the privacy and policy implications of all of their interactions
fjh: we started to look at privacy already, but if you could look at policy especially that would be good
James: what aspects, other than privacy, do we wish to control?
fjh: Well there are several concerns addressed by access control
... there may be external control for various business reasons
... as well as user-driven control
... avoidance of prompts is one aspect
James: I would like to see something based on initial configuration
... I don't think that's incompatible with user-selectable preferences
... I would be happy to look through all the APIs with this in mind
fjh: I think the issue is how to convert concepts into something concrete, usable, deployable, yet not too simpistic
... if you could do that, and send to list, that would be great
... I don't have much more to say
darobin: don't have much to add
... but if we are looking at usage situations for widgets then we should look at <feature>
Suresh: a couple of observations
... for WARP, we think it is designed for widget authors to declare their intent
... .however <feature> element is exactly that
... but <access> talks about policy-based access
<fjh> need for review and applicability of feature and access elements as currently defined
Suresh: eg the spec says that in the default policy the UI must deny access
... so I think it is specified in-between author's intent and actual policy
... so I see some correlation but maybe not usable for our purposes as-is
... when I look at the policy framework I see three variables:
... what I think would be interesting would be to see if we can come up with a schema like config.xml in Widgets
... perhaps we could come up with a simple expression language
... if we add some attribute for environments to config.xml would that be enough?
... I would like to see how far we can do by extending what was done in Widgets
fjh: I think the XACML model alread applies to what you are talking about
... so it is a question of tying the abstract model to the concrete things we do
... I don't think we need to rework the model itself
... I'm against having a separate but "equivalent" language
suresh: just looking on the face of it we should be able to come up with something simpler
fjh: we have a list of abuse cases but not enough "use cases"
<fjh> paddy notes confusion between parties, e.g. WARP sites to request access, default deny, if request, get it by default., access element.
<fjh> paddy notes runtime should be also able to use policy determined by someone other than web site author, to manage access
<fjh> suresh asks who whether author is policy writer
<fjh> paddy responds that this is noted in the BONDI use cases, various roles and process
<dom> (policy wins over the authors intents)
suresh: thanks for the clarification
<fjh> need to separate author stated intent and runtime policy
suresh: it looks like do want to separate the author's intent from the runtime policy
fjh: anything anyone else can do before F2F?
... I will take a look again at the BONDI docs
... one other discussion relating to permissions API
... but lets leave that discussion to the list
darobin: I was hope to close the last ongoing issues with sysinfo
... but we don't have Bryan and I'm reluctant to make decisions in his absence
James: I have a serious disagreement about some of this
... I think there are seious privacy implications and implications on us as engineers
<fjh> ACTION-204?
<trackbot> ACTION-204 -- Robin Berjon to step into the Bryan/James thread in the hope of helping find consensus -- due 2010-07-07 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/204
<darobin> close ACTION-204
<trackbot> ACTION-204 Step into the Bryan/James thread in the hope of helping find consensus closed
James: so where is the line between the information needed that customers will expect versus privacy
... customers and consumers will expect that corporations adhere to thie expectations wrt privacy
... the line between privacy concerns and database schema is an extrmely blurry line
darobin: I don't think there is a dispute about whether or not these issues exist
<dom> James' list of information he wants added in Network interface
darobin: but the issue is whether or not we address them in these fields in sysinfo
James: I didn't expect it to come up here either
... I guess I can say positively that AT&T do not degrade DNS quality
... they don't actually return invalid database results
... but some companies are know to do this
<richt> well, what can we do about that at the API level?
James: that's the kind of esoteric issue we can't deal with
<Zakim> dom, you wanted to suggest this is not something that device typically provides info on
James: but issues as to whether or not DNS is accurate is an issue that we can deal with, and seems to me to be necessary
... if it's not necessary then I'd like to hear why
dom: I don't think the question is whether it is important or not
... but I don't think the information is available from the device
... so we wouldn't necessarily expose it through a device API
... I think it is clearly out of scope
... so sysinfo seems to be pretty much finished based on info you can get from the device
James: ifconfig output would give you the information needed to determine bandwith
... similarly you could determine whether or not certain DNS requests are resolved
dom: but these are network info issues
James: but a network device is just another kind of system device
darobin: I think it is too low level
fjh: I'd like to ask 2 things:
... first, bandwidth is there as a property so isn't this already addressed?
... second, we have already been discussing privacy extensively
... this has already been pruned to keep it simple, and bandwidth appears to be listed. may need extensibility
... it could be refined later
thomas: take the DNS thing as an example
... there are other organisations that deal with this sort of thing
... and make very clear statements about what is expected of DNS
... there is a large ecosystem of politics, business etc about that
... also issues relating to whether or not you can do peer-to-peer for example
... the way a lot of those sort of politics work out is that people look for win-win situations
... and this requires all relevant parties to be at the table
... such as the network operations divisions of companies
... and getting to a real win-win is more than just creating a javascript API
... so since we can't do that I suggest that we keep our own task to just defining the API
... that is not intended to understate the importance of what you're raising
jmorris: I agree with thomas
... making these issues a precondition to defining an API seems like it will just stall us
... but we should think about how to address it in other fora
... to get networks to be as transparent as possible
... once that happens, we can think about how to expose that info to a web applciation
james: where do you draw the line: eg bandwidth?
<tlr> +1 to John
jmorris: we've limiting it to things we can reasonably expect a device to know
... we do not generally have access to this information right now
... but I think right now there is no common datapoint whereby a device can discover the privacy policy of its network
james: I think most of the issues a device can figure out does not include the privacy policy
... I think we can make progress on it after the privacy F2F
<fjh> should we add to document note that the items are those that the device can figure out itself?
james: and a format is needed to be able to express such policies
... since then networks will be able to see how they can be measured
... instead of being measured just on their marketing capability
... and the possibilities should not be dismissed lightly
darobin: you are preaching to the choir here
jmorris: I agree it would be great to discuss outside of DAP
james: I have to ask: where is the right place to address this?
darobin: I think the W3C staff can help us understand the right place to address this?
... on sysinfo is we assume that the current issue is moved out of scope
... then are we nearing publishability? Shall we go to CfC or wait for Bryans' input?
james: I'd like to ask that the decision is delayed until after the privacy workshop
darobin: it would be after the w'shop anyway because there is a 1 week comment period
<richt> Agree with jmorris. I think we should also delay the decision until after the F2F...still a lot for Bryan to respond to
darobin: any objection to CfC?
dom: I object, based on the upcoming w'shop and F2F
... which will limit the time available for thorough review
... personally I will not have time to review
... I will not formally object but I would rather not
<darobin> PROPOSED RESOLUTION: Two weeks CfC on SysInfo LC
darobin: would it be OK to say the CfC period is 2 weeks?
<tlr> +1 to two weeks
<richt> yep, two weeks would be good as Dom said.
fjh: remember there probably won't be a meeting in 2 weeks
darobin: we can decide by email
RESOLUTION: Two weeks CfC on SysInfo LC
richt: want to talk about DOM integation of the contacts API
... as discussed on the email
... so unifying what you can do via a non-form-based control as well as by programmatic means
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0026.html
richt: key question is where would the work be done? bearing in mind how close this is to the discussion in HTML5?
... should the two groups work together?
darobin: we can definitely do work on this and coordinate if there is interest
risht: the same discussion relates to other areas
... and there are interesting topics to discuss between the groups
... the same issue arises with MediaCapture
suresh: just a question for richt for clarification:
... can you clarify what is the advantage of this approach, and does it have the same power as the JavaScript approach?
... you can get access to the contact list but do you have the same functionality you would have from JavaScript?
richt: you can get the objects by declarative means, but then use the objects via JavaScript in the same way
<darobin> [+1 to Dom]
richt: you can use the JavaScript API to do the same operations
suresh: we have this service.contacts to get access to the contacts object
... is that the main distinction?
<Zakim> dom, you wanted to ask about formally bringing <device> in DAP, and to suggest keeping contacts API as is for now
dom: I think we have talked about <device> again and again
... eg capture, and now contacts
... the proposal made by Hixie to DAP.
... would he be interested in making a formal proposal to DAP?
... I think integration with the <device> tag is interesting
... but perhaps we should leave that to a later stage and concentrate on the current API for now
fjh: do we need a formal action or resolution here?
<darobin> [we can ask HTML WG, rather than WG]
dom: we need an action for someone to get in contact with Hixie
richt: don't want it to lose its place in the HTML spec
... but I don't want to lose it from DAP either
suresh: are we going to have a problem with HTML5 being a moving target?
dom: there will be issues but they can be addressed
<richt> that's it for contacts. everything else will be discussed at the F2F next week.
dom: but the main question is whether or not we have an interest in working on that aspect of the spec
... including having an editor, and dealing with issues with IPR commitments etc
<richt> fyi, someone will lead the API discussion now that darobin has left?
<richt> sorry...for my information, I guess
ilkka: I have found it problematic to add attributes to MediaCapture because of the way the HTML5 spec is written with no scope for extension
fjh: so are you saying it should not go into DAP?
<dom> [note that if we leave it to the HTML WG, it won't be taken up before X years]
Ilkka: yes, what we have now in DAP would be better moved into HTML5
fjh: my suggestion is that someone talks to hixie
... maybe dom can talk to see what his reaction is before we progress with this discussion
<dom> ACTION: Robin to contact Hixie about future of <device> tag work [recorded in http://www.w3.org/2010/07/07-dap-irc]
<trackbot> Created ACTION-206 - Contact Hixie about future of <device> tag work [on Robin Berjon - due 2010-07-14].
<scribe> ACTION: Robin to talk to Ian Hickson about interaction with HTML5 [recorded in http://www.w3.org/2010/07/07-dap-irc]
<trackbot> Created ACTION-207 - Talk to Ian Hickson about interaction with HTML5 [on Robin Berjon - due 2010-07-14].
fjh: is there anything to be said on this call?
AnssiK: I put in some feedback on Gallery, until then it had been dormant
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.html
AnssiK: perhaps now there will be some discussion
... you had some concrete conments
<dom> (editors are Kangchan and Wonsuk)
AnssiK: is there something specific that the WG needs to decide, or can the editor deal with this?
... I think we should make the simplest use cases easy
<dom> ACTION-143?
<trackbot> ACTION-143 -- Anssi Kostiainen to provide feedback on the list on Gallery API -- due 2010-06-15 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/143
AnssiK: so I proposed dropping the galleries interface completely
<richt> I agree with Anssi's sentiment of dropping the Gallery API.
AnssiK: concentrate on the high-value use cases of accessing media objects and metadata
... I think also same API design could be shared with contacts
fjh: have people had a chance to look at this?
... I think we can agree on it at the F2F
<fjh> ACTION: Wonsuk to review comments from anssi http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.html [recorded in http://www.w3.org/2010/07/07-dap-irc]
<trackbot> Created ACTION-208 - Review comments from anssi http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.html [on WonSuk Lee - due 2010-07-14].
AnssiK: I know that this API, as it stands now, is not useful
<fjh> ACTION:kangchan to review comments from anssi http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.htm [recorded in http://www.w3.org/2010/07/07-dap-irc]
AnssiK: you cannot do anything with it except get metadata
<fjh> ACTION: kangchan to review comments from anssi http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.htm [recorded in http://www.w3.org/2010/07/07-dap-irc]
<trackbot> Created ACTION-209 - Review comments from anssi http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.htm [on Kangchan Lee - due 2010-07-14].
AnssiK: you cannot get the media data (eg images) itself
... what is believed to be the status (eg how much done)?
... I would say it is a very early draft
<richt> ...the Gallery API is a copy from BONDI. I think an API based around the FileSystem API with the MediaArray interface in Media Capture API would be a much more sensible approach.
<AnssiK> perhaps I'll send my additional comments to the ML
fjh: thanks AnssiK
<AnssiK> One additional comment was that shouldn't there be a uri/url/URL attribute on MediaObject object? Perhaps MediaObject could inherit from Blob?
fjh: There was an ETA question from darobin
<dom> Media Capture API restructured
fjh: there has been various discussions on the email list
... what would you like to discuss?
ilkka: there are two versions of capture API
<fjh> Form Based Access: http://dev.w3.org/2009/dap/camera/Overview.html
<fjh> Programmatic API: http://dev.w3.org/2009/dap/camera/Overview-API.html
ilkka: one is about form-based capture with the <input type=file> element
... the other is pure JavaScript API
... on the mailing list there is discussion ongoing about more detailed aspect of each specification
... I think this is best discussed on the mailing list
fjh: can this be done before the F2F so we can make decisions?
ilkka: I think the detailed issues are solvable
... but the main question as to whether or not we move the form-based approach to HTML5
... will not be solved by then
James: I agree with supporting the form-based approach into HTML5
... but using the JavaScript API can you capture and then store the captured media to a file?
ilkka: yes, if you have FileWriter (which may trigger a prompt)
<richt> I would like to support both approaches. JS API approach with well-defined interfaces AND a form-based approach hooking in to low-level JS API interfaces. It is very doable IMO.
fjh: just to clarify, are you supportive of the form-based approach?
James: I am in favour of both
fjh: It sounds like people are generally in favour
... apart from the question of where things should be moved, we are close to settling it
ilkka: lets address it at the F2F
fjh: anything new to be said?
... nothing new
fjh: where are we with messaging?
danielcoloma: we sent a message a few hours ago
... we are preparing a new proposal now
<dom> Plan for update of messaging API
danielcoloma: we will submit before F2F
fjh: thanks - anything else to discuss?
suresh; I think the best way forward is to pick up where we left off, which is what Daniel seems to be doing
scribe: if we can pick up from the earlier thread it would be a good start
danielcoloma: yes, that's what we are doing
fjh: Propose no calls on 21 July and 28 July
... so next call is 4 August
... any objection or concern?
RESOLUTION: calls on 21 July and 28 July are cancelled
fjh: is that it?
... if not, lets adjourn
... see you next week
... we have published agenda and we will do the best we can to stick to it
... but flexibility is required
suresh: appreciate putting my topics in the afternoon
... but happy to be flexible
... is there a bridge set up?
dom: I have confirmation that we can have a bridge
fjh: adjourned