See also: IRC log
<trackbot> Date: 23 June 2010
<dom> s/Present+ enewland/Present+ Erica_Newland/
<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 applis
a/applies/applies
scribe: 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]
scribe: 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]
<fjh> s;s/Present+ enewland/Present+ Erica_Newland/;;
<fjh> s;a/applis/applies;;
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) FAILED: s/Present+ enewland/Present+ Erica_Newland/ Succeeded: s/agenda/F2F agenda/ Succeeded: s/model/logical model/ Succeeded: s/<richt> that's/<richt_scribe> that's/ Succeeded: s/I keep getting kicked off the bridge; has the code changed?// Succeeded: s/barrier t/barrier to/ Succeeded: s/o implementation/implementation/ Succeeded: s/(sorry I'm late, local minor emergency)// Succeeded: s/that's me at 650// Succeeded: s/applis/applies/ Succeeded: s/ScribeNick richt// Found ScribeNick: richt Inferring Scribes: richt Default Present: fjh, alissa, darobin, Dom, +358.504.86aabb, ilkka, +1.202.637.aacc, paddy, wonsuk, enewland?, +1.972.373.aadd, Suresh, +44.777.541.aaee, richt, LauraA, +1.202.637.aaff, +1.650.335.aagg, jsalsman Present: +1.202.637.aacc +1.202.637.aaff +1.650.335.aagg +1.972.373.aadd +358.504.86aabb +44.777.541.aaee Alissa_Cooper Dom Dominique_Hazael-Massieux Erica_Newland Frederick_Hirsch Ilkka_Oksanen James_Salsman John_Morris LauraA Paddy_Byers Richard_Tibbett Robin_Berjon Suresh Suresh_Chitturi Wonsuk_Lee alissa darobin enewland? fjh ilkka jsalsman paddy richt wonsuk Regrets: Claes_Nilsson Maria_Oteo Dzung_Tran Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0239.html Found Date: 23 Jun 2010 Guessing minutes URL: http://www.w3.org/2010/06/23-dap-minutes.html People with action items: dom dzung fjh paddy pbyers2 roll[End of scribe.perl diagnostic output]