See also: IRC log
<trackbot> Date: 28 April 2010
<alissa> ok
<alissa> scribenick: alissa
<fjh> Privacy workshop, Mon/Tue 12-13 July 2010, London
Privacy workshop, Mon/Tue 12-13 July 2010, London
http://www.w3.org/2010/api-privacy-ws/
fjh: our F2F is now starting Weds, July 14
drogersuk: OMTP is flexible with hosting
<drogersuk> http://www.ceop.gov.uk/
drogersuk: also arranging a visit to CEOP one evening of F2F
<nwidell> (will be IRC only first 30 minutes of this call
<drogersuk> potentially we could setup two separate visits, but these will not infringe directly on the meetings - they would be after
<inserted> ScribeNick: dom
frederick: not sure if we should have a 2 or 3 days meeting
... probably won't need to discuss privacy given that we'll have discussed it for two days during the workshop before
Bryan: I suggest going for 3 days
... our F2F meetings are fairly productive
<AnssiK> personally I'm not avail for Fri
Robin: suggests 2.5 days to allow for people to leave early on Friday
... re privacy, I'm hoping we'll get new input from the workshop that will be worth processing
Frederick: does anybody have a problem with 2.5 days?
David: we can accommodate for that one way or another re hosting
RESOLUTION: Next F2F on July 14 to 16 in London
<Suresh> does it end at 12:00noon on the 3rd day?
RESOLUTION: Next F2F on July 14 to 16 in London, ending at 2 or 3pm on Friday
frederick: our hosts will need to look into lunch & logistics
(note that attendance at the workshop requires sending a position paper)
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/att-0080/minutes-2010-04-21.html
<fjh> 21 April 2010
RESOLUTION: Minutes of April 21st approved
<scribe> ScribeNick: alissa
<fjh> Policy requirements and framework
<fjh> http://dev.w3.org/2009/dap/policy-reqs/
<fjh> ACTION: fjh to review policy requirements and propose changes [recorded in http://www.w3.org/2010/04/28-dap-minutes.html#action01]
<trackbot> Created ACTION-166 - Review policy requirements and propose changes [on Frederick Hirsch - due 2010-05-05].
<fjh> http://dev.w3.org/2009/dap/policy/
will resume scribing now
<fjh> layering model considerations can move to requirements doc?
fjh: Laura still needs to add trust domain stuff from Nokia
Laura: still working on it
... maybe done early next week
fjh: two different things in document
... 1 model of how security works
... 2 detailed XACML profile
... 1 very tied to 2
... XACML profile could be its own doc
... but issues still lie in model piece
... maybe need some layering to separate out XACML
dom: no problem with the length, but perhaps the scope
<fjh> we might want to split framework into model and separate xacml profile document
dom: rules lang, ID model, model for environment, capacities model,policy decision model -- lots of stuff
... makes it harder to get reviews, to get browsers to look at it, etc.
<dom> Dom's comment on policy framework
fjh: could make XACML part separate pretty easily
... not a whole lot in the rest of the doc
... need suggestions on way forward
<dom> ACTION: Dom to make a concrete proposal for policy framework based on his comments http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0030.html [recorded in http://www.w3.org/2010/04/28-dap-minutes.html#action02]
<trackbot> Created ACTION-167 - Make a concrete proposal for policy framework based on his comments http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0030.html [on Dominique Hazaël-Massieux - due 2010-05-05].
fjh: next step: Laura to finish, others to think about way forward
<fjh> comment from Claes
<fjh> <http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0084.html
Claes: tables defining the subject attributes -- didn't understand
<fjh> http://dev.w3.org/2009/dap/policy/#subject-attributes
Laura: have not had time to respond yet
Claes: important to be able to identify a unique web application, not just domain
<dom> (this is an example of why identity in itself is probably worth a spec on its own :)
fjh: will take this to the list
<fjh> identity is one area to call out
Suresh: sent an email awhile ago asking how the warp (?) spec in widgets group is relevant to policy
... if you run this against widget environment, widget config will come into effect
<fjh> http://www.w3.org/TR/2010/CR-widgets-access-20100420/
fjh: answer was that warp was an intermediate specification- we should look at it
darobin: warp is in CR
... it's one use case, so if policy doesn't cover what warp does, that's a problem
Suresh: couldn't we just reference it?
darobin: it's fine to redefine it
... otherwise might have to caveat warp out
Suresh: if we can reference it, we should
darobin: not sure how reusable warp is, not certain
<fjh> issue: note relationship of WARP to DAP policy work
<trackbot> Created ISSUE-83 - Note relationship of WARP to DAP policy work ; please complete additional details at http://www.w3.org/2009/dap/track/issues/83/edit .
<fjh> privacy requirements
<fjh> http://dev.w3.org/2009/dap/privacy-reqs/
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0088.html
<fjh> this draft fills in details, removes ambiguous language and adds new requirements
<fjh> this could impact API work
<scribe> ACTION: Alissa to incorporate edits into Privacy Requirements. [recorded in http://www.w3.org/2010/04/28-dap-minutes.html#action03]
<trackbot> Created ACTION-168 - Incorporate edits into Privacy Requirements. [on Alissa Cooper - due 2010-05-05].
<dom> (I had trouble with the interpretation of "mutually exclusive" in Alissa's response; I think we should talk about subsetting relationships rather)
fjh: had some placeholder text for APIs
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0086.html
<dom> ACTION-114?
<trackbot> ACTION-114 -- Alissa Cooper to phrase the temporary privacy section -- due 2010-03-23 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/114
<darobin> [yeah, that's part of what I was thinking about — but I need to ground those ideas in examples to see if it would make sense]
fjh: can editors put in the text?
<soonho> (I am attending this conference call only via IRC.)
<scribe> ACTION: Frederick to insert temporary privacy language into the APIs. [recorded in http://www.w3.org/2010/04/28-dap-minutes.html#action04]
<trackbot> Created ACTION-169 - Insert temporary privacy language into the APIs. [on Frederick Hirsch - due 2010-05-05].
<darobin> ACTION-142?
<trackbot> ACTION-142 -- Max Froumentin to propose two interfaces Outgoing and Incoming messages for messaging API -- due 2010-03-25 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/142
darobin: hasn't been much feedback on this -- should we go ahead with it?
Suresh: don't see why we want to split into incoming and outgoing
... only distinguished by send
... if we split will need interface for draft message, e.g.
<dom> Messaging API discussions at the F2F
maxf: I don't have insight into which way we're going, just need to make a choice
... don't have a strong opinion
dom: we had the distinction because incoming should be read-only
... send on incoming doesn't make any sense
... maybe incoming/outgoing is misleading; it should be about whether it will be sent
... distinction has value
darobin: same intf with different rules?
Suresh: have exception on send for incoming
<maxf> the proposal I had: http://www.w3.org/mid/4BD04FAA.2010107@opera.com
Suresh: can address use case with what we have
<maxf> ah, no.
darobin: might want to filter received messages to make them readable
bryan: messages should be editable in the inbox
<maxf> http://www.w3.org/mid/4BCF032E.9050900@opera.com
bryan: once you've stored a message, you need an ID to edit
... the attributes end up becoming similar between the two
... although there are exceptions
darobin: hearing more arguments in favor of single interface
Suresh: once we have folder management, we can come back to this
darobin: not strongly tied to folders
... sent mail folder is more of an implementation detail
Suresh: can tag msgs as sent or received
darobin: if object fields are similar, it's a small decision between object type and type flag
... hearing stronger consensus for single interface
dom: already have a type flag
... need to disambiguate names
<Suresh> 'status'
RESOLUTION: Messages have a single interface irrespective of their type. Need a better name for type (status?).
<darobin> close ACTION-142
<trackbot> ACTION-142 Propose two interfaces Outgoing and Incoming messages for messaging API closed
maxf: so we're not keeping a per-type (MMS, SMS) interface then?
Suresh: should separate interfaces based on messaging type
... BONDI separates the interfaces
<darobin> [actually these two are half-orthogonal — if we have separate for incoming/ougoing *and* for types we get IncomingSMS, OutgoingSMS, IncomingEmail, ...]
Suresh: right now we create a superset interface and we're silent for what doesn't apply
<darobin> [given a unified in/out interface, if we split we just get Email, SMS, MMS]
Suresh: implementations might have separate modules for different messaging technologies
darobin: some implementations might only support email
Suresh: separation lets implementations pick
bryan: extension to specific message types is a useful approach (attachments aren't relevant for SMS, e.g.)
... defining message types is a better approach
<maxf> +1 with Bryan: different interfaces handles the attribute errors automatically
Suresh: makes spec longer
<dom> (which we'll have to do for incoming/outgoing :) )
Suresh: will miss exception cases
RESOLUTION: Have multiple interfaces for different messaging technologies (i.e., message types).
<Zakim> darobin, you wanted to bring up numerical constants
<dom> (this relations to ACTION-139)
<dom> ACTION-139?
<trackbot> ACTION-139 -- Max Froumentin to fix section 5 "supported messaging types" in Messaging API to clarify handling of non-supported attributes -- due 2010-03-25 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/139
maxf: will wait to update until receiving something from Suresh
<maxf> I was asking about a resolution on the priority attribute
Suresh: priority attribute is not applicable for SMS and MMS, but it is for email
... since we're separating, we should add it to email
bryan: why isn't priority applicable to MMS?
Suresh: it's not defined in the MMS spec
... user-defined priority
<dom> (another item that my MUA lets me set at writing time: reply-to)
dom: could have generic getheader and setheader?
darobin: concerned about security issues (in XHR had to jump hoops re headers)
<dom> (at least getHeader() should exist?)
<darobin> [yeah, getHeader() makes sense — note that it can return an array]
Suresh: list of headers is not long right now
darobin: there are many email headers
dom: PHP lets you write any header
bryan: could deal with security issues separately from API functionality
<nwidell> (maybe we should decide on abstraction level of Messaging API)
bryan: could define specific attributes for most common message fields, but use others by name through generic mechanism
<dom> [we could WebIDL setter/getter? not sure if it's worth it, though]
<darobin> [email from Suresh: X-Original-To, Delivered-To, Received, X-AuditID, X-MimeOLE, Content-class, MIME-Version....]
<darobin> ACTION: Robin to review the options for headers on emails [recorded in http://www.w3.org/2010/04/28-dap-minutes.html#action05]
<trackbot> Created ACTION-170 - Review the options for headers on emails [on Robin Berjon - due 2010-05-05].
<dom> ISSUE: which headers to support setting/getting in Messaging API?
<trackbot> Created ISSUE-84 - Which headers to support setting/getting in Messaging API? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/84/edit .
darobin: lots of different headers that might need support
... will draft an email with use cases, review XHR
nwidell: question of size and scope of API
... do we really have a use case for replacing outlook?
<AnssiK> go for 80/20
bryan: providing a message where you can get/set fields by name, keeps API small
... if we have something generic, market will find useful ways to leverage it
<maxf> ScribeNick: maxf
Suresh: we didn't talk about ability to identify messages by Service, like in Contacts
... people have different email accounts.
<darobin> +1
Suresh: retrieving by service is useful.
... e.g. different mailboxes
<darobin> [you get some emails from Opera, others from GMail, etc. different accounts]
Suresh: different accounts
<nwidell> +1 (was thinking about same thing before going AWOL ;-)
darobin: account-ID sounds better than service-ID
darobin: seems to be heading towards using object literals
... objections?
dom: I'm not sure I would call it a consensus
... about half and half
darobin: happy to keep discussion alive
dom: perhaps we need to wait a bit, see if anybody reacts further
darobin: ok
<dom> (this was about ISSUE-55)
darobin: david suggested he might be able to find someone
<dom> ACTION-147?
<trackbot> ACTION-147 -- David Rogers to look for an editor for the Tasks API -- due 2010-03-25 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/147
<drogersuk> Hello?
Suresh: is Tasks among the priority APIs?
<drogersuk> Can you hear me?
darobin: not necessarily, but editors would be welcome
drogersuk: didn't see any responses when I asked
<dom> close ACTION-147
<trackbot> ACTION-147 Look for an editor for the Tasks API closed
<dom> ACTION-147: no one took up the offer
<trackbot> ACTION-147 Look for an editor for the Tasks API notes added
darobin: then we might just have to wait
darobin: we're going to need a test framework soon
<dom> A Proposal for the Testing Framework, Soonho Lee
<drogersuk> +1
darobin: dom also looked at it
<dom> wttjs
dom: I found WTTGS which generates test cases based on webidl
... it's not as good as it could be, not too good for async interfaces
<darobin> bah
darobin: widlproctools might be a better start. Hoping I'll be able to work on it soon.
<darobin> s/-> http://www.w3.org/mid/n2n708552fb1004071110x6d98c6e6t85e83eef0eef52de@mail.gmail.com//
<dom> ACTION-150?
<trackbot> ACTION-150 -- David Rogers to send BONDI experience with testing for device APIs -- due 2010-03-25 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/150
<darobin> s/drogersuk: trying to lobby for your case with new Bondi CEO (Geoff Jackson?)//
sorry
<drogersuk> example of W3C minuting!
drogersuk: dom, let's speak offline about it, cause I think we have a plan.
<scribe> ACTION: drogersuk and Dom to speak offline on testing framework [recorded in http://www.w3.org/2010/04/28-dap-minutes.html#action06]
<trackbot> Created ACTION-171 - And Dom to speak offline on testing framework [on David Rogers - due 2010-05-05].
drogersuk: there's a large amount of interest, since manufacturers need to be able to claim compliance
... we'd like to endorse Marcos' job with widgets specs
darobin: we should try and get him on this group to help. And we should try and gather as much manufacturer power as possible
<darobin> ack !
<drogersuk> I need to jump onto another conference call, see you guys later
<dom> (regrets for next two weeks from me)