See also: IRC log
<trackbot> Date: 16 July 2010
<dom> ScribeNick: nstratford
<scribe> scribeNick: nstratford
<dom> nstratford, http://www.w3.org/2005/Incubator/audio/
<Dong-Young> Presence+ Dong-Young_Lee
<fjh> reminder - agenda - discuss F2F after TPAC
<dom> HTML Form Based Media Capturing Editors draft
darobin: New re-arrangement of the API - we need to agree on the plan, when to have a draft and how soon to release. Good short-term interest - should push something out quickly and get feedback/implementations.
ilkka: Two separate specification - 1. Form based (better name ideas?) - simple addition to html 5 - main discussion point is that the spec is now different, controlled by dap, or more integrated to html5
darobin: easier to get the spec out rather than wait for html 5 consensus
<dom> +1 to darobin
darobin: we can extend it, just not clash with it and coordinate not to cause problems
ilkka: addition we are proposing are additions to the accept parameter
darobin: ok not to validate as html 5
<dom> -> http://dev.w3.org/html5/spec/number-state.html#attr-input-accept Accept parameter in HTML5 <input type="file"/>
richt: do the source parameter and the media file api need to be bound together here? is it necessary to have both - can see the source parameter without this api
darobin: feedback that MediaFile is being implemented
ilkka: is a small extension to File
richt: change type to be mime-type - need to be consistent
darobin: FormatData - eg. file.format.codecs - should it be a subfield or directly on MediaFile? Maybe inherit from FormatData and File?
<richt> the parameters in FormatData also need to be made 'readonly'.
<richt> further to the type/mime-type discussion I'd suggest that type can be removed from the 'MediaFile' interface as it is already provided in the 'File' interface
<dom> The Blob interface already has a type attribute, cf http://dev.w3.org/2006/webapi/FileAPI/#dfn-type
tlr: since using mime-types - respect for extension points - do we need to mirror them
... mime parameters are a list of tag value pairs
... check formats actually use parameters - eg. video
dom: remove the type attibute
darobin: sequence or array for MediaList?
ilkka: same as for FileList
wonsuk: most of the information is covered by Media Annotations api - need to be consistent
<dom> API for Media Resource 1.0
ilkka: we should avoid overlap, but downside is creating dependencies (but that spec is in last call)
wonsuk: Location information in the capture api?
darobin: Should remove gelocation information from images
... should have a note that we are looking into alignment with media annotations
dom: Should remove the trusted environments example from section 5
darobin: Do we say enough in section 5 to properly integrate with html5?
... Impacts of exposing capture attribute in the dom - parameter is easier to implement
tlr: Do we need to specify what happens if you have an input element is changed in the dom?
darobin: agree that prefer a parameter over an attribute?
<dom> (I think the FileAPI, HTML5, RFC4281 should be normative refs; WebIDL should also be added as normative ref)
<dom> ACTION: Dom to update media capture form for publication next week [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action01]
<trackbot> Created ACTION-233 - Update media capture form for publication next week [on Dominique Hazaël-Massieux - due 2010-07-23].
<richt> Interesting angle to this stuff: http://blog.nihilogic.dk/2008/05/reading-exif-data-with-javascript.html. Any potential that this covers the FormatData interface parameters? (no EXIF for video yet though :-( )
<dom> PROPOSED RESOLUTION: we publish capture-forms as an update to TR/capture-api pending the changes discussed today are implemented
<dom> richt, I think leaving EXIF to the javasript layer is probably best for now
bryan: intent is to split into two peices - leaves all the capture part to the implementation (clarification)
Claes: shouldn't this just be an update to html5?
<richt> dom, I agree that the Media Capture spec goes a lot further than EXIF info, which is currently limited to a small number of formats.
bsulliva: between dap and webapps we have the charter to connect html5 web runtime to the world - so it's better fitting here
claes: Many other things can build on top of the input element
<tlr> ACTION: dom to seek review of capture-forms from HTML WG, Webapps once FPWD is published [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action02]
<trackbot> Created ACTION-234 - Seek review of capture-forms from HTML WG, Webapps once FPWD is published [on Dominique Hazaël-Massieux - due 2010-07-23].
bsulliva: Can we be more specific in the reference to html5 in the specification? where does it talk about creating media files?
... as part of the File Upload state feature
... What about the name of the specification? - the short name will change (html media capture)
<dom> http://dev.w3.org/2009/dap/camera/Overview-API.html
RESOLUTION: we publish html-media-capture as an update to TR/capture-api pending the changes discussed today are implemented
<darobin> RESOLUTION: we publish a WD of Media Capture API as soon as Ingmar has polished it
<darobin> ACTION: Ingmar to polish Media Capture [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action03]
<trackbot> Created ACTION-235 - Polish Media Capture [on Ingmar Kliche - due 2010-07-23].
darobin: Security section has been re-writen, changed the privacy section - new editors draft before decide on last cal
<fjh> 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
<fjh> http://www.w3.org/2009/dap/track/actions/191 -- and ACTION-202 have
<fjh> james email - http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0077.html
<fjh> s/http://www.w3.org/2009/dap/track/actions/191 -- and ACTION-202 have//
tlr: Calendar - internatonalisation, timezone. Contacts (how fits with IETF vcard?)
darobin: Units from sysinfo - which bandwidth metric/luminance/decibel
<fjh> s;http://www.w3.org/2009/dap/track/actions/191 -- and ACTION-202 have;;
tlr: Sysinfo: network, contacts, calendar - need more on messaging before review
richt: Portable contacts people as well
bsulliva: difficulty because we have our own schema - OMA are trying to do things in a coordinated way - how close can CAB(?) be to what they need
<richt> RE: OMA CAB/PoCo/vCard relationship to Contacts API -> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0273.html
darobin: make sure CAB are aware of our work
Dong-Young: CAB is defining it's own format, concerns related to deployment because of own format - making effort to make compatible with vCard - should be in this group as well
richt: A lot of people are behind portable contacts that go beyond vCard - but portable contacts inherits from vCard - scope of the contacts api is much larger
<richt> List of providers of Portable Contacts information: http://wiki.portablecontacts.net/Software-and-Services-using-Portable-Contacts
tlr: Three way coordination between IETF vCard, CAB and us is required
<tlr> ACTION: thomas to report back on IETF relationships after Maastricht meeting [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action04]
<trackbot> Created ACTION-236 - Report back on IETF relationships after Maastricht meeting [on Thomas Roessler - due 2010-07-23].
<tlr> ACTION-236: Calendar formats and protocols (calDAV, recurrence model, solilunar calendar and internationalization)
<trackbot> ACTION-236 Report back on IETF relationships after Maastricht meeting notes added
<tlr> ACTION-236: Contacts API (PoCo, Vcard, relationship to OMA CAB work)
<trackbot> ACTION-236 Report back on IETF relationships after Maastricht meeting notes added
<tlr> ACTION-236: Sysinfo (bandwidth metrics)
<trackbot> ACTION-236 Report back on IETF relationships after Maastricht meeting notes added
<darobin> ACTION: Robin to talk to TC-39 about TimezonedDate once it's ready [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action05]
<trackbot> Created ACTION-237 - Talk to TC-39 about TimezonedDate once it's ready [on Robin Berjon - due 2010-07-23].
<tlr> ACTION-236 due 2010-07-31
<trackbot> ACTION-236 Report back on IETF relationships after Maastricht meeting due date now 2010-07-31
<tlr> action-236?
<trackbot> ACTION-236 -- Thomas Roessler to report back on IETF relationships after Maastricht meeting -- due 2010-07-31 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/236
bsulliva: Working to align with OMA work - SysInfo attributes and CPM(?) for messaging APIs - CPM is a broad framework for messaging of all types
<darobin> ACTION: bsulliva to inform OMA groups of our status [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action06]
<trackbot> Created ACTION-238 - Inform OMA groups of our status [on Bryan Sullivan - due 2010-07-23].
<dom> ACTION: Dom to prepare survey on finding a date for a F2F meeting in Seoul, in Feb/Mar 2011 [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action07]
<trackbot> Created ACTION-239 - Prepare survey on finding a date for a F2F meeting in Seoul, in Feb/Mar 2011 [on Dominique Hazaël-Massieux - due 2010-07-23].
<darobin> ACTION: Kangchan to look into hosting at ETRI in late Feb/early Mar 2011 [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action08]
<trackbot> Created ACTION-240 - Look into hosting at ETRI in late Feb/early Mar 2011 [on Kangchan Lee - due 2010-07-23].
RESOLUTION: first meeting of 2011 in Korea
and
RESOLUTION: The group thanks David and WAC for hosting
<LauraA> fjh: powerbox and privacy
<LauraA> ... might be possible to use rulesets in powerbox
<fjh> seems logical to integrate user privacy information with introduction/discovery mechanism
<LauraA> bsulliva: a protocol in which you have a provider interact with an authoriser on behalf of the user is what powerbox is about
<fjh> not to say inappropriate for APIs as discussed earlier, though we've also discussed issues for that
<LauraA> alissa: somewhere there has to be a UI element that allows the user to stablish what privacy aplies with which data
<LauraA> alissa: user needs to get involved at one point. thus, there needs to be a UI element
<LauraA> Claes: powebox allows the user to install the provider you trust
<LauraA> jmorris: for control policies powerbox might be a good thing, we will look at it to get a better understanding
<LauraA> Dong-Young: for attaching privacy rules, this can be easly implemented by a header in HTTP,
<LauraA> fhj: not just a technical problem, need to consider the whole ecosystem
<LauraA> dom: we identified the set of issues. we should at least rough ideas how we are going to deal with these issues
<LauraA> fjh: we just listed the issues against it
<LauraA> dom: we have a plan. we have these issues, we need to decide if we address them or ignore them.
<LauraA> dom: alissa will document the issues
<LauraA> jmorris: we'll go through the list and provide responses to these items
<LauraA> ... some items are resolvable. We might want to identify communities that would implement this.
<LauraA> ... if we are not able to find this community, that we might not want to spend time on this
<LauraA> dom: all the privacy investment we are doing is not in rulesets
<fjh> jmorris notes powerbox might be able to enable access decisions including privacy as inputs, but might not help transmitting rules aspect
<LauraA> dom: in terms of experimental implementations, there were two options presented
<LauraA> alissa: having a sort of RI will be the only way to make some progress
<LauraA> dom: i might be able to help
<Claes> +1 for RI on rule sets
<LauraA> darobin: me too. I think it's better if it was not hosted by W3C
<fjh> discussion of possible prototype
<LauraA> alisaa: we would need 2 parts: browser extension and a site that makes use of them.
<LauraA> darobin: it could be simpler, just having a site, where a user configures the privacy settings
<LauraA> bsulliva: a specification of some sort of data format is required, like rule sets. I think we should write a recommendation to support rule sets.
<LauraA> jmorris:
<LauraA> ...
<LauraA> bsulliva: to me rule set is just a definition of a preference or an intent
<richt> jmorris, the ability to block contextual advertising in a user-generated privacy policy is going to jar with a lot of web business models. i.e. you get the service for free in exchange for contextual advertising.
<LauraA> fjh: this is not a technical concern, is a political concern
<richt> ...'contextual advertising' is often the price you pay for free services. This also applies to the cost/benefit ratio of other compromises of user privacy.
<LauraA> bsulliva: why do we need to define a default policy?
<LauraA> jmorris: the value is that it works with many websites
<fjh> want default privacy policy that works widely on the web
<fjh> want policy that can be understood and is meaningful
<LauraA> dom: what Bryan was pointing to is that it makes sense to have possible values of the rule sets defined
<fjh> buy-in from various stakeholders is important
<LauraA> jmorris: i agree with that. the rule set document should get buy in from the privacy community.
<LauraA> fjh: should we have an action to look at powerbox?
<LauraA> jmorris: fine, we are happy to look at powerbox.
<LauraA> bsulliva: result from this discussion: we don't feel is good to define a framework in which the policy is set by the user?
<LauraA> fjh: we didn't say that..
<LauraA> bsulliva: we have a proposal for having 3 buckets because we think is simpler. Are we going to allow users to say "no, i don't want to allow..." ?
<LauraA> alissa: there are the 3 choices and they are what they are
<LauraA> tlr: I don't really know what it means "to break the web", it's better to frame this issue and focus on next steps, etc
<LauraA> fjh: the assumption is that by doing some simplification it might get adopted more easily
<fjh> bryan asks about maintenance and change related to rulesets over time
<LauraA> alissa: there are arguments on both sides. Some think it's too complex, some others think it's not complex enough
<LauraA> bsulliva: one last point, tying to the work being done elsewhere. When we get to the point of defining a policy framework, if we define set policies with specific settings, it's going to be difficult to comply to all different markets.
<fjh> ISSUE: different regulatory environments and relationship to privacy and rulesets
<trackbot> Created ISSUE-95 - Different regulatory environments and relationship to privacy and rulesets ; please complete additional details at http://www.w3.org/2009/dap/track/issues/95/edit .
<LauraA> tlr: regarding different regulatory environments, as John set about the privacy community, this is also something that will come up for privacy.
<Zakim> fjh, you wanted to ask about actions and next steps
<fjh> API sections, Features
<paddy> ok
<fjh> http://dev.w3.org/2009/dap/features/
<dom> Privacy & Security Consideration
<LauraA> dom: I added privacy and security sub-sections in the API checklist
<fjh> the checklist now includes questions that should be answered by each API in privacy and security considerations section
<LauraA> ... I am going to send a link to the mailing list
<LauraA> ... this should be part of our regular check list
<LauraA> fjh: we are all free to add to these questions
<LauraA> fjh: Features --> i created a draft including the feature definitions from BONDI
<LauraA> ... I reference the feature element in P&C
<LauraA> ... I am not sure we want to define a set of capabilities
<richt> fjh's draft: http://dev.w3.org/2009/dap/features/
<LauraA> paddy: how does this document relate to existing documents?
<LauraA> ... it would make sense to have just one set of definitions we all agree on
<LauraA> fjh: it might be good to focus on the features draft and not worry about repeating content in different docs
<LauraA> paddy: the scope of this document is --> defining what a feature is, define a list of features and those definitions are going to be linked to a different API draft
<LauraA> dom: we don't need to restrict ourselves to the set of APIs this WG is defining, like Geolocation
<LauraA> fjh: i agree. I didn't include references to the API docs yet, but these should be there, of course.
<richt> Rather than using http://dev.w3.org/2009/dap/features/* for features maybe we should use http://w3.org/device/f/* or something similar? It's probably not a big deal right now....bikesheding aside :-/
<LauraA> fjh: not sure what else we could do with policy right now
<LauraA> dom: It was interesting that Ian stated that a policy might be something they consider for the future
<LauraA> paddy: There is interest around the table to define the policy framework well but support is needed from all those interested in moving the policy work forward. The discussion with Ian was quite encouraging.
<fjh> ACTION: fjh to review and update policy requirements [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action09]
<trackbot> Created ACTION-241 - Review and update policy requirements [on Frederick Hirsch - due 2010-07-23].
<fjh> ACTION: paddy to review and update policy requirements [recorded in http://www.w3.org/2010/07/16-dap-minutes.html#action10]
<trackbot> Created ACTION-242 - Review and update policy requirements [on Paddy Byers - due 2010-07-23].
<LauraA> fjh: 2 things to do
<LauraA> ... feature stuff and requirements&policy
<fjh> update requirements to clarify focus and objectives
<dom> (I think it's critical to define use cases for the in-entreprise usage of the policy framewr)
<fjh> paddy notes trust domains, rule separation topic to discuss later; whether to use XACML or something similar or not etc
<LauraA> dom: in the requirements document, we could include use cases of policy in the enteprise context
<fjh> possible use case - configuration for child protection/use by operator etc
<LauraA> paddy: do any operators around the room have any views of the enterprise use cases?
<fjh> enterprise use case might not be driven by operator, but by enterprise itself
<LauraA> dom: we are talking about the policy reqs document to make it more interesting for other parties
<LauraA> bsulliva: we could help to give an example of these use cases
<soonho> (Especially, in web application for B2B, it's so important to consider enterprise use cases)
<LauraA> fjh: are we done with policy?
<LauraA> fjh: we are done with policy now.
<bsulliva> Here is the link to the message I sent with comment on the Policy Rulesets proposal: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0099.html
<LauraA> fjh: should we go through the issues?
<fjh> http://www.w3.org/2009/dap/track/issues/open
<LauraA> fjh: I'll bring up the issues list
<fjh> ISSUE-26?
<trackbot> ISSUE-26 -- How to refer to API -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/26
<fjh> ISSUE-29?
<trackbot> ISSUE-29 -- Should DAP APIs support "API Keys" -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/29
<fjh> social network requires application specific key
<fjh> sounds like extensibility point needed. Goal to enable authentication to service by javascript
<fjh> ISSUE-29 and ISSUE-30 are the same or related
<fjh> ISSUE-34?
<trackbot> ISSUE-34 -- Protecting data versus protecting apis -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/34
<fjh> see note from Richard
<fjh> ISSUE-56 closed
<trackbot> ISSUE-56 Add custom copyright notice closed
<fjh> ISSUE-54?
<trackbot> ISSUE-54 -- What messaging use cases cannot be fulfilled by existing URI schemes (mailto, sms, mms)? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/54
<fjh> issue-54 closed
<trackbot> ISSUE-54 What messaging use cases cannot be fulfilled by existing URI schemes (mailto, sms, mms)? closed
<fjh> issue-78?
<trackbot> ISSUE-78 -- Capture has a minimisation problem with EXIF data (e.g. it could be Geotagged) -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/78
<fjh> add warning to capture API regarding EXIF data
<fjh> next teleconference is 4 August
<fjh> adjourn