See also: IRC log
<trackbot> Date: 02 June 2010
<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
<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
<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
<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
<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)
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].
<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