See also: IRC log
<trackbot> Date: 15 September 2010
<dom> ScribeNick: Bryan
<scribe> scribenick: bryan
fjh: will plan to have a bridge at tpac
<dom> ACTION: Dom to request bridge reservation for TPAC [recorded in http://www.w3.org/2010/09/15-dap-minutes.html#action01]
<trackbot> Created ACTION-269 - Request bridge reservation for TPAC [on Dominique Hazaël-Massieux - due 2010-09-22].
<fjh> WG questionnaire (for all), http://www.w3.org/2002/09/wbs/43696/tpac2010dap/
<fjh> TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/
<fjh> DOM 3 Last Call
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0060.html
<dom> (note that 22 people say they will attend to TPAC, but only 16 have effectively registered http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/registrants#DeviceAP )
fjh: minutes approval
<fjh> Approve 1 September minutes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/att-0007/minutes-2010-09-01.html
fjh: 1st sept call
<fjh> proposed RESOLUTION: Minutes from 1 Sept 2010 approved
RESOLUTION: Minutes from 1 Sept 2010 approved
<fjh> Published Tuesday 7 Sept, see http://www.w3.org/News/2010#entry-8886
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0043.html
<dom> Device APIs ACcess Control Use cases and Requirements (TR in Sep 7)
fjh: published 7 sept , updated in editors draft with use case stories, by dom
<dom> Access Control Use Cases editors draft
fjh: open to publishing as soon as new changes are agreed, e.g. with features
<dom> (I think publishing it along with the features draft sounds like a good idea)
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0016.html
fjh: updated the draft, dom suggested to remove features
... didn't go into features as trouble finding use cases for it in BONDI
<fjh> bryan: notes that features were intended to be used for API versioning
<fjh> bryan: capabilities probably enough if at same level of granularity
<dom> (we already resolved not to worry about APIs versioning)
<fjh> bryan: ok with not using features in DAP
suresh: thats OK in BONDI context given the explanation by bryan
<richt> no API versioning was the very first decision this working group made :)
<dom> (I propose the stop talking about "features" or "capabilities", but only talking about "permissions"
suresh: in the context of widgets we need though some representation of the APIs as feature tags
fjh: isn't that the same as the API
<darobin> [+1 to dom, though the DOM has "feature strings"]
suresh: may not need the same level as BONDI provided, but in what the feature config requires we need to define features
q
fjh: we don't need features ala bondi to do permissons but do in config
<Suresh> At the minimum we need to specify the "features" that are required for using our APIs in the context of widgets
<darobin> what Widgets have is "feature": http://www.w3.org/TR/widgets/#feature0
dom: my proposal goes a bit further - rather than capabilities and features, focus instead on permissions
<Suresh> yes so we need to standardize the set of "feature names" which is an IRI
james: re granularity, the issue is connotation , i.e. what you want your devices to be able to do. re features and capabilities its more about how to write the document - if we use only features, where are the capabilities supposed to go
fjh: permissions would be more obvious - the feature/capabilties model in bondi adds complexity we dont need
james: where would capabilities go if taken out
fjh: essentially the same thing, we can discuss granularity, but attempts to access are permitted or not. we need the concept of permissions fundamentally, and also a way to define those things that are permitted or not
dom: want to focus only on permissions, not a distinction between features and capabilities
fjh: maybe misunderstood that the intent was to remove capabilities
... meant that we need trust domains, permissions, and naming to bind to feature elements in widget spec
james: supports the proposal
<Suresh> Widgets spec requires that the feature names is a IRI
fjh: re using feature strings vs abstracted device capabilities, robin had a proposal to define capabilities and prefix as needed with a base API reference
bryan: would like to have the more generic string to enable a single policy for different APIs using the same device capabilities
fjh: versioning would still need to be considered
<maoteo> I was not
fjh: summary, we dont need features and will call the things permissions, id the method that applies to a permission with a string
... propose dom do work on that
RESOLUTION: we will not include the concept of features in the DAP V1 work
fjh: clarifying, features here means specifically as used in the bondi sense
... we are collapsing features and capabilities into one thing and calling them permissions
bryan: bondi included the distinction to enable control of permission for device capabilities shared by different APIs
<dom> [I think the high level resolution is that we're using a single layer of permissions, more than on the specific word]
james: recommend using the term with a positive rather than permission
fjh: thinks permissions has a positive connotation connotation
<Suresh> access pemissions
fjh: permissions is used elsewhere and we should use the same term
... permissions is a straightforward concept
dom: at this time, what we are agreeing is to use a single layer of permissions - the name for that we can decide later on - as a start I will refer to permissions but we can settle that later
james withdraw the objection
james: withdraws the objection
<dom> PROPOSED RESOLUTION: we will use a single layer model for access permissions
RESOLUTION: we will use a single layer model for access permissions
james: can we defer or resolve to replace the work permissions with a more positive connotation
<dom> ACTION-263 due next week
<trackbot> ACTION-263 Take a stab at DAP features doc due date now next week
fjh: let see what dom comes up with and we will discuss it on the list
<richt_> this conversation is becoming a bit circular right? perhaps dom can propose something and we can rediscuss on the call next week if necessary.
james: preferred to defer the resolution
<richt_> take it to the mailing list?
dom: the resolution is only about the modeling and not the name/terms of the concepts in it
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0034.html
<fjh> not much to do with this
<fjh> right now
robin: dont recommend discussing this now
<fjh> keep it on the list
fjh: the proponents are not on the call
<fjh> action-210?
<trackbot> ACTION-210 -- Alissa Cooper to summarize and add issues to ruleset doc -- due 2010-07-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/210
<darobin> http://lists.w3.org/Archives/Public/public-contacts-coord/
darobin: mailing list created for contacts coordination
... progressing toward common understanding
... a new draft was announced
<darobin> http://www.w3.org/mid/9B2983F7-D3C0-4EE3-B9AF-BDCE6B53271B@robineko.com
richt: the draft looks into formats, proposed extensions, look at the cvs diff log for the changes
darobin: made a post about pending op
... any sync in wrt needs to define the way it works in terms of HTML event loops and task queues
... basically a mental model to explain the way things happen
... e.g. if a request is cancelled before completion the two actions related to this need to put on a task queue so they are handled in the right order
richt: so the need is to understand the process model etc
... the HTML device spec has pending op specified, is that the best place to put this
darobin: different APIs will have different needs re what to do when cancel is called - so we need specific text for each spec
richt: will see what can be done for contacts re this
darobin: we can use the text for the other APIs as template
... anne form opera will be able to help
<dom> [I've added the need to look at asyncronous calls in terms of the HTML5 event loop in http://www.w3.org/2009/dap/wiki/ApiCheckList]
suresh: was on the contacts coordination call - thought we should discuss this and decide what is next
... we got info on what is being done but there was no decision on how to converge - do we want to discuss this now or give more time for this
tlr: there is an ongoing discussion between ietf and poco -that needs time
... the mapping between vcard3 and cab needs to be considered as this might impact vcard4
... the OMA has the action item to review the info available
suresh: expecting Christina to respond - she has the action
tlr: that response should clarify the story
suresh: looking back at the API, don't know what happened to the note re contacts schema for further study
richt: made some changes to reflect the call discussion, so removed the note re poco schema. we are not now saying that we are compatible with poco etc
<tlr> also my fault; I probably referred to our API as PoCo-based on multiple occasions
richt: but focusing on extensions, how to include them
... still up in the air, not a specific mapping to vcard or poco
suresh: the formats refer to poco schema still - seems to be dependent
richt: those attributes are vcard attributes (all are)
suresh: need to reflect the open issue re formats
richt: will put a statement back in
<dom> Dom's comments on updated contacts draft
suresh: some comments were provided on the list re attributes related to social networking - we should avoid dependency on these e.g. relationships
richt: these are vcard4 attributes
<dom> [relationship can be used outside of a social network, I would think]
suresh: to be useful, we need a service tied to the contacts format
<dom> (this is all about ISSUE-98)
<dom> ISSUE-98?
<trackbot> ISSUE-98 -- On what data model should the contacts API be based? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/98
richt: don't agree we have social attributes specifically - this is still ongoing and we need to continue the coordination work on the coord list
... we need to be active in that discussion to influence it
... do detail the specific issues on the list
suresh: a lot depends upon convergence in the coord group - we need a plan b in case that does not happen
richt: the timelines for poco and vcard are their own - we could go for example with a vcard subset and let the market decide what is useful
... looking at including an html integration part to the spec - may delay until we address current feedback
... this will include integrating with the device element of html
darobin: concerned about the dependency in the spec - maybe better outside
<dom> (separate spec sounds better to me)
richt: how about a non-normative section
darobin: action on John for privacy, not here so that will wait
james: on device element with audio, there are no open echo cancellation algorithms
darobin: its unclear whether the device element is in scope for this group
... the element is a couple of months away from being published - but a good point for the a/v part of the device element
<darobin> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0010.html
<richt_> HTML Device is already being implemented: https://labs.ericsson.com/blog/beyond-html5-conversational-voice-and-video-implemented-webkit-gtk ;)
darobin: we have an open cfc for capture - believe most comments have been resolved
<dom> ilkka: not all, but most of them
in the lab
<darobin> [group goes textual due to ilkka's noise]
<darobin> ilkka, are the missing ones important?
<dom> [I'm hoping the remaining issues be documented in the draft itself]
darobin: we are trying to check if all the changes have been included - need to know if we can move ahead and publish - if the remaining issues are minor, propose to move forward with a pwd
<darobin> ilkka, can you put notes for the issues that weren't fixed?
darobin: need to put notes for the issues that weren't fixed?
illka: ok
darobin: anyone objecting to publishing with notes?
james: there were some concerns about objections re audio
<richt_> I believe that the audio format was discussed on the WHATWG without resolution (what to choose is the problem).
james: does anyone object to a proposed audio format?
dom: we discussed this and had resolved to not recommend a default at this time
<richt_> start of discussion on WHATWG: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028337.html
<dom> PROPOSED RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document
james: have w3c considered what should be default formats?
darobin: yes, unsure where though
<dom> (+1 on audio codec discussion belonging to HTML WG)
tlr: the location for that should be in HTML5 in the html wg
james: did that two weeks ago and there was no objection
... at least one member said it would be difficult to obtain concensus
dom: suggest to move this to html wg where there is a defined process for consensus
darobin: we don't want different spec in w3c to recommend different options
<darobin> RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document
RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document
<darobin> ACTION: Ilkka to add notes to the MCAPI draft and ping Robin when ready [recorded in http://www.w3.org/2010/09/15-dap-minutes.html#action02]
<trackbot> Created ACTION-270 - Add notes to the MCAPI draft and ping Robin when ready [on Ilkka Oksanen - due 2010-09-22].
<darobin> http://lists.w3.org/Archives/Public/public-calendar-coord/
darobin: new coordination call and mailing list - suggest to join if you have interest
... on the call, we discussed status and call connects group described their work including caldav restful version and xcal, json version etc - we agreed to keep in touch on the issues
<Zakim> dom, you wanted to ask about schedule/roadmap for calendar API FPWD
dom: we had talked about publishing a pwd for calendar - wonder about the status
<dom> (also, what about TimezonedDate publication?)
richt: long overdue, stuck re a couple of issues. A good way forward e.g. xcalendar and mapping to js - will get the draft ready in the next two weeks to month
darobin: good to get it out before tpac
richt: can do
<darobin> http://dev.w3.org/2009/dap/calendar/TimezonedDate.html
dom: re creating a new timezone date interface, drafting is in progress and can this be included in the near term?
richt: a rough draft is in progress, not sure what approach to use
darobin: a service requires a connection and service discovery
james: it would be useful to discuss the underlying julian date and what info is available from it
darobin: when we publish calendar we should try to include this
james: include the ISO spec with a description of the number of bits it takes
richt: the ISO format is the cause of the problem
darobin: not much movement since the last version - we need to review the draft to move to last call soon
<Zakim> dom, you wanted to ask about pendingop
<richt_> Using an ISO date in a recurring rule there is no way to represent a timezone rule (or timezone id). Instead it uses timezone offset at a fixed point in time. That does not represent the time for any further recurring date of the event.
dom: re need to integrate with HTML5 event loops - this is needed here also
<richt_> ...if the timezone offset changes to -4 then the ISO representation (of e.g. -5)will be coordinating the call at the wrong time.
darobin: yes, all async interfaces need that so it needs to be included before last call
<richt_> ...hence the TimezonedDate object
darobin: would rather solve it once for all specs
<darobin> ACTION: Robin to figure out the event loop stuff for sysinfo [recorded in http://www.w3.org/2010/09/15-dap-minutes.html#action03]
<trackbot> Created ACTION-271 - Figure out the event loop stuff for sysinfo [on Robin Berjon - due 2010-09-22].
<dom> ISSUE: Sysinfo asynchronous calls needs to be expressed in terms of events loop
<trackbot> Created ISSUE-102 - Sysinfo asynchronous calls needs to be expressed in terms of events loop ; please complete additional details at http://www.w3.org/2009/dap/track/issues/102/edit .
james: should the capture API be closer to last call - due to issues with network attributes
... are there any attributes that are off limits - any restrictions on what the network attributes can include
... for example packet sniffing
darobin: what is the relationship with sysinfo
james: we need a wide variety of quality of service metrics
darobin: we resolved that, and unless there is new info we have agreed on the current set of attributes
<dom> james, do you have a pointer to a specific proposal for additions?
james: still think there is a need to a wide array of quality of service metrics from the network interface
<dom> [SysInfo is certainly not targeted for use by network engineers]