W3C

Device APIs and Policy Working Group Teleconference

02 Jun 2010

Agenda

See also: IRC log

Attendees

Present
Anssi_Kostiainen, David_Rogers, Dzung_Tran, Erica_Newland, Frederick_Hirsch, Ilkka_Oksanen, Laura_Arribas, Maria_Oteo, Paddy_Byers, Robin_Berjon, Suresh_Chitturi, Wojciech_Maslowski, Wonsuk_Lee, bryan_sullivan
Regrets
Dominique_Hazael-Massieux, Marco_Marengo, John_Morris, Claes_Nilsson, Richard_Tibbett, Alissa_Cooper
Chair
Robin_Berjon, Frederick_Hirsch
Scribe
Suresh

Contents


<trackbot> Date: 02 June 2010

Agenda review, Announcements

<fjh> Additional announcement: upcoming Last Call for the Media Resource API

<fjh> http://lists.w3.org/Archives/Public/public-media-annotation/2010Jun/0023.html

<fjh> The Media Annotations WG plans a 4 weeks Last Call review, ending on

<fjh> July 11, 2010.

<darobin> if possible I'd like to get several people reviewing the MAWG drafts

<darobin> last time there were a number of issues

<fjh> add to agenda, action notification item

<scribe> ScribeNick: Suresh

<fjh> Additional announcement: upcoming Last Call for the Media Resource API

<fjh> http://lists.w3.org/Archives/Public/public-media-annotation/2010Jun/0023.html

<fjh> The Media Annotations WG plans a 4 weeks Last Call review, ending on July 11 2010

robin: reviewed previous versions..it is important for us (e.g. Gallery API)

more people to review the better

<fjh> Ontology for Media Resource 1.0

<fjh> API for Media Resource 1.0

fjh; any volunteers?

<darobin> ACTION-143?

<trackbot> ACTION-143 -- Anssi Kostiainen to provide feedback on the list on Gallery API -- due 2010-03-25 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/143

Anssi: I have an action for Gallery API, and can also take this one together

