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
<darobin> Scribe: Paddy
<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-minutes.html#action01]
<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-minutes.html#action02]
<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-minutes.html#action03]
<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-minutes.html#action04]
<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-minutes.html#action05]
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-minutes.html#action06]
<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
<richt> .me thanks! bye
fjh: adjourned
<fjh> p+ foo_bar
<fjh> s/abotu/about/
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/uses/use cases/ Succeeded: s/and the most important info only// Succeeded: s/simple,/simple, and bandwidth appears to be listed. may need extensibility/ Succeeded: s/meing/being/ Succeeded: s/programmtic/programmatic/ Succeeded: s/wouldhe/would he/ Succeeded: s/'fmi;/for my information, / Succeeded: s/Ilkjka/ilkka/ Succeeded: s/approach/approach to HTML5/ Succeeded: s/approach/approach into HTML5/ Succeeded: s/abotu/about/ Succeeded: s/if I stop talking at some point, it'll be because I've passed out from the heat :)// Succeeded: s/ p+ erica_newland// FAILED: s/abotu/about/ Found Scribe: Paddy Found ScribeNick: paddy Found ScribeNick: paddy Present: Robin_Berjon Frederick_Hirsch James_Salsman Dan_Burnett Neil_Stratford Ilkka_Oksanen James_ Salsman Anssi_Kostiainen Suresh_Chitturi Alissa_Cooper Dominique_Hazael-Massieux Erica_Newland erica_newland John_Morris Paddy_Byers Maria_Oteo Richard_Tibbett Daniel_Coloma Ingmar_Kliche Regrets: Laura_Arribas Marco_Marengo Niklas_Widell Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0031.html Found Date: 07 Jul 2010 Guessing minutes URL: http://www.w3.org/2010/07/07-dap-minutes.html People with action items: dom kangchan robin wonsuk[End of scribe.perl diagnostic output]