IRC log of dap on 2010-07-07

Timestamps are in UTC.

13:23:47 [RRSAgent]
RRSAgent has joined #dap
13:23:47 [RRSAgent]
logging to
13:23:49 [trackbot]
RRSAgent, make logs world
13:23:49 [Zakim]
Zakim has joined #dap
13:23:51 [trackbot]
Zakim, this will be DAP
13:23:51 [Zakim]
ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 37 minutes
13:23:52 [trackbot]
Meeting: Device APIs and Policy Working Group Teleconference
13:23:52 [trackbot]
Date: 07 July 2010
13:24:44 [fjh]
13:43:23 [Fan_HU]
Fan_HU has joined #dap
13:52:04 [darobin]
darobin has joined #dap
13:54:12 [Zakim]
UW_DAP()10:00AM has now started
13:54:19 [Zakim]
+ +1.650.335.aaaa
13:55:40 [AnssiK]
AnssiK has joined #dap
13:56:33 [burn]
burn has joined #dap
13:56:42 [fjh]
Chair: Robin_Berjon, Frederick_Hirsch
13:56:44 [darobin]
RRSAgent, pointer?
13:56:44 [RRSAgent]
13:56:53 [fjh]
Present+ Robin_Berjon, Frederick_Hirsch
13:57:19 [Zakim]
13:57:23 [darobin]
if I stop talking at some point, it'll be because I've passed out from the heat :)
13:58:29 [darobin]
nstratford: welcome to the group! it'd be nice if you could introduce yourself a little at the beginning of the call
13:58:51 [fjh]
Regrets+ Laura_Arribas, Marco_Marengo, Niklas_Widell
13:58:58 [burn]
Present+ James_Salsman
13:59:09 [burn]
Present+ Dan_Burnett
13:59:25 [Zakim]
+ +44.135.388.aabb
13:59:45 [burn]
zakim, Voxeo is Dan_Burnett,Neil_Stratford
13:59:45 [Zakim]
+Dan_Burnett,Neil_Stratford; got it
13:59:45 [nstratford]
Present+ Neil_Stratford
13:59:46 [Zakim]
13:59:52 [fjh]
zakim, [IPcaller] is me
13:59:52 [Zakim]
+fjh; got it
13:59:57 [Zakim]
14:00:00 [Zakim]
14:00:04 [darobin]
Zakim, [IPCaller] is me
14:00:04 [Zakim]
+darobin; got it
14:00:15 [fjh]
zakim, who is here?
14:00:15 [Zakim]
On the phone I see +1.650.335.aaaa, Dan_Burnett,Neil_Stratford, +44.135.388.aabb, fjh, darobin, ilkka
14:00:18 [Zakim]
On IRC I see burn, AnssiK, darobin, Zakim, RRSAgent, nstratford, wmaslowski, fjh, tlr, shepazu, Marcos, lgombos, trackbot, dom, ilkka, ingmar
14:00:19 [nstratford]
zakim, aabb is nstratford
14:00:19 [Zakim]
+nstratford; got it
14:00:25 [burn]
zakim, Dan_Burnett,Neil_Stratford is Dan_Burnett
14:00:25 [Zakim]
+Dan_Burnett; got it
14:00:30 [ilkka]
Present+ Ilkka_Oksanen
14:00:51 [Zakim]
+ +1.202.436.aacc
14:00:53 [fjh]
Present+ James_ Salsman
14:00:56 [Zakim]
14:01:00 [AnssiK]
Present+ Anssi_Kostiainen
14:01:02 [fjh]
zakim, who is here?
14:01:02 [Zakim]
On the phone I see +1.650.335.aaaa, Dan_Burnett, nstratford, fjh, darobin, ilkka, +1.202.436.aacc, AnssiK
14:01:04 [Zakim]
On IRC I see burn, AnssiK, darobin, Zakim, RRSAgent, nstratford, wmaslowski, fjh, tlr, shepazu, Marcos, lgombos, trackbot, dom, ilkka, ingmar
14:01:07 [Suresh]
Suresh has joined #dap
14:01:13 [burn]
zakim, Dan_Burnett is me
14:01:13 [Zakim]
+burn; got it
14:01:19 [Suresh]
Present+ Suresh_Chitturi
14:01:22 [Zakim]
14:01:23 [paddy]
paddy has joined #dap
14:01:24 [alissa]
alissa has joined #dap
14:01:35 [dom]
zakim, ??P20 is probably me
14:01:35 [Zakim]
+dom?; got it
14:01:40 [dom]
zakim, mute me
14:01:40 [Zakim]
dom? should now be muted
14:01:42 [alissa]
Present+ Alissa_Cooper
14:01:48 [enewland]
enewland has joined #dap
14:02:00 [enewland]
p+ erica_newland
14:02:00 [alissa]
zakim, +1.202.436.aacc is alissa
14:02:00 [Zakim]
+alissa; got it
14:02:10 [dom]
Present+ Dominique_Hazael-Massieux
14:02:11 [fjh]
zakim, who is here?
14:02:11 [Zakim]
On the phone I see +1.650.335.aaaa, burn, nstratford, fjh, darobin, ilkka, alissa, AnssiK, dom? (muted)
14:02:13 [Zakim]
On IRC I see enewland, alissa, paddy, Suresh, burn, AnssiK, darobin, Zakim, RRSAgent, nstratford, wmaslowski, fjh, tlr, shepazu, Marcos, lgombos, trackbot, dom, ilkka, ingmar
14:02:22 [dom]
Present+ Erica_Newland
14:02:23 [enewland]
present+ erica_newland
14:02:29 [jmorris]
jmorris has joined #dap
14:02:33 [Zakim]
14:02:35 [Zakim]
+ +1.972.373.aadd
14:02:40 [fjh]
zakim, aaaa salsman
14:02:40 [Zakim]
I don't understand 'aaaa salsman', fjh
14:02:46 [dom]
zakim, aaaa is James_Salsman
14:02:46 [Zakim]
+James_Salsman; got it
14:02:53 [jmorris]
Present+ John_Morris
14:02:56 [Suresh]
zakim, aadd is Suresh
14:02:56 [Zakim]
+Suresh; got it
14:02:56 [dom]
Present+ James_Salsman
14:03:12 [fjh]
zakim, who is here?
14:03:12 [Zakim]
On the phone I see James_Salsman, burn, nstratford, fjh, darobin, ilkka, alissa, AnssiK, dom? (muted), jmorris, Suresh
14:03:14 [Zakim]
On IRC I see jmorris, enewland, alissa, paddy, Suresh, burn, AnssiK, darobin, Zakim, RRSAgent, nstratford, wmaslowski, fjh, tlr, shepazu, Marcos, lgombos, trackbot, dom, ilkka,
14:03:16 [Zakim]
... ingmar
14:03:27 [Zakim]
+ +1.301.581.aaee
14:03:40 [jmorris]
zakim, aaee is jmorris
14:03:40 [Zakim]
+jmorris; got it
14:03:43 [fjh]
zakim, who is here?
14:03:43 [Zakim]
On the phone I see James_Salsman, burn, nstratford, fjh, darobin, ilkka, alissa, AnssiK, dom? (muted), jmorris, Suresh, jmorris.a
14:03:46 [Zakim]
On IRC I see jmorris, enewland, alissa, paddy, Suresh, burn, AnssiK, darobin, Zakim, RRSAgent, nstratford, wmaslowski, fjh, tlr, shepazu, Marcos, lgombos, trackbot, dom, ilkka,
14:03:49 [Zakim]
... ingmar
14:03:49 [Zakim]
14:03:52 [enewland]
zakim, jmorris is enewland
14:03:52 [Zakim]
+enewland; got it
14:03:58 [maoteo]
maoteo has joined #dap
14:04:04 [fjh]
zakim, who is here?
14:04:04 [Zakim]
On the phone I see James_Salsman, burn, nstratford, fjh, darobin, ilkka, alissa, AnssiK, dom? (muted), enewland, Suresh, jmorris.a, ??P25
14:04:06 [paddy]
zakim, ??P25 is paddy
14:04:07 [Zakim]
On IRC I see maoteo, jmorris, enewland, alissa, paddy, Suresh, burn, AnssiK, darobin, Zakim, RRSAgent, nstratford, wmaslowski, fjh, tlr, shepazu, Marcos, lgombos, trackbot, dom,
14:04:10 [Zakim]
... ilkka, ingmar
14:04:10 [Zakim]
+paddy; got it
14:04:17 [paddy]
present+ Paddy_Byers
14:04:31 [maoteo]
Present+ Maria_Oteo
14:04:47 [darobin]
Scribe: Paddy
14:04:50 [fjh]
zakim, who is here?
14:04:50 [Zakim]
On the phone I see James_Salsman, burn, nstratford, fjh, darobin, ilkka, alissa, AnssiK, dom? (muted), enewland, Suresh, jmorris.a, paddy
14:04:52 [Zakim]
On IRC I see maoteo, jmorris, enewland, alissa, paddy, Suresh, burn, AnssiK, darobin, Zakim, RRSAgent, nstratford, wmaslowski, fjh, tlr, shepazu, Marcos, lgombos, trackbot, dom,
14:04:53 [darobin]
ScribeNick: paddy
14:04:55 [Zakim]
... ilkka, ingmar
14:05:11 [paddy]
14:05:47 [Zakim]
+ +49.133.7.aaff
14:05:48 [richt]
richt has joined #dap
14:05:57 [fjh]
james question - initial configuration vs remote management
14:06:23 [Zakim]
14:06:30 [richt]
Present+ Richard_Tibbett
14:06:52 [maoteo]
zakim, who is here
14:06:52 [Zakim]
maoteo, you need to end that query with '?'
14:07:01 [maoteo]
zakim, who is here?
14:07:01 [Zakim]
On the phone I see James_Salsman, burn, nstratford, fjh, darobin, ilkka, alissa, AnssiK, dom? (muted), enewland, Suresh, jmorris.a, paddy, +49.133.7.aaff, richt
14:07:05 [Zakim]
On IRC I see richt, maoteo, jmorris, enewland, alissa, paddy, Suresh, burn, AnssiK, darobin, Zakim, RRSAgent, nstratford, wmaslowski, fjh, tlr, shepazu, Marcos, lgombos, trackbot,
14:07:14 [Zakim]
... dom, ilkka, ingmar
14:07:23 [maoteo]
Zakim, aaff is maoteo
14:07:23 [Zakim]
+maoteo; got it
14:07:29 [paddy]
fjh: I sent out a draft agenda for the F2F.
14:07:36 [paddy]
.. the F2F will be next week
14:07:43 [dom]
14:07:45 [paddy]
.. We have had logistics issues with the size of the room
14:07:48 [dom]
ack me
14:07:56 [paddy]
... so far I think all latecomers have been accommodated
14:07:58 [darobin]
-> F2F agenda draft
14:08:07 [paddy]
... if you think you're coming, pls make sure Dom knows
14:08:16 [fjh]
14:08:21 [paddy]
dom: you absolutely need to be registered if you're coming
14:08:31 [danielcoloma]
danielcoloma has joined #dap
14:08:31 [fjh]
please indicate if you have any comment or suggestions on the agenda
14:08:36 [paddy]
.. we are again fitting in the maximum number that we can accommodate
14:08:49 [dom]
zakim, mute me
14:08:49 [Zakim]
dom? should now be muted
14:08:52 [fjh]
logistics page
14:08:54 [paddy]
fjh: logistics page is up
14:09:05 [paddy]
... I think this has all the details you need
14:09:21 [paddy]
... Anything else to say abotu F2F?
14:09:33 [paddy]
.. the timing: it is Weds-Fri
14:09:49 [paddy]
.. different times each day so check the agenda
14:10:11 [paddy]
Topic: Minutes approval from 30 June
14:10:14 [fjh]
14:10:29 [paddy]
RESOLUTION: Minutes from 30 June approved
14:10:38 [paddy]
Topic: Policy
14:10:39 [danielcoloma]
Present+ Daniel_Coloma
14:10:47 [paddy]
fjh: Just sent a reply to Dom to the list
14:10:54 [dom]
14:11:06 [paddy]
.. I understand where you're coming from but wonder if we are just going to reinvent XACML
14:11:17 [paddy]
.. I guess you've suggested a couple of things in your email
14:11:18 [dom]
-> Dom's reply to FJH's reply
14:11:34 [paddy]
... then go from there, eg try to incrementally invent WARP
14:11:37 [tlr]
zakim, call thomas-781
14:11:37 [Zakim]
ok, tlr; the call is being made
14:11:38 [Zakim]
14:11:43 [tlr]
zakim, I am thomas
14:11:43 [Zakim]
ok, tlr, I now associate you with Thomas
14:11:44 [tlr]
zakim, mute me
14:11:44 [Zakim]
Thomas should now be muted
14:11:48 [paddy]
.. but I think these things are so different
14:12:02 [paddy]
.. on the other hand, we already have contributions that address these issues
14:12:11 [paddy]
.. perhaps we have more of a model than we think we do
14:13:42 [paddy]
paddy: in BONDI tried to do something simple but ended up with XACML to avoid reinventing the wheel
14:13:55 [dom]
14:14:02 [paddy]
fjh: as soon as there is any complexity, you will end up with something similar
14:14:03 [dom]
ack me
14:14:03 [fjh]
ack dom
14:14:15 [paddy]
dom: I agree, I replied to the message with clarifications
14:14:39 [paddy]
.. waht i meant by suggestio n to extend WARP wasn't intended to substitute for policy framework
14:14:48 [paddy]
... but instead to address another part of the problem
14:15:09 [paddy]
... ie the part where authors declare what they want to do
14:15:28 [paddy]
.. now, having looked more closely at WARP and how it is used for widgets
14:15:47 [paddy]
... I don't think that the framework we have fits very well with the kinds of restrictions we might want to impose
14:15:58 [paddy]
.. .eg restrictions that are specific to the way an API works
14:16:14 [paddy]
... so I think we need to look at a representative sample of APIs
14:16:26 [paddy]
... before we can know whether or not the model is applicable
14:16:39 [paddy]
.. but not questioning whether or not XACML is the might model approach
14:17:00 [paddy]
...still not convinced that we understand the space of restrictions well enough
14:17:21 [paddy]
... 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
14:17:24 [Suresh]
14:17:26 [paddy]
... as exemplars
14:17:45 [Marcos]
Marcos has joined #dap
14:17:57 [paddy]
fjh: I think what you're saying is that it is hard to link the abstract model to actual APIs
14:18:01 [paddy]
.. and I agree with this
14:18:12 [dom]
ACTION: Dom to document a couple of APIs restrictions and see how it impacts policy work
14:18:12 [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].
14:18:19 [paddy]
... I will read the mail more carefully
14:18:39 [paddy]
... anyone else can help?
14:19:03 [paddy]
... also, is someone in a position to be able to approach the browser aspects as well?
14:19:08 [dom]
zakim, mute me
14:19:08 [Zakim]
dom? should now be muted
14:19:19 [paddy]
James: I would like to review all of the APIs from a consumer perspective
14:19:31 [paddy]
.. and look at the privacy and policy implications of all of their interactions
14:19:55 [paddy]
fjh: we started to look at privacy already, but if you could look at policy especially that would be good
14:20:09 [paddy]
James: what aspects, other than privacy, do we wish to control?
14:20:27 [paddy]
fjh: Well there are several concerns addressed by access control
14:20:39 [paddy]
.. there may be external control for various business reasons
14:20:44 [paddy]
.. as well as user-driven control
14:20:57 [paddy]
... avoidance of prompts is one aspect
14:21:11 [paddy]
James: I would like to see something based on initial configuration
14:21:22 [paddy]
.. I don't think that's incompatible with user-selectable preferences
14:21:32 [paddy]
.. I would be happy to look through all the APIs with this in mind
14:21:37 [Zakim]
14:22:03 [paddy]
fjh: I think the issue is how to convert concepts into something concrete, usable, deployable, yet not too simpistic
14:22:15 [paddy]
.. if you could do that, and send to list, that would be great
14:22:27 [paddy]
.. I don't have much more to say
14:22:35 [paddy]
darobin: don't have much to add
14:22:54 [paddy]
... but if we are looking at usage situations for widgets then we should look at <feature>
14:23:03 [fjh]
ack suresh
14:23:07 [fjh]
14:23:16 [paddy]
Suresh: a couple of observations
14:23:22 [Zakim]
14:23:29 [paddy]
.. for WARP, we think it is designed for widget authors to declare their intent
14:23:37 [richt]
richt has joined #dap
14:23:39 [paddy]
.. .however <feature> element is exactly that
14:23:51 [paddy]
... but <access> talks about policy-based access
14:23:52 [fjh]
need for review and applicability of feature and access elements as currently defined
14:24:03 [Zakim]
14:24:08 [paddy]
... eg the spec says that in the default policy the UI must deny access
14:24:26 [paddy]
.. so I think it is specified in-between author's intent and actual policy
14:24:41 [ingmar]
present+ Ingmar_Kliche
14:24:42 [paddy]
... so I see some correlation but maybe not usable for our purposes as-is
14:25:02 [paddy]
... when I look at the policy framework I see three variables:
14:25:25 [paddy]
... what I think would be interesting would be to see if we can come up with a schema like config.xml in Widgets
14:25:32 [fjh]
q+ remind of xacml
14:25:45 [paddy]
... perhaps we could come up with a simple expression language
14:26:16 [paddy]
... if we add some attribute for environments to config.xml would that be enough?
14:26:47 [paddy]
... I would like to see how far we can do by extending what was done in Widgets
14:27:00 [paddy]
fjh: I think the XACML model alread applies to what you are talking about
14:27:14 [paddy]
.. so it is a question of tying the abstract model to the concrete things we do
14:27:25 [paddy]
.. I don't think we need to rework the model itself
14:27:40 [paddy]
.. I'm against having a separate but "equivalent" language
14:28:07 [paddy]
suresh: just looking on the face of it we should be able to come up with something simpler
14:28:28 [paddy]
fjh: we have a list of abuse cases but not enough "use cases"
14:28:34 [paddy]
14:28:40 [Suresh]
14:28:41 [fjh]
ack paddy
14:29:35 [fjh]
paddy notes confusion between parties, e.g. WARP sites to request access, default deny, if request, get it by default., access element.
14:30:02 [fjh]
paddy notes runtime should be also able to use policy determined by someone other than web site author, to manage access
14:30:35 [fjh]
suresh asks who whether author is policy writer
14:31:01 [fjh]
paddy responds that this is noted in the BONDI uses, various roles and process
14:31:08 [fjh]
s/uses/use cases
14:31:51 [dom]
(policy wins over the authors intents)
14:33:12 [paddy]
suresh: thanks for the clarification
14:33:28 [fjh]
need to separate author stated intent and runtime policy
14:33:32 [paddy]
... it looks like do want to separate the author's intent from the runtime policy
14:33:50 [paddy]
fjh: anything anyone else can do before F2F?
14:34:19 [paddy]
.. I will take a look again at the BONDI docs
14:34:45 [paddy]
fjh: one other discussion relating to permissions API
14:34:54 [paddy]
.. but lets leave that discussion to the list
14:35:01 [paddy]
Topic: APIs
14:35:16 [paddy]
darobin: I was hope to close the last ongoing issues with sysinfo
14:35:31 [paddy]
.. but we don't have Bryan and I'm reluctant to make decisions in his absence
14:35:50 [paddy]
James: I have a serious disagreement about some of this
14:36:05 [paddy]
... I think there are seious privacy implications and implications on us as engineers
14:36:19 [fjh]
14:36:19 [trackbot]
ACTION-204 -- Robin Berjon to step into the Bryan/James thread in the hope of helping find consensus -- due 2010-07-07 -- OPEN
14:36:19 [trackbot]
14:36:27 [darobin]
close ACTION-204
14:36:27 [trackbot]
ACTION-204 Step into the Bryan/James thread in the hope of helping find consensus closed
14:36:34 [paddy]
.. so where is the line between the information needed that customers will expect versus privacy
14:36:57 [paddy]
... customers and consumers will expect that corporations adhere to thie expectations wrt privacy
14:37:13 [paddy]
.. the line between privacy concerns and database schema is an extrmely blurry line
14:37:32 [paddy]
darobin: I don't think there is a dispute about whether or not these issues exist
14:37:34 [dom]
-> James' list of information he wants added in Network interface
14:37:52 [paddy]
.. but the issue is whether or not we address them in these fields in sysinfo
14:38:02 [paddy]
James: I didn't expect it to come up here either
14:38:23 [dom]
q+ to suggest this is not something that device typically provides info on
14:38:24 [paddy]
.. I guess I can say positively that AT&T do not degrade DNS quality
14:38:29 [fjh]
14:38:41 [paddy]
.. they don't actually return invalid database results
14:38:51 [paddy]
.. but some companies are know to do this
14:38:59 [richt]
well, what can we do about that at the API level?
14:39:02 [paddy]
.. that's the kind of esoteric issue we can't deal with
14:39:08 [tlr]
14:39:18 [jmorris]
14:39:20 [dom]
ack me
14:39:21 [Zakim]
dom, you wanted to suggest this is not something that device typically provides info on
14:39:22 [paddy]
.. 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
14:39:33 [darobin]
ack dom
14:39:34 [paddy]
.. if it's not necessary then I'd like to hear why
14:39:55 [paddy]
dom: I don't think the question is whether it is important or not
14:40:04 [paddy]
.. but I don't think the information is available from the device
14:40:20 [paddy]
.. so we wouldn't necessarily expose it through a device API
14:40:28 [paddy]
.. I think it is clearly out of scope
14:40:48 [paddy]
... so sysinfo seems to be pretty much finished based on info you can get from the device
14:41:05 [paddy]
James: ifconfig output would give you the information needed to determine bandwith
14:41:23 [paddy]
.. similarly you could determine whether or not certain DNS requests are resolved
14:41:30 [paddy]
dom: but these are network info issues
14:41:46 [dom]
zakim, mute me
14:41:46 [Zakim]
dom? should now be muted
14:41:55 [paddy]
James: but a network device is just another kind of system device
14:42:03 [darobin]
ack fjh
14:42:07 [paddy]
darobin: I think it is too low level
14:42:17 [paddy]
fjh: I'd like to ask 2 things:
14:42:34 [paddy]
... first, bandwidth is there as a property so isn't this already addressed?
14:42:48 [paddy]
... second, we have already been discussing privacy extensively
14:42:57 [darobin]
ack thomas
14:43:04 [tlr]
ack thomas
14:43:04 [paddy]
.. this has already been pruned to keep it simple, and the most important info only
14:43:08 [paddy]
.. it could be refined later
14:43:16 [paddy]
thomas: take the DNS thing as an example
14:43:29 [paddy]
... there are other organisations that deal with this sort of thing
14:43:39 [paddy]
.. and make very clear statements about what is expected of DNS
14:43:40 [fjh]
s/and the most important info only/
14:43:59 [paddy]
... there is a large ecosystem of politics, business etc about that
14:44:16 [paddy]
... also issues relating to whether or not you can do peer-to-peer for example
14:44:26 [fjh]
s/simple,/simple, and bandwidth appears to be listed. may need extensibility/
14:44:35 [paddy]
.. the way a lot of those sort of politics work out is that people look for win-win situations
14:44:50 [paddy]
.. and this requires all relevant parties to be at the table
14:45:00 [paddy]
... such as the network operations divisions of companies
14:45:21 [paddy]
.. and getting to a real win-win is more than just creating a javascript API
14:45:45 [paddy]
.. so since we can't do that I suggest that we keep our own task to just defining the API
14:45:56 [tlr]
zakim, mtue me
14:45:56 [Zakim]
I don't understand 'mtue me', tlr
14:45:58 [darobin]
ack jmorris
14:45:59 [tlr]
zakim, mute me
14:45:59 [Zakim]
Thomas should now be muted
14:46:08 [paddy]
... that is not intended to understate the importance of what you're raising
14:46:15 [paddy]
jmorris: I agree with thomas
14:46:39 [paddy]
... making these issues a precondition to defining an API seems like it will just stall us
14:46:50 [paddy]
.. but we should think about how to address it in other fora
14:46:59 [paddy]
.. to get networks to be as transparent as possible
14:47:11 [paddy]
.. once that happens, we can think about how to expose that info to a web applciation
14:47:23 [paddy]
james: where do you draw the line: eg bandwidth?
14:47:32 [tlr]
+1 to John
14:47:43 [paddy]
jmorris: we've limiting it to things we can reasonably expect a device to know
14:47:56 [paddy]
.. we do not generally have access to this information right now
14:48:25 [paddy]
.. but I think right now there is no common datapoint whereby a device can discover the privacy policy of its network
14:48:41 [paddy]
james: I think most of the issues a device can figure out does not include the privacy policy
14:48:52 [paddy]
.. I think we can make progress on it after the privacy F2F
14:48:53 [fjh]
should we add to document note that the items are those that the device can figure out itself?
14:49:03 [paddy]
.. and a format is needed to be able to express such policies
14:49:20 [paddy]
.. since then networks will be able to see how they can be measured
14:49:33 [paddy]
... instead of meing measured just on their marketing capability
14:49:39 [jmorris]
14:49:47 [paddy]
.. and the possibilities should not be dismissed lightly
14:49:47 [fjh]
14:49:58 [darobin]
ack jmorris
14:50:06 [paddy]
darobin: you are preaching to the choir here
14:50:19 [paddy]
jmorris: I agree it would be great to discuss outside of DAP
14:50:39 [paddy]
james: I have to ask: where is the right place to address this?
14:51:04 [paddy]
darobin: I think the W3C staff can help us understand the right place to address this?
14:51:21 [paddy]
... on sysinfo is we assume that the current issue is moved out of scope
14:51:48 [paddy]
.. then are we nearing publishability? Shall we go to CfC or wait for Bryans' input?
14:52:05 [paddy]
james: I'd like to ask that the decision is delayed until after the privacy workshop
14:52:22 [dom]
14:52:23 [paddy]
darobin: it would be after the w'shop anyway because there is a 1 week comment period
14:52:24 [dom]
ack me
14:52:27 [richt]
Agree with jmorris. I think we should also delay the decision until after the F2F...still a lot for Bryan to respond to
14:52:34 [paddy]
darobin: any objection to CfC?
14:52:46 [paddy]
dom: I object, based on the upcoming w'shop and F2F
14:52:55 [paddy]
... which will limit the time available for thorough review
14:53:05 [paddy]
.. personally I will not have time to review
14:53:17 [paddy]
.. I will not formally object but I would rather not
14:53:24 [darobin]
14:53:29 [paddy]
darobin: would it be OK to say the CfC period is 2 weeks?
14:53:32 [tlr]
+1 to two weeks
14:53:32 [richt]
yep, two weeks would be good as Dom said.
14:53:44 [dom]
zakim, mute me
14:53:44 [Zakim]
dom? should now be muted
14:53:55 [paddy]
fjh: remember there probably won't be a meeting in 2 weeks
14:54:05 [paddy]
darobin: we can decide by email
14:54:24 [Zakim]
14:54:40 [paddy]
RESOLUTION: Two weeks CfC on SysInfo LC
14:55:05 [paddy]
Topic: Contacts
14:55:15 [paddy]
richt: want to talk about DOM integation of the contacts API
14:55:24 [paddy]
.. as discussed on the email
14:55:47 [paddy]
... so unifying what you can do via a non-form-based control as well as by programmtic means
14:55:47 [richt]
14:56:18 [paddy]
... key question is where would the work be done? bearing in mind how close this is to the discussion in HTML5?
14:56:29 [paddy]
.. should the two groups work together?
14:56:36 [fjh]
14:56:43 [paddy]
darobin: we can definitely do work on this and coordinate if there is interest
14:57:06 [paddy]
risht: the same discussion relates to other areas
14:57:18 [paddy]
... and there are interesting topics to discuss between the groups
14:57:51 [paddy]
.. the same issue arises with MediaCapture
14:57:51 [Suresh]
14:57:56 [darobin]
ack Suresh
14:58:05 [paddy]
suresh: just a question for richt for clarification:
14:58:28 [paddy]
... can you clarify what is the advantage of this approach, and does it have the same power as the JavaScript approach?
14:58:57 [paddy]
.. you can get access to the contact list but do you have the same functionality you would have from JavaScript?
14:59:19 [dom]
q+ to ask about formally bringing <device> in DAP, and to suggest keeping contacts API as is for now
14:59:21 [paddy]
richt: you can get the objects by declarative means, but then use the objects via JavaScript in the same way
14:59:31 [darobin]
[+1 to Dom]
15:00:01 [paddy]
.. you can use the JavaScript API to do the same operations
15:00:05 [fjh]
15:00:21 [paddy]
suresh: we have this service.contacts to get access to the contacts object
15:00:21 [fjh]
ack dom
15:00:26 [paddy]
.. is that the main distinction?
15:00:29 [Zakim]
dom, you wanted to ask about formally bringing <device> in DAP, and to suggest keeping contacts API as is for now
15:01:17 [paddy]
dom: I think we have talked about <device> again and again
15:01:27 [paddy]
.. eg capture, and now contacts
15:01:40 [paddy]
.. the proposal made by Hixie to DAP.
15:01:59 [paddy]
.. wouldhe be interested in making a formal proposal to DAP?
15:02:12 [paddy]
.. I think integration with the <device> tag is interesting
15:02:14 [fjh]
s/wouldhe/would he/
15:02:25 [paddy]
... but perhaps we should leave that to a later stage and concentrate on the current API for now
15:02:46 [paddy]
fjh: do we need a formal action or resolution here?
15:03:01 [darobin]
[we can ask HTML WG, rather than WG]
15:03:02 [richt]
15:03:09 [fjh]
ack richt
15:03:12 [dom]
zakim, mute me
15:03:12 [Zakim]
dom? should now be muted
15:03:17 [paddy]
dom: we need an action for someone to get in contact with Hixie
15:03:37 [paddy]
richt: don't want it to lose its place in the HTML spec
15:03:50 [Zakim]
15:03:50 [paddy]
... but I don't want to lose it from DAP either
15:04:01 [dom]
ack me
15:04:09 [paddy]
suresh: are we going to have a problem with HTML5 being a moving target?
15:04:18 [paddy]
dom: there will be issues but they can be addressed
15:04:39 [richt]
that's it for contacts. everything else will be discussed at the F2F next week.
15:04:39 [ilkka]
15:04:41 [paddy]
.. but the main question is whether or not we have an interest in working on that aspect of the spec
15:04:47 [fjh]
ack ilkka
15:04:52 [dom]
zakim, mute me
15:04:52 [Zakim]
dom? should now be muted
15:04:58 [paddy]
... including having an editor, and dealing with issues with IPR commitments etc
15:05:57 [richt]
fyi, someone will lead the API discussion now that darobin has left?
15:06:07 [richt]
sorry...'fmi; I guess
15:06:14 [paddy]
Ilkjka: I have found it problematic to add attributes to MediaCapture because of the way the HTML5 spec is written with no scope for extension
15:06:22 [richt]
s/'fmi;/for my information, /
15:06:27 [paddy]
fjh: so are you saying it should not go into DAP?
15:06:37 [dom]
[note that if we leave it to the HTML WG, it won't be taken up before X years]
15:06:45 [paddy]
Ilkka: yes, what we have now in DAP would be better moved into HTML5
15:06:54 [AnssiK]
15:07:19 [paddy]
fjh: my suggestion is that someone talks to hixie
15:07:38 [paddy]
.. maybe dom can talk to see what his reaction is before we progress with this discussion
15:07:46 [dom]
ACTION: Robin to contact Hixie about future of <device> tag work
15:07:46 [trackbot]
Created ACTION-206 - Contact Hixie about future of <device> tag work [on Robin Berjon - due 2010-07-14].
15:08:05 [paddy]
ACTION: Robin to talk to Ian Hickson about interaction with HTML5
15:08:05 [trackbot]
Created ACTION-207 - Talk to Ian Hickson about interaction with HTML5 [on Robin Berjon - due 2010-07-14].
15:08:19 [paddy]
Topic: Gallery
15:08:30 [paddy]
fjh: is there anything to be said on this call?
15:08:54 [paddy]
AnssiK: I put in some feedback on Gallery, until then it had been dormant
15:08:56 [fjh]
15:09:02 [paddy]
.. perhaps now there will be some discussion
15:09:11 [paddy]
.. you had some concrete conments
15:09:18 [Marcos_]
Marcos_ has joined #dap
15:09:32 [dom]
(editors are Kangchan and Wonsuk)
15:09:48 [paddy]
... is there something specific that the WG needs to decide, or can the editor deal with this?
15:10:05 [paddy]
AnssiK: I think we should make the simplest use cases easy
15:10:06 [dom]
15:10:06 [trackbot]
ACTION-143 -- Anssi Kostiainen to provide feedback on the list on Gallery API -- due 2010-06-15 -- PENDINGREVIEW
15:10:06 [trackbot]
15:10:18 [paddy]
... so I proposed dropping the galleries interface completely
15:10:37 [richt]
I agree with Anssi's sentiment of dropping the Gallery API.
15:10:40 [paddy]
.. concentrate on the high-value use cases of accessing media objects and metadata
15:10:58 [paddy]
... I think also same API design could be shared with contacts
15:11:09 [paddy]
fjh: have people had a chance to look at this?
15:11:22 [paddy]
... I think we can agree on it at the F2F
15:12:01 [fjh]
action: Wonsuk to review comments from anssi
15:12:01 [trackbot]
Created ACTION-208 - Review comments from anssi [on WonSuk Lee - due 2010-07-14].
15:12:14 [paddy]
AnssiK: I know that this API, as it stands now, is not useful
15:12:16 [fjh]
action:kangchan to review comments from anssi
15:12:30 [paddy]
... you cannot do anything with it except get metadata
15:12:36 [fjh]
action: kangchan to review comments from anssi
15:12:36 [trackbot]
Created ACTION-209 - Review comments from anssi [on Kangchan Lee - due 2010-07-14].
15:12:44 [paddy]
... you cannot get the media data (eg images) itself
15:13:01 [paddy]
... what is believed to be the status (eg how much done)?
15:13:09 [paddy]
... I would say it is a very early draft
15:13:36 [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.
15:13:39 [AnssiK]
perhaps I'll send my additional comments to the ML
15:14:08 [paddy]
fjh: thanks AnssiK
15:14:10 [AnssiK]
One additional comment was that shouldn't there be a uri/url/URL attribute on MediaObject object? Perhaps MediaObject could inherit from Blob?
15:14:13 [paddy]
Topic: Capture
15:14:26 [paddy]
fjh: There was an ETA question from darobin
15:14:45 [dom]
-> Media Capture API restructured
15:14:52 [paddy]
... there has been various discussions on the email list
15:15:05 [paddy]
... what would you like to discuss?
15:15:19 [paddy]
ilkka: there are two versions of capture API
15:15:43 [fjh]
Form Based Access:
15:15:50 [fjh]
Programmatic API:
15:15:55 [paddy]
.. one is about form-based capture with the <input type=file> element
15:16:01 [paddy]
.. the other is pure JavaScript API
15:16:21 [paddy]
... on the mailing list there is discussion ongoing about more detailed aspect of each specification
15:16:31 [paddy]
... I think this is best discussed on the mailing list
15:16:50 [paddy]
fjh: can this be done before the F2F so we can make decisions?
15:17:01 [paddy]
ilkka: I think the detailed issues are solvable
15:17:25 [paddy]
.. but the main question as to whether or not we move the form-based approach
15:17:31 [paddy]
.. will not be solved by then
15:17:47 [fjh]
s/approach/approach to HTML5
15:17:54 [paddy]
James: I agree with supporting the form-based approach
15:18:18 [paddy]
.. but using the JavaScript API can you capture and then store the captured media to a file?
15:18:34 [fjh]
s/approach/approach into HTML5
15:18:35 [paddy]
ilkka: yes, if you have FileWriter (which may trigger a prompt)
15:19:01 [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.
15:19:13 [paddy]
fjh: just to clarify, are you supportive of the form-based approach?
15:19:22 [paddy]
James: I am in favour of both
15:20:01 [paddy]
fjh: It sounds like people are generally in favour
15:20:22 [paddy]
... apart from the question of where things should be moved, we are close to settling it
15:20:35 [paddy]
ilkka: lets address it at the F2F
15:20:42 [paddy]
Topic: Calendar
15:20:49 [paddy]
fjh: anything new to be said?
15:20:53 [paddy]
.. nothing new
15:20:57 [paddy]
Topic: Messaging
15:21:07 [paddy]
fjh: where are we with messaging?
15:21:26 [paddy]
danielcoloma: we sent a message a few hours ago
15:21:39 [paddy]
... we are preparing a new proposal now
15:21:47 [dom]
-> Plan for update of messaging API
15:21:51 [paddy]
... we will submit before F2F
15:22:09 [paddy]
fjh: thanks - anything else to discuss?
15:22:47 [paddy]
suresh; I think the best way forward is to pick up where we left off, which is what Daniel seems to be doing
15:23:03 [paddy]
... if we can pick up from the earlier thread it would be a good start
15:23:15 [paddy]
danielcoloma: yes, that's what we are doing
15:23:23 [paddy]
Topic: Administrative item
15:23:49 [paddy]
fjh: Propose no calls on 21 July and 28 July
15:23:58 [paddy]
... so next call is 4 August
15:24:08 [paddy]
.. any objection or concern?
15:24:21 [paddy]
RESOLUTION: calls on 21 July and 28 July are cancelled
15:24:34 [paddy]
fjh: is that it?
15:24:52 [paddy]
... if not, lets adjourn
15:25:05 [paddy]
... see you next week
15:25:35 [paddy]
... we have published agenda and we will do the best we can to stick to it
15:25:42 [paddy]
... but flexibility is required
15:25:56 [paddy]
suresh: appreciate putting my topics in the afternoon
15:26:06 [paddy]
... but happy to be flexible
15:26:21 [dom]
ack me
15:26:24 [paddy]
suresh: is there a bridge set up?
15:26:38 [paddy]
dom: I have confirmation that we can have a bridge
15:26:53 [Zakim]
15:26:55 [richt]
.me thanks! bye
15:26:55 [Zakim]
15:26:57 [Zakim]
15:26:58 [Zakim]
15:26:59 [Zakim]
15:27:00 [Zakim]
15:27:01 [Zakim]
15:27:01 [Zakim]
15:27:02 [paddy]
fjh: adjourned
15:27:03 [Zakim]
15:27:03 [Zakim]
15:27:04 [Zakim]
15:27:06 [Zakim]
15:27:08 [Zakim]
15:27:08 [nstratford]
nstratford has left #dap
15:27:10 [fjh]
rrsagent, generate minutes
15:27:10 [RRSAgent]
I have made the request to generate fjh
15:28:17 [fjh]
15:28:22 [fjh]
p+ foo_bar
15:28:28 [fjh]
rrsagent, generate minutes
15:28:28 [RRSAgent]
I have made the request to generate fjh
15:28:49 [jmorris]
jmorris has left #dap
15:30:57 [fjh]
s/if I stop talking at some point, it'll be because I've passed out from the heat :)//
15:31:06 [fjh]
s/ p+ erica_newland//
15:31:25 [fjh]
Present+ Erica_Newland
15:31:55 [fjh]
15:32:02 [fjh]
rrsagent, generate minutes
15:32:02 [RRSAgent]
I have made the request to generate fjh
15:38:40 [Zakim]
15:38:43 [Zakim]
15:38:44 [Zakim]
UW_DAP()10:00AM has ended
15:38:46 [Zakim]
Attendees were +1.650.335.aaaa, +44.135.388.aabb, fjh, ilkka, darobin, nstratford, AnssiK, burn, dom?, alissa, +1.972.373.aadd, James_Salsman, Suresh, +1.301.581.aaee, enewland,
15:38:49 [Zakim]
... paddy, +49.133.7.aaff, richt, maoteo, Thomas, Ingmar_Kliche
15:54:11 [Marcos]
Marcos has joined #dap
15:54:22 [Marcos]
Marcos has joined #dap
17:36:55 [Zakim]
Zakim has left #dap
18:18:27 [paddy]
paddy has joined #dap