See also: IRC log
<trackbot> Date: 26 May 2010
<arve> I have conflicting appointments
<darobin> stupid bot
<darobin> okay let's wait a little
<darobin> danielcoloma, can you scribe? you're at the top of the list
sure
<darobin> thanks!
<darobin> Scribe: Daniel
<darobin> ScribeNick: danielcoloma
<dom> Registration for DAP F2F in London, July 2010
dom: registration for London meeting is open
<dom> Current registrants for F2F
darobin: privacy workshop is scheduled for the same week as DAP F2F
<darobin> Minutes of 19 May 2010 call
RESOLUTION: minutes approved
<dom> ACTION-152?
<trackbot> ACTION-152 -- Laura Arribas to edit policy framework, reviewing BONDI material and editorial update -- due 2010-05-05 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/152
<dom> Laura's report on progress on policy framework wrt trust domains
LauraA: Changes submitted to CVS
this morning
... e-mail summarizes key changes done in the commit
<darobin> the Policy document
LauraA: Trust domain control layer added, new dataflow
<dom> Dataflow diagram
LauraA: One of the objectives was
making it simpler, not sure if it is achieved yet
... need help to split the document in different specs
darobin: volunteers for contributing more to the work?
<wojciech> yes it's me
darobin: which kind of problems do you have when splitting the doc?
lauraA: agreed to have 3 docs (policy framework, profile and example documents) but not sure how to do the split
darobin: create 3 copies of the
doc, add them to the CVS and remove the part that is not needed
for every of them
... Do you think the documents resulting of the split are
small/indepent enough to be implemented in a granular
manner?
LauraA: Yes, I think so
<AnssiK> editorial comment re policy framework doc: do not scale images, instead display them in their native size for better readability (see e.g. section 2.3)
darobin: status from a publication point view?
LauraA: The policy framework is the more mature one
darobin: could we have a FPWD Cfc next week?
LauraA: Yes, it is doable
darobin: discussion on the
sysinfo attributes on the mailing list
... target is reach an agreement today
... MAC address and SSID, suggestion is remove both
<dom> Analysis of SysInfo Attributes
<Dzung_Tran> +1
<maxf1> +1
dom: widget and open web are different use cases
darobin: we should think about the use case for exposing these attributes
<tlr> I like Robin's proposal.
<dom> (this could be something defined in the policy framework, that said)
darobin: accessing some properties may return a denied permission error depending on whether an installed applciation or a web page is accessing them
<Dzung_Tran> At one point we talk about a different use cases document, Is there one?
darobin: the other alternative is having an extended spec for these additional properties
tlr: supports the idea of having these properties in another spec
<alissa> +1 to having scary properties separate
dom: who is doing that analysis?
<Dzung_Tran> that analysis would be difficult, I would just remove obvious scary properties for release 1.0, revisit in release 2.0
<dom> (an editors note in the doc maybe?)
dom: We could include a note saying that these properties are not part of the spec because of privacy issues
<darobin> PROPOSED RESOLUTION: macAddress and SSID removed; Make a note that these have been removed but that the group is considering making them available in a more advanced document
<darobin> + because of privacy concerns
<darobin> + seeking comments, planning to revisit in future version => in SotDF
<darobin> RESOLUTION: macAddress and SSID removed; Make a note in SotD that these have been removed but that the group is seeking comments and considering making them available in a future version
<darobin> ACTION: maxf to implement the maxAddress/SSID resolution [recorded in http://www.w3.org/2010/05/26-dap-minutes.html#action01]
<trackbot> Created ACTION-175 - Implement the maxAddress/SSID resolution [on Max Froumentin - due 2010-06-02].
darobin: suggestion to remove IP address
<tlr> ack
<darobin> PROPOSED RESOLUTION: remove ipAddress as well, put in same list as macAddress and SSID
<darobin> RESOLUTION: remove ipAddress as well, put in same list as macAddress and SSID
darobin: APN, operatorName,
roaming, mcc and mnc have been also suggested for being
removed
... suggest to separate roaming from the other four, as there
are strong use cases for it at least
<tlr> The "data connection is expensive" flag, right.
alissa: some of these attributes may be redundant
maxf: Bryan was the main supporter for including these attributes, we may need to check with him
darobin: suggestion is removing them unless we have strong use cases for them
tlr: it would be good to validate the decission on the mailing list
<darobin> ACTION: Robin to email Bryan to ask what his use cases are for apn, operatorName, mcc, mnc [recorded in http://www.w3.org/2010/05/26-dap-minutes.html#action02]
<trackbot> Created ACTION-176 - Email Bryan to ask what his use cases are for apn, operatorName, mcc, mnc [on Robin Berjon - due 2010-06-02].
tlr: roaming is a way to abstract to the user he may be charged for data connections more expensively
darobin: the use case is the "expensive flag", but not sure how to specify it in a way that is useful
<darobin> ACTION: Robin to ask the mailing about usage of roaming [recorded in http://www.w3.org/2010/05/26-dap-minutes.html#action03]
<trackbot> Created ACTION-177 - Ask the mailing about usage of roaming [on Robin Berjon - due 2010-06-02].
darobin: suggestion is keeping the rest of elements (included in item 4) in the spec
<darobin> RESOLUTION: keep the fields: type, currentDownloadBandwidth, currentUploadBandwidth, maxDownloadBandwidth, maxUploadBandwidth, currentSignalStrength
Suresh: From a conformance point
of view, could we group some of these properties
... it should be possible to query if one property group is
supported or not
darobin: this approach has not worked in DOM, SVG
<Zakim> dom, you wanted to note link with policy framework
Suresh: Key question is the sysinfo spec a all or none spec?
darobin: conformance is all or none, but for instance, if sensor does not return a value it would be acceptable
<dom> [I think making a concrete proposal would help in any case :) ]
darobin: if we want it to be
modular, we should split the spec
... handling it at the conformance level is very difficult
maxf: is there any conclusion on the issue of having multiple active connections?
darobin: no resolution so far
alissa: privacy discussions should be held when we have reached a conclusion on the multiple connections issue
<darobin> Suresh's comments
<maxf1> what's an "MMS connection"?
Suresh: we need also to clarify the meaning of connections in this context
<darobin> [I wonder if we don't have to expose multiple just to make sure we can be interoperable...]
darobin: what are the downsides
of having an array of multiple connections?
... complexity, interoperability problems, any other?
<darobin> PROPOSED RESOLUTION: we only expose active connections and we expose all of them through activeConnections
<darobin> RESOLUTION: we only expose active connections and we expose all of them through activeConnections
<maxf1> ACTION maxf to make activeConnection multiple
<trackbot> Created ACTION-178 - Make activeConnection multiple [on Max Froumentin - due 2010-06-02].
darobin: in general, the progress
of the APIs has been slowed down
... which are the reasons for that?
<dom> (tracker is supposed to be used for that; not that I mind using the wiki for it)
richt: pending resolutions on some issues may be a reason
<Dzung_Tran> I think the main reason got to do with privacy
tlr: we already have the tracker
darobin: kind of wiki in which we list the key issues for every API may help
<darobin> ACTION: Robin to get the ball rolling on documenting path forward for specs [recorded in http://www.w3.org/2010/05/26-dap-minutes.html#action04]
<trackbot> Created ACTION-179 - Get the ball rolling on documenting path forward for specs [on Robin Berjon - due 2010-06-02].
<maxf1> ah
tlr: concerns on the community about the capture API
darobin: still waiting for input from mozilla
<wojciech> yes
tlr: some concerns may be due to
confusion
... suggestion is putting on the list a clarification on the
scope of the capture API
<richt> sorry I dropped from the call.
<richt> I will document progress on the wiki for Contacts and Calendar
<darobin> ACTION: Robin to ping the editors about explaining the design of Capture on the list [recorded in http://www.w3.org/2010/05/26-dap-minutes.html#action05]
<trackbot> Created ACTION-180 - Ping the editors about explaining the design of Capture on the list [on Robin Berjon - due 2010-06-02].
maxf: last call in this WG, passing the editorshp on sysinfo the Dzung_Tran
<scribe> ... new Opera employee on this group, wojciech
<Dzung_Tran> Max, wish you well
<maxf1> thanks :)
<dom> welcome wojciech!
<darobin> RRSAgent: make minutes
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) Succeeded: s/enewland/Eric Newland/ Succeeded: s/topic/Topic:/ Succeeded: s/.html/.html Minutes of 19 May 2010 call/ Succeeded: s/<darobin> RESOLUTION:/<danielcoloma> RESOLUTION:/ Succeeded: s/returned/return/ Succeeded: s/that it/that/ Succeeded: s/hold/held/ Found Scribe: Daniel Found ScribeNick: danielcoloma Default Present: alissa, Dom, +1.314.454.aaaa, enewland, darobin Present: alissa Dom +1.314.454.aaaa enewland darobin Dzung_Tran Robin_Berjon Dominique_Hazael-Massieux Eric Newland Alissa_Cooper LauraA Marco_Marengo Daniel_Coloma Claes_Nilsson Richard_Tibbett Anssi_Kostiainen Wojciech_Maslowski Wojciech_Masłowski Suresh_Chitturi Regrets: Frederick_Hirsch John_Morris Arve_Bersvendsen Frederick Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010May/0123.html Found Date: 26 May 2010 Guessing minutes URL: http://www.w3.org/2010/05/26-dap-minutes.html People with action items: maxf robin[End of scribe.perl diagnostic output]