<scribe> ACTION: Bryan (AT&T) to review API and Ontology for Media Resource API [recorded in http://www.w3.org/2010/06/02-dap-minutes.html#action01]

<trackbot> Created ACTION-181 - (AT&T) to review API and Ontology for Media Resource API [on Bryan Sullivan - due 2010-06-09].

<darobin> ACTION: Robin to review API and Ontology for Media Resource API [recorded in http://www.w3.org/2010/06/02-dap-minutes.html#action02]

<trackbot> Created ACTION-182 - Review API and Ontology for Media Resource API [on Robin Berjon - due 2010-06-09].

<bryan_sullivan> that was me - reconnecting

<darobin> +1

<fjh> Deadline Extended to 7 June for Privacy Workshop Position Papers

The group to enable notifications of action items follow-up

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0002.html

<fjh> DAP registration form

<fjh> http://www.w3.org/2002/09/wbs/43696/london2010/

Resolution: The group to enable action notifications

Minutes approval

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010May/att-0131/26-dap-minutes.html

<fjh> 26 May 2010

RESOLUTION: 26 May 2010 minutes approved

Policy Framework

<LauraA> http://dev.w3.org/2009/dap/policy/Framework.html

<LauraA> http://dev.w3.org/2009/dap/policy/Profile.html

<LauraA> http://dev.w3.org/2009/dap/policy/Examples.html

Laura: Examples document may need more examples
... focusing on framework document, and any help with other documents would be good

Powerbox

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010May/0133.html

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0009.html

fjh: a concern expressed on the list re what we are doing

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0020.html

Suresh: Is there a relation between the two?

fjh: the group agreed to work on the current JS API approach

<darobin> ACTION-109?

<trackbot> ACTION-109 -- Robin Berjon to write up Prague Doctrine (define in WebIDL, have mappings to JS and REST as needed, leave which is implemented up to implementers just like they could decide to map WebIDL to Java, have orthogonal installation/exposing aspects like PB defined, well, orthogonally) -- due 2010-03-23 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/109

<fjh> Remember the WG agreed with Resolution on javascript API priority, so we continue with that approach. However it is good to have this additional material to review

David: to make this succesful, we need to engagement,

the proponents should attend the F2F, it is critical

<fjh> I note that this powerbox revision is an improvement and offers more clarity on that approach

we need to understand how the powerbox model fits into mobile (e.g. Android)

<drogersuk> was hoping the guys would be on the call today

fjh: wondering about the acronym UMP used in the draft, IPR issues, etc.

<drogersuk> we have bryan here - he has to do the same

APIs -SysInfo

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010May/0144.html

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010May/0145.html

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0001.html

robin: we have a few issues to discuss before we proceed towards Call for Consensus (Last call)

<darobin>

Bryan: the use cases are more driven from mobile,

robin: disagree that it is mobile spec, yes mobile is important but the API needs to work on other devices as well

concerns about privacy were also raised

Bryan: knowing the operator and roaming are good indicators

a distinction between national and international can be sufficient

home-> home domain

scribe: it allows to optimize network interaction

<drogersuk> high cost when roaming is the use case robin

<drogersuk> protecting the consumer

<fjh> use cases - http://lists.w3.org/Archives/Public/public-device-apis/2010May/0145.html

<AnssiK> "The System Information API: Mobile Extensions"

<darobin> Roaming discussion

<darobin> +1 to tlr's proposal

tlr: moving it into a separate specification may help

<Zakim> fjh, you wanted to ask about timing of extension api

<drogersuk> I agree - this is a very important use case for users and operators

<drogersuk> most devices have UICCs in these days

Bryan: we don't need a separate specification, we just need to support an API to access supported properties

<darobin> PROPOSED RESOLUTION: split operatorName, apn, mcc, mnc to a separate, extended specification

<drogersuk> let me take this back into OMTP

<drogersuk> I can get some more feedback

<tlr> move it into CR independently

<darobin> RB: we can move both to LC (even if the extension is FPWD) at the same time

David: where are the objections coming from (e.g. roaming, network operator)?

<fjh> operatorName, mcc, mnc ?

<darobin> origin of discussion

<darobin> and apn

robin: the idea is to put them in a separate spec

droger: we are not being consistent....
... we have policy to control access

robin: the API design is to work independent of policy

droger: we should not pick on individual fields

robin: we have looked at other fields such as SSID, etc

fjh: is the concern that if it is a separate spec it will be dropped?

droger: i'm happy to take a look at this again with an action

<Dzung_Tran> same here, I don't know why we want another spec. It will get drop.

droger: we would like more time to review before going to LC

<darobin> PROPOSED RESOLUTION: we give one week, and not a day more, to receive an objection to splitting off operatorName, apn, mcc, mnc into a separate specification that is reasonably grounded

robin: one week is reasonable but not more

Bryan: i don't see the value in moving few properties into separate spec
... passing string to access property value is the correct approach

RESOLUTION: The SysInfo mobile network attribute gets one week extra discussion, decision for LC will be made next Thursday

<fjh> my understanding is that if there is an extension spec, it would go into LC at the same time

<drogersuk> Sorry guys I have to go to another call

<darobin> PROPOSED RESOLUTION: drop connections[] and activeConnection, move to activeConnections[]

robin; re active connections, we agreed to keep only active connections

Bryan: do we mean available or transfering data?

<darobin> Bryan: we need to define clearly what "active" means

RESOLUTION: drop connections[] and activeConnection, move to activeConnections[]

<darobin> ACTION: Dzung to drop connections[] and activeConnection, move to activeConnections[] and define clearly what "active" means [recorded in http://www.w3.org/2010/06/02-dap-minutes.html#action03]

<trackbot> Created ACTION-183 - Drop connections[] and activeConnection, move to activeConnections[] and define clearly what "active" means [on Dzung Tran - due 2010-06-09].

Contacts API

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0007.html

<tlr> +1 to deferring

robin: we received feedback from Mozilla, with specific details

<fjh> +1 to defer

Contacts API discussion deferred...

tlr: Announcement: Privacy workshop deadline pushed back

Suresh> would Opera continue with editorship with Messaging API?

<wmaslowski> i think he handed it to someone - should be in the minutes

<dom> s/<darobin> RESOLUTION:/<Suresh> RESOLUTION:/g

<dom> s/robin; /robin: /gg

Summary of Action Items

[NEW] ACTION: Bryan (AT&T) to review API and Ontology for Media Resource API [recorded in http://www.w3.org/2010/06/02-dap-minutes.html#action01]
[NEW] ACTION: Dzung to drop connections[] and activeConnection, move to activeConnections[] and define clearly what "active" means [recorded in http://www.w3.org/2010/06/02-dap-minutes.html#action03]
[NEW] ACTION: Robin to review API and Ontology for Media Resource API [recorded in http://www.w3.org/2010/06/02-dap-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $