See also: IRC log
<trackbot> Date: 19 September 2012
<scribe> Scribe: Josh_Soref
Josh_Soref: Next week is Yom Kippur
fjh: are there other people in Josh_Soref 's situation?
<dsr> I will be away for next 2 weeks.
<dsr> You can declare your phone number via the W3C User Search Form https://www.w3.org/Systems/db/userSearch and then click on the contact tab after having found yourself
<fjh> PING http://lists.w3.org/Archives/Public/public-privacy/2012JulSep/0059.html
fjh: there's a PING call
<fjh> PING is the privacy interest group, tomorrow call will have Dom reviewing 'Permissions on the Web', possible privacy review of WebIntents; I believe Paul Kinlan plans to attend as well as myself
<fjh> to attend you need to join PING
<fjh> I attended an earlier PING call and reviewed DAP privacy work in general
fjh: we'll defer until next week
Josh_Soref: i sent out a draft
... i'm going to send out a revised version
<fjh> Pick Contacts Intent updated, http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0058.html
Jungkee: i updated webidl definitions
... the type of array from Sequence Type
... dictionaries are pass by value
... one topic is search capability
... based on the intent discussion, we lost the extra field
... the extra field was meant to deliver types
... now we want to deliver type in the specific api
... for Pick-Contact/Pick-Media
... the need to request certain fields
... i'd like to hear some opinions about search/filtering fields
... maybe we can use the data field
... but that's defined to deliver the object itself
... maybe we put in extra information fields
... any ideas?
fjh: it seems like there are two issues
... 1. do we need search?
... 2. can extras be used
... I think being able to search makes sense
Jungkee: in the case of pick-contact
... contacts has quite a few fields
... and the client developer may require some number of fields
... explicitly from the services
... filtering capability is kind of necessary
Josh_Soref: at least initially, would rather see the providers manage this, they can design a better UI
... then we can think about an API
... there are too many ways to define a contacts database, for example an address field, various types with different semantics, e.g. business address vs address
... thus it isn't clear search will work as expected, depending on assumptions
... will need to work out patterns over time, then eventually standardize it
... also bad if request has to include 1,000 fields
... pick contacts and then fields you want (?)
<richt> +1 to Josh_Soref. Leave search/filtering up to providers initially.
Josh_Soref: josh suggests naviating through contacts
gmandyam: aren't you putting the problem of 1000 fields from the intent invocation
... and into the dialog box
Josh_Soref: case of picking intent provider or not,
... once picked then service provider can provide search, e.g. facebook does, google does,
... so good service providers already do this
... users would prefer seeing familiar Provider interface
... so let's leave it to the Provider
fjh: I could argue that is not aways true if users wish to use multiple services....
Josh_Soref: Users and sites can address confusion of multiple providers through the use of an aggregator
Jungkee: the client developer just want to make some specific request
... the fields that they can specify in filtering property
... is confined to fields already defined in the contacts intent spec
... it's constrained
... 1000 fields isn't going to happen
... it's just a hint to the Provider
... if the client has a specific UC
Josh_Soref: Clients will always have to have adaptation code
... for when Providers don't honor their "hints" or fill in fields insufficiently
... by not having hints, Providers are forced to consider users' Data privacy at a field level
... and design a UI to address this
... the Clients are saved from some "extra" (request) field filling which would be ignored
... either way they [the clients] had to write the adaptation code
... and the Providers don't get led down a path where they just provide all requested fields
... they have to think about and design a privacy conscious UI
fjh: [summarizing]
... pushing the search capabilities to the service provider
... you avoid issues of semantics for the service provider
... you reduce confusion for the user, and increase familiarity for the user
... the flip side is what happens for multiple providers
... or for non web providers
... possible confusion for user accessing variety of providers
Josh_Soref: for non-web provider (e.g. local) someone has to write adaptation code, will create UI
... e.g. for phone, would try to make it close to phone feel
... would have to consider privacy regardless, so not really different case
fjh: I thought initially in contacts API we had search to avoid retrieving more information than needed, data minimization
Josh_Soref: regarding only retrieving certain fields, I suggest it is more common to request all, since clients want to make sure they get what they need, and not blank fields
fjh: i think we need a CfC on the list
... obviously it simplifies stuff for us
... there's a certain logic to that, they know what matters to people in their domain
richt: i think leaving it to the providers initially is in their interest
... they don't want to give away the farm
... if providers return the same thing, we can later codify that
... providers will want to protect their users
fjh: it has the benefit that there's someone you can sue in court
... by leaving things to the providers
richt: right
... if the api has a bug in it, and it malfunctions, that's bad
fjh: i'm looking to see how to make it a specific thing
... CfC would say we remove extras
... and to remove the search functionality
Josh_Soref: i thought we already removed search
... and we're just saying we're removing field hints
Jungkee: i haven't removed the search field yet
fjh: i'll send out a CfC that does remove search+filter+field-hint
... i think we're agreed
... but since people aren't on the call, i think we should send out to the list
richt: you could define different service types that provide subsets of contact information
<fjh> ACTION: fjh to send CfC for removal of search from Pick Contacts [recorded in http://www.w3.org/2012/09/19-dap-minutes.html#action01]
<trackbot> Created ACTION-576 - Send CfC for removal of search from Pick Contacts [on Frederick Hirsch - due 2012-09-26].
richt: so if i'm just looking for "email addresses", that would be the service id
... i expect there to be innovation in that area
... you can have as many service types as you like
... and you request a subset
fjh: that makes sense too
Josh_Soref: +1
fjh: i'll send out the CfC, and we can move pretty fast w/ or w/o a call
... thanks Jungkee , Josh_Soref
fjh: dougt has created a new draft
<fjh> Latest draft, http://dvcs.w3.org/hg/dap/raw-file/tip/light/Overview.html
fjh: there were a few clarifying things on the list
... i think we'll publish an update fairly soon
... i guess that's a FPWD
... oh, we already have a FPWD
... so it'll be an update
... i don't think there's anything to discuss today
fjh: we have to move through LC comments
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0050.html
fjh: i don't think we're done w/ shepazu's comments
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0051.html
fjh: i haven't had a chance to go through them
<fjh> LC-2644 possible resolution, http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0079.html
fjh: i think we have a resolution for one
<fjh> "If document scanners and live scanners declaring themselves as cameras is a viable technical solution, it is fine."
Josh_Soref: Camera is a "still image capture device"
fjh: i think that's resolved
... we might need to clarify that somewhere in the doc
... does anyone have any concern?
[ None ]
<fjh> ACTION: fjh to draft text proposal to resolve LC-2644 [recorded in http://www.w3.org/2012/09/19-dap-minutes.html#action02]
<trackbot> Created ACTION-577 - Draft text proposal to resolve LC-2644 [on Frederick Hirsch - due 2012-09-26].
<fjh> http://w3c-test.org/dap/wi-addendum-local-services/
fjh: i think we're waiting on Cathy 's request for changes
Cathy: nothing on my part
... i think Claes is waiting for comments
fjh: i don't think we need to wait for comments before FPWD
... the act of FPWD will invite comments
<fjh> Propose to WebIntents TF to publish FPWD of "Web Intents Addendum - Local Services"
Claes: i think that would be good
<fjh> ACTION: fjh to propose FPWD publication of "Web Intents Addendum - Local Services" on TF [recorded in http://www.w3.org/2012/09/19-dap-minutes.html#action03]
<trackbot> Created ACTION-578 - Propose FPWD publication of "Web Intents Addendum - Local Services" on TF [on Frederick Hirsch - due 2012-09-26].
fjh: publication of FPWD should solicit comments
RESOLUTION: DAP is ok with a FPWD of Web Intents Addendum - Local Services
<fjh> Please remember to complete the WG questionnaire for the F2F and also the TPAC registration as well as making your travel arrangements.
<fjh> https://www.w3.org/2002/09/wbs/43696/dapf2ftpac2012/ ; http://www.w3.org/2012/10/TPAC/Overview.html#Registration
<fjh> Please suggest topics for DAP F2F agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France
fjh: i think we'll spend a good amount of time on Web Intents
... related, and how to work w/ whatwg
... Web Intents, Pick Contacts, Pick Media
... and HTML MC
... i'd prefer for people to edit the wiki directly
... does anyone have suggestions regarding the F2F?
... it looks like the Media TF will meet
... we might want to suggest they meet on Tuesday
... i think we're required to have a draft agenda 2 weeks before the F2F
dsr: the other thing to do is Observers
... to figure out how many are attending
fjh: to give them permissions
Josh_Soref: and to calculate room size
fjh: please think about the agenda
fjh: i need to resolve/reassign darobin 's
<fjh> ACTION-565?
<trackbot> ACTION-565 -- Josh Soref to propose text for HTML Media Capture to allow for alternative capture device if specified device not available -- due 2012-08-22 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/565
Josh_Soref: if you want to do it
... i think we're on the same page
<fjh> ACTION-568?
<trackbot> ACTION-568 -- Jungkee Song to work with Robin to move darobin to move API Cookbook to w3c space and prepare for publication as W3C FPWD NOTE -- due 2012-08-29 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/568
Jungkee: i spoke with darobin
... he's going to do the action very soon
... i'm waiting for that
... it should happen within a week
<fjh> ACTION-519?
<trackbot> ACTION-519 -- Claes Nilsson to add a proposal for hidden disposition. -- due 2012-08-15 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/519
<fjh> in progress
<fjh> ACTION-572?
<trackbot> ACTION-572 -- Frederick Hirsch to move specs in the home page Roadmap to 'Exploratory Work' section -- due 2012-09-05 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/572
<fjh> close ACTION-572
<trackbot> ACTION-572 Move specs in the home page Roadmap to 'Exploratory Work' section closed
trackbot, end meeting