See also: IRC log
<trackbot> Date: 23 June 2010
<fjh> Agenda additions
<fjh> a. XACML IPR at beginning of policy section
<fjh> b. F2F planning during administrative
<fjh> c. additional API from Richard http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0254.html
<fjh> d additional API from James http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0253.html
<fjh> ScribeNick: richt
<dom> [regrets from me for the call next week]
fjh: Need to have stuff in place before the f2f.
... Need some publications. Need actions to be looked at and completed for the f2f
... Any suggestions for the F2F agenda, please send them ahead of time
... F2F agenda items before the next conference call (29th July) would be good.
<Suresh> Is there going to be a dial-in facility at F2F?
<fjh> The F2F is coming soon, after the next two calls.
<dom> Suresh, we haven't planned for it, but I can investigate if that's an option
<fjh> To make the F2F productive we should have material for review in advance, so please complete actions and make proposals before the 7 July call, preferably for next week
<Suresh> thanks Dom, it will be appreciated!
<fjh> Input on the agenda in advance would be useful, especially topics or proposals
<dom> ACTION: Dom to look into calling-in possibilities for London F2F [recorded in http://www.w3.org/2010/06/23-dap-minutes.html#action01]
<trackbot> Created ACTION-199 - Look into calling-in possibilities for London F2F [on Dominique Hazaël-Massieux - due 2010-06-30].
<fjh> Please remember to register
<fjh> DAP registration form http://www.w3.org/2002/09/wbs/43696/london2010/
<fjh> TPAC in November, 2nd F2F
<fjh> http://lists.w3.org/Archives/Member/member-device-apis/2010Jun/0001.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/att-0177/minutes-2010-06-16.html
RESOLUTION: 16th June Minutes approved
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0204.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0216.html
fjh: Laura did a few updates based on Dom's comments. FJH made a few updates also.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0235.html
fjh: Additional comments on the framework received on the list.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0238.html
fjh: Where are we at with this?
paddy: Based on how the document has been put together (from input spec sources)
... Need to go back and make sure references/terminology is clear.
fjh: For the doc, if we make the changes can we publish
paddy: yes
<dom> -1 on rushing the publication for next week
<Suresh> +1 to Dom
fjh: Would like to publish next week
dom: Still a lot of clarification required before we go to FPWD
fjh: we have never published. Would like to get something out there. Although we have a lot of feedback to get through
dom: For FPWD we must agree on the scope of the work
... It's not clear we're all clear on the scope at this stage
FWIW, the API docs took a long time to get to FPWD
dom: spec is difficult to understand. perhaps not clear enough on the scope at this stage
fjh: let's make the changes and hope we can publish soon.
<fjh> ACTION: paddy to provide clarifications to framework document as well as to address concerns raised by Suresh http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0235.html [recorded in http://www.w3.org/2010/06/23-dap-minutes.html#action02]
<trackbot> Sorry, amibiguous username (more than one match) - paddy
<trackbot> Try using a different identifier, such as family name or username (eg. pbyers, pbyers2)
<dom> ACTION: pbyers2 to provide clarifications to framework document as well as to address concerns raised by Suresh http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0235.html [recorded in http://www.w3.org/2010/06/23-dap-minutes.html#action03]
<trackbot> Created ACTION-200 - Provide clarifications to framework document as well as to address concerns raised by Suresh http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0235.html [on Paddy Byers - due 2010-06-30].
fjh: will defer this decision for another time (ACTION-200)
suresh: agrees with Dom. having a good draft is better than going through feedback
fjh: understands that rationale. will wait on ACTION-200
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0216.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0237.html
fjh: fixed validation problems and attributes have been merged to a single set of definitions.
... doc is in better shape. Dom has done some edits also.
... XACML works under the Royalty Free mode on Limited Terms
<dom> ACTION-185?
<trackbot> ACTION-185 -- Frederick Hirsch to investigate IP status for XACML -- due 2010-06-16 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/185
fjh: XACML 1.0 and 2.0 done under original policy. Latest spec is under RAND policy
<dom> re the impact of the IPR policy of XACML 2.0 on our work: http://www.w3.org/2003/12/22-pp-faq.html#outside-normative-ref says "W3C Recommendations may include normative references to standards or technologies developed outside of W3C. However, the Working Group should keep in mind the importance of royalty-free implementations of Web standards. In the event it becomes clear that the licensing status of those externally-developed technologies could become a barrier to
<dom> implementation of the technology according to the W3C Royalty-Free (RF) Licensing Requirements, W3C may choose not to publish the document or may launch a PAG."
fjh: Questions whether XACML 3.0 will be appropriate depending on the timelines of the WG
suresh: Had a look at XACML IPR. Initially looked RF. Originally RAND. Unclear if RAND commitments will carry on in to RF domain
... unclear if they have a Patent Exclusion Policy like W3C
fjh: there was a transition period. Originally RAND. Now there are new modes and there is a transition period.
... TCs that existed before the transition operated under the old mode. Obligations during transition are still under original obligations i.e. RAND (not necessarily RF)
... new stuff will be under RF terms
... Looking at XACML 3.0. Will feedback how that may relate to all this.
suresh: If we make references to XACML we need to be careful. At this point, perhaps we should make it an informative reference.
fjh: that's what we have now
... rather than discussing this complex IPR, let's focus on the technology for now.
... If you do something similar it may still be subject to patents. It's not necessarily just a XACML issue.
... we may end up doing something different but perhaps premature to get so deep in to this IPR discussion
<Suresh> we need to be consicous on the implications upfront
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0228.html
<dom> (the schema was actually mostly duplicated effort)
fjh: {goes through Dom's email}
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0232.htm
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0236.html
dom: I went through the documents last week in some detail. I now have an understanding of how it is supposed to work.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0257.html
dom: we have a lot of things to work through before it is useful for both web apps and widgets
... led me to renew the focus on a smaller scope to begin with.
<dom> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0257.html
dom: and perhaps look at interchange afterwards.
fjh: I'm not clear on why a profile wasn't done rather than a copy/paste/modify.
... Do we need the power of XACML for our purposes? A lot dealing with the trust domain (e.g. from a certificate) in XACML
... perhaps that is not necessary for our purposes
... Nokia input did something much simpler than this
<dom> (I think the point of that XACML modification is precisely because the full power of XACML wasn't needed)
fjh: what do we lose with some more simplicity? Do we need all the complexity e.g. combining algorithms, policy sets, etc. Will help when we get to testing
dom: If we are going to allow for external policy providers change the way user agents react to API calls, we need to understand the current situation for .e.g browser for API calls.
... e.g. a current browser may prompt user for a specific API call. For other interfaces there is no JS interface. e.g. cannot access a file object via JS..only available through input file element
... perhaps not clear that we can reduce this to a set of all/deny permits in a XACML profile.
... we need to first understand the current detail in user agents interacting with existing APIs
... It's not a case of browsers/widgets. Used browser as the starting point. A lot of experience in defining policies. Points on list should also apply to widgets cases.
<darobin> [using browsers as a benchmark makes a lot of sense to me]
dom: Interested in figuring out the scope of this work. Not planning on editing at this stage.
fjh: If you can help answer some of the questions you raised on the mailing list, that would be helpful.
paddy: Agree with Dom's comment. Sounds like we need to further define the model. We were going to break model in two parts:
... trust domain and permissions given to those trust domains.
... not done yet. That may take us away from XACML.
... when we did the BONDI docs we put text to further explain what 'prompt' actually meant.
... roughly it meant that there is explicit user interaction although there are other requirements. e.g. User revocation was not definable in (XACML) policy
... the best user experience is unclear. Worst thing would be to take away the best user experience in the absence of a best current practice on user experience.
... a lot of that context was lost in transition to the W3C document
fjh: Paddy, can you write down a list of the key points considered in BONDI?
... Makes sense to seperate trust domain from access control decision
... how do we proceed? Brainstorm on the mailing list?
<Zakim> fjh, you wanted to discuss next steps
suresh: important to have some level of access control. do we want to go down to granular details. Will be difficult to enforce as it is currently just a logical model
fjh: model doesn't change so much if we change the underlying technology. Need to determine trust domain and be explicit about trust domains
<Zakim> dom, you wanted to say we should start with WARP+
<fjh> ACTION: fjh to review WARP from perspective of use for DAP [recorded in http://www.w3.org/2010/06/23-dap-minutes.html#action04]
<trackbot> Created ACTION-201 - Review WARP from perspective of use for DAP [on Frederick Hirsch - due 2010-06-30].
dom: instead of focusing on interchangable policies, instead look at what WARP currently allows for Widgets. Look what is missing for more detailed policies to be built around them.
... once that is clarified, look at thow we can make these policies insterchangable
<jsalsman> flowcharts could be good. This might be an opportunity to simplify behaviors and add representation later
<jsalsman> what is WARP?
<darobin> WARP
suresh: agree with Dom.
... Looking at WARP, more than declaring intent. It talks about UA policy allow/deny.
<fjh> proposed RESOLUTION: WG agrees to focus on policy model before details
RESOLUTION: WG agrees to focus on policy model before details
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0205.html
fjh: Discussion on the list.
... Can we automate WebIDL wrt/ features and capabilities
<Zakim> dom, you wanted to leave the tooling for later, note that WebIDL option only works for our own APIs
dom: ther emay be ways for automation but we are a long way from talking about tooling at this point.
... for features and capabilities, we need to really focus on how it applies
... policy framework is not only intended to apply to our APIs, but to other APIs (e.g. Geolocation?)
<darobin> [I don't want to get into tooling right now, but I'd like to point out that it's easy to create "Web IDL Component Designators" in order to add extended attributes to parts of a Web IDL]
dom: and to other groups/APIs to which we have no link at all.
... when we reach last call I think we should approach this. Right now it may be too early.
fjh: so I understand, we shouldn't build a decision on the current APIs until the policy model is better scoped/defined.
... any simplifications we can do will help the WG. If we can simplify we should do so.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0212.html
<darobin> [e.g. { ACTION: "addExtAttr", path: "/interface:Unicorn/operation:neigh(float)", content: "[RestID=name]" }]
fjh: If we don't publish in the next couple of weeks we will publish at the F2F
dom: we will be publishing 2 or 3 specs next week.
... no pressure to publish in the next couple of weeks
<jsalsman> Was ACTION-191 approved?
darobin: perhaps we can't get througg the agenda as published in the remaining time for the call today
<jsalsman> yes
darobin: James, you wanted to bring up your action items?
<darobin> ACTION-191?
<trackbot> ACTION-191 -- James Salsman to send pre-LC editorial comments on system-info and camera/Media Capture -- due 2010-06-16 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/191
jsalsman: Action has been approved. Just wanted to check if it has been included in the spec.
darobin: any opinions on this?
jsalsman: hope this is correct as per the action item
suresh: obviously free-form is not great but when specifying the properties are we specifying the formats?
... MIME type needs to be a certain format
jslasman: included a format for speex (sp?)
jsalsman: unencumbered format
<jsalsman> audio/x-speex
<scribe> ACTION: Roll in changes from the outcome of ACTION-191 [recorded in http://www.w3.org/2010/06/23-dap-minutes.html#action05]
<trackbot> Sorry, couldn't find user - Roll
<darobin> ACTION: Dzung to include changes from ACTION-191 http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0253.html [recorded in http://www.w3.org/2010/06/23-dap-minutes.html#action06]
<trackbot> Created ACTION-202 - Include changes from ACTION-191 http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0253.html [on Dzung Tran - due 2010-06-30].
darobin: do we need to seperate each media type per entry?
suresh: yes, otherwise we need to parse the whole string
<darobin> attribute DOMString[] compFormats;
<darobin> "audio/x-speex;quality=7;bitrate=16000, audio/ogg"
<darobin> ["audio/x-speex;quality=7;bitrate=16000", "audio/ogg"]
darobin: issue in the provided code snippet should be amended.
... Sticking to strings is common enough at this point
... Let's stick to strings. If it's a problem we can revisit this
illka: jsalman's last comment about Media Capture API. Proposal for impl to choose the audio format to use?
suresh: aid to check which formats are supported by the system.
darobin: example gives 'audio/x-wav' as an example...proposal is to change to another format?
... idea is not to refer too much to proprietary formats. even if impl choose to support them.
<jsalsman> yes, use good examples, especially when union types can be replaced with open standards
<darobin> sysinfo.authfor("Power", "Light", "Network")
<fjh> is this an optimization , box car of requests
<darobin> sysinfo.get({ Network: function (res, err) {...}, Power: function (res, err) {....});
the second is possibly more interesting: variadic sysinfo.get attributes.
<richt_scribe> that's my understanding, darobin. one prompt is too little, prompt per sysinfo property is too much.
let's take it back to the list
<fjh> jmorris suggests could have groupings for environmental vs device capabilities etc
<fjh> sysinfo not to be published right now, still being discussed
<dom> +1 to publish snapshot of contacts
<fjh> suresh asks how to tell where data comes from
<fjh> richard talks about mozilla implementation, provides dashboard to identify sources
<fjh> richard notes, not exposed to api
<darobin> PROPOSED RESOLUTION: Publish WD of Contacts with note indicating that some parts, including schema, are still in flux
disagree with the resolution. An intermediate draft is in flux by default
<darobin> RESOLUTION: Publish WD of Contacts with note indicating that some parts, including schema, are still in flux
<dom> [I'll note that there won't be staff contacts to help through the publication process, hopes that's ok]