07:03:03 RRSAgent has joined #dap 07:03:03 logging to http://www.w3.org/2011/07/19-dap-irc 07:03:05 RRSAgent, make logs world 07:03:05 Zakim has joined #dap 07:03:07 Zakim, this will be DAP 07:03:07 ok, trackbot; I see UW_DAP(WGF2F)2:00AM scheduled to start 63 minutes ago 07:03:08 Meeting: Device APIs and Policy Working Group Teleconference 07:03:08 Date: 19 July 2011 07:03:53 Chair: Robin_Berjon, Frederick_Hirsch 07:03:57 lgombos_ has joined #dap 07:04:13 Present+ Robin_Berjon, Frederick_Hirsch 07:04:24 Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_19,_20,_21_July_2011,_Paris 07:04:30 Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_19,_20,_21_July_2011,_Paris 07:05:12 robin has joined #dap 07:05:32 richt has joined #dap 07:05:36 richt has left #dap 07:05:38 richt has joined #dap 07:05:47 darobin has joined #dap 07:05:58 ernesto_jimenez_ has joined #dap 07:07:23 hi all. are you guys set up? 07:08:03 wonsuk has joined #dap 07:08:20 Present+ Wonsuk_Lee 07:08:44 Kihong_Kwon has joined #dap 07:08:54 zakim, code? 07:08:54 the conference code is 94323 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), francois 07:09:48 UW_DAP(WGF2F)2:00AM has now started 07:09:56 +Caroline 07:10:23 zakim, Caroline is Orange 07:10:23 +Orange; got it 07:10:28 zakim, Caroline is DAP 07:10:28 sorry, robin, I do not recognize a party named 'Caroline' 07:10:31 SungOk_You has joined #dap 07:10:44 Topic: Administrative 07:10:48 ok great. I'm joining for the morning session. Will dial in now. 07:11:25 + +44.208.144.aaaa 07:11:35 shan has joined #dap 07:11:36 Present+ Rich_Tibbett 07:11:37 scribe: francois 07:11:42 Johnson has joined #dap 07:11:47 zakim, aaaa is me 07:11:47 +richt; got it 07:11:57 Present+ Laszlo_Gombos 07:12:09 Present+ Robin_Berjon 07:12:10 Present+ FrancoisDaoust 07:12:12 Present+ SungOk_You 07:12:18 Present+ Ernesto_Jimenez 07:12:35 [round of introduction] 07:13:34 Present+ Johnson_Wang 07:13:47 cmarc has joined #dap 07:13:57 Present+ Kihong_Kwon 07:14:43 [francois explaining that he is replacing Dom for this meeting as he's away] 07:14:53 Present+ Cecile_Marc 07:15:12 zakim, who is here? 07:15:12 On the phone I see Orange, richt 07:15:13 On IRC I see cmarc, Johnson, shan, SungOk_You, Kihong_Kwon, wonsuk, ernesto_jimenez, robin, richt, lgombos_, Zakim, RRSAgent, francois, fjh, homata, homata_, wmaslowski, lgombos, 07:15:15 ... ilkka, ingmar, dom, trackbot 07:15:25 wmaslowski has left #dap 07:15:28 Present+ Soonbo_Han 07:16:01 fjh: we'll start by reviewing the agenda, approve last minutes, and check rechartering. 07:16:46 robin: DanA may not join us today. To be confirmed. 07:16:54 bryan has joined #dap 07:17:20 fjh: [going through the agenda] 07:17:32 present+ Sullivan_Bryan 07:17:32 ceyrigno has joined #dap 07:17:52 fjh: comments on the agenda, requests for things to add? 07:18:18 wonsuk: slot to discuss on Webkit implementations 07:18:32 robin: right, we can probably discuss that on Thursday morning. 07:18:45 fjh: no telcon on 27th July following the meeting 07:18:58 RESOLUTION: no DAP telcon on 27th July 2011 07:19:22 fjh: concerns with last minutes? 07:19:56 ??1: question about relationship with Webinos. Anyone went to their latest F2F? 07:20:24 zakim, who is here? 07:20:24 On the phone I see Orange, richt 07:20:25 On IRC I see ceyrigno, bryan, cmarc, Johnson, shan, SungOk_You, Kihong_Kwon, wonsuk, ernesto_jimenez, robin, richt, lgombos_, Zakim, RRSAgent, francois, fjh, homata, homata_, 07:20:27 ... lgombos, ilkka, ingmar, dom, trackbot 07:20:42 s/??1/Sungok_You/ 07:20:44 robin: no direct contact but there are people in this group contributing to Webinos who are not there today. No formal coordination, but e.g. Dom is on Webinos. 07:21:04 ... I suspect we'll hear from them pretty soon. 07:21:21 Sungok_You: do you know if members can join Webinos? 07:21:26 robin: no idea. 07:21:34 bryan: any minutes or report? 07:21:38 robin: I can ask. 07:21:47 fjh: ok, so minutes approved. 07:22:03 RESOLUTION: minutes from 13 July 2011 are approved. 07:22:09 http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/att-0079/minutes-2011-07-13.html 07:22:17 Topic: Charter review 07:22:22 http://www.w3.org/2010/11/DeviceAPICharter.html 07:23:32 latest version: http://www.w3.org/2011/07/DeviceAPICharter 07:24:28 francois: in progress. No precise date for W3M review yet. Sooner rather than later. 07:25:31 robin: for practical purpose here, we should consider the latest draft version to be in effect. There are a few areas that may look dodgy right now and are under negotiation. 07:25:55 ... The short name of the group remains DAP, even though the P doesn't stand for anything anymore. 07:26:16 ... The new charter runs through the end of July 2013. Easy to finish all deliverables by then, right? 07:26:49 ... Goals have been clarified to ensure that people that we're addressing the whole ecosystem of consumer electronic devices, incl. eg. TV. 07:27:15 youenn has joined #dap 07:27:22 ... Privacy was added to Scope section (it was a main work item before but was not in the scope) 07:27:29 + +1.617.453.aabb 07:27:30 -richt 07:27:43 zakim, aabb is richt 07:27:43 +richt; got it 07:27:51 ... Clearly out of scope is the security context different from the default Web browser security context. 07:28:45 ... There's a deliverable based on Web Introducer / Web Intent / whatever which could be a major deliverable provided we get the right persons to work on it. 07:29:08 ... Clarification on vibration. 07:29:24 ... One addition: discovery on the local network. 07:29:32 fjh: one of the ones people are concerned about. 07:29:50 robin: yes, we expect to work on this in collaboration with Web and TV IG and MMI. 07:30:29 ... It's possible that in some point in the future that a group specific to device discovery be created and work moved there, but for practical reasons, we should just proceed here. 07:30:53 fjh: we have on the goals privacy by design but still difficult to frame it in practice. 07:31:25 robin: beyond that, it's mostly a timeline that we may update provided we document updates on the group's home page. 07:31:54 fjh: checking the current table 07:32:27 ... Contacts API looks doable 07:32:59 robin: decision need to be taken on implementation criteria (WebIDL and/or JavaScript) 07:33:10 fjh: Other milestones sound reasonable. 07:33:37 robin: battery has an active editor, Network APIs and Media Capture and Messaging would benefit from more contributions. 07:33:52 ... Not a lot of work but we'd benefit from someone stepping up. 07:34:13 ... Dom and myself are doing a bit because no one's doing it. 07:35:04 ??2: I can probably say next week whether I can contribute more to some of it. 07:35:20 robin: feel free to pick up more than one ;) 07:35:34 ... no need to worry about making mistakes. 07:35:46 Youngsun has joined #dap 07:35:55 ... Rich has been editing Contacts but said he would welcome help as well. 07:35:58 jun has joined #dap 07:36:16 fjh: ok, would be very useful if you can help. 07:36:16 yes, I would welcome any help from other participants. 07:36:20 ..on Contacts 07:37:01 wonsuk: relationship between scope and work carried upon in Web Real-Time Communications WG. 07:37:13 zakim, who is here? 07:37:13 On the phone I see Orange, richt 07:37:14 On IRC I see jun, Youngsun, youenn, ceyrigno, bryan, Johnson, shan, SungOk_You, Kihong_Kwon, wonsuk, ernesto_jimenez, robin, richt, lgombos_, Zakim, RRSAgent, francois, fjh, 07:37:16 ... homata, homata_, lgombos, ilkka, ingmar, dom, trackbot 07:37:25 s/??2/ernesto_jimenez/ 07:37:33 robin: there's been coordination between DAP and Web RTC. 07:37:46 kyungtak has joined #dap 07:38:02 Present+ Kyung-Tak_Lee 07:38:20 ... streams are essentially to be done in Web RTC WG. Media capture remains in DAP. This API might have ways to expose more advanced parameters to control devices (audio/video parameters) 07:38:42 ... The charter allows us to discuss with Web RTC WG and draw the line. 07:39:02 ... It's fairly obvious for real-time communications. 07:40:05 ... The augmented reality use case is essentially theirs. Plus they're going to do P2P as well. 07:40:20 bryan: you mentioned AR. Is that something in their charter? 07:40:42 robin: I don't think any group has AR in their charter, but a lot of groups are doing parts of it. 07:41:04 bryan: media preview was part of DAP, right? 07:41:15 robin: we didn't have proposals around that. 07:41:43 bryan: presenting something as opposed to communicating would still be in DAP? 07:42:22 robin: well, that remains in Web RTC, I think from an implementation perspective because assigning a stream will use the same mechanism as for communication. 07:44:20 francois: Web RTC will focus on audio/video communications. Active discussions on reliable/unreliable datagrams but unclear at this stage what will be included in the "first" version. 07:45:18 robin: one thing that will happen once charter comes into effect: several commenters worried about the long list of deliverables, willing to be able to nominate people to work on specific work items. 07:46:19 ... Some logistics to be made: task forces, separate mailing-lists, emails tagging, there are different ways to address this. Discussion we should have not only within the group but also with people that may be interested in some of the deliverables. 07:46:55 fjh: if somebody wants to participate, he'll participate. Email tagging is a great way to classify topics. 07:47:12 who just joined? 07:47:29 Present+ Jerome_Giraud 07:47:40 Topic: Use case review for all specs 07:48:01 rrsagent, generate minutes 07:48:01 I have made the request to generate http://www.w3.org/2011/07/19-dap-minutes.html fjh 07:48:09 robin: if we're to have a complete use cases doc for each spec, we're going to spend the next two years doing just that. 07:48:40 ... The goal is more to have a short paragraph that describes what each spec solves, the goals. 07:48:49 fjh: we should look at one spec as an example. 07:49:02 ... Contacts for instance. 07:49:14 some Contacts UCs are in https://lists.webkit.org/pipermail/webkit-dev/2011-July/017456.html 07:49:43 http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/#contacts 07:49:52 wonsuk: if we add use cases to each spec, we should add requirements to each spec. 07:50:56 robin: we should be careful about the API requirements document. Very early draft. Meant to foster discussions. A few updates by Dom but mainly obsolete. 07:51:09 ... We still have requirements for file API although we don't have that anymore. 07:51:23 ... Same for application launcher. 07:51:45 ... Probably a good idea to mark this document as being dead and import the useful requirements into each spec. 07:51:52 wonsuk: yes. 07:51:58 cmarc has joined #dap 07:52:14 robin: if we agree we're going to move requirements to each spec, then we should kill this document. 07:53:02 ACTION-281? 07:53:02 ACTION-281 -- Dominique Hazaël-Massieux to take a stab at updating the API Requirements documents -- due 2011-05-10 -- OPEN 07:53:02 http://www.w3.org/2009/dap/track/actions/281 07:53:11 bryan: it would be useful somewhere early in the Contacts spec to say that it's read-only. Maybe the rationale behind that would explain why. Use cases may clarify that. 07:53:29 fjh: right. This is a last call comment. 07:53:30 last call comment on use cases - clarify that read only, add section on requirements and use cases 07:53:53 ACTION: Robin to end-of-life API Requirements (CVS and published version) 07:53:53 Created ACTION-420 - End-of-life API Requirements (CVS and published version) [on Robin Berjon - due 2011-07-26]. 07:54:44 proposed RESOLUTION: put use cases and requirements in each requirements and kill requirements document. 07:54:50 ceyrigno has joined #dap 07:54:59 proposed RESOLUTION: put use cases and requirements in each specification and kill requirements document. 07:55:15 RESOLUTION: put use cases and requirements in each specification and kill requirements document. 07:55:33 fjh: worried about Contacts to start with as fairly advanced. 07:56:14 robin: should be right after introduction. We usually have an examples section, use cases and requirements would fit there. 07:56:50 fjh: this should help Ernesto take his decision to become an editor ;) 07:57:15 Use Case and Requirements sections would be helpful as it's not clear until you get into the spec, what types of functionality is supported. For example Contacts is a read-only API, and although there may be good reasons for omission of write ability in this version, it would be helpful to make it clear that write is not supported, and in significant cases such as this (limiting the supported use cases), why the use case is not supported in this version. 07:57:38 ACTION: Ernesto to add use cases and requirements, with examples, to Contacts as an example of the way this should be done throughout. Input from https://lists.webkit.org/pipermail/webkit-dev/2011-July/017456.html may be useful. 07:57:38 Created ACTION-421 - Add use cases and requirements, with examples, to Contacts as an example of the way this should be done throughout. Input from https://lists.webkit.org/pipermail/webkit-dev/2011-July/017456.html may be useful. [on Ernesto Jimenez - due 2011-07-26]. 07:58:05 bryan: we might look to future versions to support write, so very useful to explain why we're restricted to read. 07:58:44 fjh: in the Webkit mailing-list discussion, the basic question was "why do we need this API?", this would address that concern. 07:59:43 robin: also, we have a good use case against adding a new input type. I don't know if we should document it, but it may be worth bringing up the rationale for using or not using a new input type. 07:59:51 ... I can draft something. 08:00:17 ACTION: Robin to draft the design decision motivating using a new input type=foo or not for a given feature 08:00:17 Created ACTION-422 - Draft the design decision motivating using a new input type=foo or not for a given feature [on Robin Berjon - due 2011-07-26]. 08:00:42 bryan: we did have a significant discussion on declarative vs. Javascript. It makes sense to explain the rationale. 08:00:59 robin: it may be the same for difference specs. May be worth a one-pager document. 08:01:33 fjh: the problem is that we didn't want to put that in the document because it could take time for people to agree on such things. 08:01:59 robin: example of battery spec with different event names for different use cases. 08:02:16 fjh: anyone comfortable with writing that down? 08:02:29 robin: I think I already did that as part of the Webkit discussion. 08:02:35 https://lists.webkit.org/pipermail/webkit-dev/2011-July/017463.html 08:02:55 wonsuk: I'm happy to do that. 08:03:01 robin: excellent. 08:03:30 fjh: deadline? 08:03:39 wonsuk: in two weeks for next telcon? 08:03:42 ACTION: Wonsuk to draft the use cases and requirements section for Battery 08:03:42 Created ACTION-423 - Draft the use cases and requirements section for Battery [on WonSuk Lee - due 2011-07-26]. 08:03:49 fjh: ok. 08:04:24 robin: messaging is interesting because design changed 17 times... 08:04:37 ... We were just flushing out solutions to address use cases. 08:04:53 ... The more recent discussion sticks to the exact same use cases. 08:05:09 ... I think we're reaching a point where use cases are stable enough and can be document. 08:05:18 ... Let's action Dom! 08:06:03 ... We could ask Josh to contribute there. 08:06:28 fjh: actions are cheap and can be passed on, let's just give an action not to forget. 08:06:36 robin: true. 08:06:44 ACTION: Josh to draft the use cases and requirements for Messaging, perhaps even take over Messaging editing 08:06:44 Created ACTION-424 - Draft the use cases and requirements for Messaging, perhaps even take over Messaging editing [on Josh Soref - due 2011-07-26]. 08:08:10 fjh: I think we're basically done here. SysInfo to be addressed afterwards. 08:08:22 robin: want to do the same thing for the privacy doc? 08:08:37 fjh: no. I don't think it makes sense. Not sure how to proceed. I'll give some thoughts about it. 08:09:26 robin: NetInfo would be a useful one to have. 08:09:33 fjh: who's doing it? 08:09:40 robin: er... me. 08:09:56 ... I have an action item to do an editorial pass anyway, I guess I can do it. 08:10:09 ACTION: Robin to incorporate feedback for NetInfo, draft use cases and requirements section 08:10:09 Created ACTION-425 - Incorporate feedback for NetInfo, draft use cases and requirements section [on Robin Berjon - due 2011-07-26]. 08:10:34 bryan: back to the privacy document. The requirements doc contains use cases. 08:10:54 fjh: yes, I guess it could have more attack scenarios. I'm not sure how necessary that is. 08:11:02 ... It's pretty obvious in some ways. 08:11:46 bryan: if there is an intent to steal what's in the architectural approach, I think you can derive use cases but they're not use cases per se. 08:12:09 fjh: we have little use cases and then some requirements there. 08:12:37 bryan: the overall scope of the use cases for privacy are limited to things that happen on the device. 08:13:01 fjh: that's the problem, privacy is really end-to-end, restricting it to an endpoint doesn't work well. 08:13:29 bryan: DAP covers mainly use cases where the user interacts with the device. 08:13:54 fjh: I don't want to arbitrarily restrict what we could potentially do for privacy. 08:14:08 ... What you're suggesting is that we make it clear. I agree. 08:14:20 bryan: question more than suggestion. 08:15:00 ... Maybe use cases could help clarify what we're trying to achieve ref. privacy. 08:15:28 PIG drat charter: http://www.w3.org/2011/07/privacy-ig-charter 08:15:34 s/drat/draft/ 08:15:50 ... We don't know yet how use cases will affect privacy. 08:19:09 ACTION-340? 08:19:09 ACTION-340 -- Frederick Hirsch to look at how we're doing privacy by design -- due 2011-02-23 -- OPEN 08:19:09 http://www.w3.org/2009/dap/track/actions/340 08:19:09 robin: we're not expecting normative requirements. We're expecting design decisions. 08:19:27 ... We're not testing for privacy, we're testing for API design which is privacy-conscious. 08:21:13 fjh: no further comment on this? If not, break. 08:21:28 [break] 08:21:34 -Orange 08:21:43 -richt 08:21:44 UW_DAP(WGF2F)2:00AM has ended 08:21:46 Attendees were Orange, +44.208.144.aaaa, richt, +1.617.453.aabb 08:22:05 s/We don't know yet how use cases will affect privacy./Not clear how much we can achieve in DAP for privacy given the limited scope of DAP/ 08:43:13 jgiraud has joined #dap 08:43:21 Present+ jerome_giraud 08:47:40 Scribe: youenn 08:47:45 SrcribeNick: youenn 08:47:55 TOPIC: status of the battery API 08:47:58 Kangchan has joined #dap 08:50:47 Kangchan_ has joined #dap 08:51:27 ACTION-423? 08:51:27 ACTION-423 -- WonSuk Lee to draft the use cases and requirements section for Battery -- due 2011-07-26 -- OPEN 08:51:27 http://www.w3.org/2009/dap/track/actions/423 08:51:59 ScribeNick: youenn 08:52:08 youenn_ has joined #dap 08:52:08 s/SrcribeNick: youenn// 08:52:24 robinis going through the spec 08:52:54 s/robinis/robin is/ 08:53:13 ... discussions on disabling javascript animations when battery is low 08:53:15 http://dev.w3.org/2009/dap/system-info/battery-status.html 08:53:33 ... events to know whether device is plugged in 08:53:54 ... two issues are remaining 08:53:55 ISSUE-112? 08:53:55 ISSUE-112 -- Do we need to give an estimated time remaining indication with battery events? -- open 08:53:55 http://www.w3.org/2009/dap/track/issues/112 08:54:02 ... Issue 112 first 08:54:24 ACTION-418? 08:54:24 ACTION-418 -- Josh Soref to formulate the use cases he sees for timeRemaining, and if possible an implementation strategy for when that information isn't provided by the OS -- due 2011-07-06 -- OPEN 08:54:24 http://www.w3.org/2009/dap/track/actions/418 08:54:25 ... Should the batter API has an indicator for the remaining time before the battery runs out 08:54:39 s/batter API/battery API/ 08:57:14 youenn has joined #dap 08:57:34 robin: proposal to close 112 without adding this value 08:58:07 robin: if we publish the spec and get feedback requesting this flag, then we can add it in v2 08:58:17 ... feel safer to ship without it 08:58:27 francois: what is the UC? 08:58:37 s/flag/time remaining / 08:58:56 robin: use case is 10 minute video watching and you want to know whether you will be able to play the video until the end 08:59:29 cmarc has joined #dap 08:59:45 ... alos based on time remaining, an app may want to commit resources earlier or not. 08:59:59 ... But changing the behaviour will change the remaining time 09:00:03 close issue-112 09:00:03 ISSUE-112 Do we need to give an estimated time remaining indication with battery events? closed 09:00:09 robin: objection to close 112? 09:00:16 No objection 09:00:22 issue-113? 09:00:22 ISSUE-113 -- AddEventListener in Battery Status has side effects -- open 09:00:22 http://www.w3.org/2009/dap/track/issues/113 09:00:30 ISSUE-112: closed given that this could be added to subsequent release if needed after getting additional feedback 09:00:30 ISSUE-112 Do we need to give an estimated time remaining indication with battery events? notes added 09:00:49 robin recaps the issue 09:00:57 http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0070.html 09:01:36 issue about event registration having side effect 09:01:42 ... or not 09:02:12 robin: not entirely convinced by this argument since registration always changes something, example with mutation event 09:02:58 all reading dom mail 09:03:20 robin: this is directly from implementors (apple, opera) 09:04:52 ... difference between onmessage and addEventListener is not clear. Why should event firing happen in one case and not in another? 09:05:26 http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0070.html 09:06:26 lgombos : need for specialization of addEventListener? 09:07:00 ... will we need to keep firing the event even if the web page is closed? 09:07:10 robin: same problem as device orientation. 09:07:34 ... no constraint on event firing granularity 09:07:59 ... no provision for stopping event firing when page is closed. 09:08:25 lgombos: maybe this should be applicable when registering the listener 09:08:48 fjh: Is it an implementation issue? 09:09:05 robin: we have the same design as device orientation. 09:09:32 ... Either we have a solution for it or we have a good reason to ignore it if we want to go further 09:10:14 [ Side note that both "batterylow" and "batterycritical" condition definitions are left to the implementation. Shouldn't the spec still say that "batterylow" needs to fired up before "batterycritical"? ] 09:10:27 robin: I could review the thread with the new progress from last week and get back to this topic later 09:11:15 fjh: LC may be also a good way to get feedback on this issue 09:12:00 close ACTION-418 09:12:00 ACTION-418 Formulate the use cases he sees for timeRemaining, and if possible an implementation strategy for when that information isn't provided by the OS closed 09:12:22 bryan: the text in the mail is not in sync 09:12:27 .. with the spec 09:13:29 ernesto: the problem is that the spec states that when registering the event, you need to send an event. It does need to be immediate. 09:14:25 jgiraud: what about adding a flag to request for having an immediate event? 09:14:50 robin: we avoid synchronous as much as we can. But this is certainly an option. 09:15:26 ... another approach is to add a function to request events from now on 09:16:14 francois: there is nothing in the spec that battery low is before battery critical 09:16:21 ... ordering should be stated 09:17:24 ISSUE: battery spec should note relative ordering of battery low versus battery critical in terms of criticality 09:17:24 Created ISSUE-114 - Battery spec should note relative ordering of battery low versus battery critical in terms of criticality ; please complete additional details at http://www.w3.org/2009/dap/track/issues/114/edit . 09:17:27 ernesto: what happens when you charge the battery and go from critical to low 09:17:58 ISSUE: do you get the batterylow event when you're charging and cross that boundary? 09:17:58 Created ISSUE-115 - Do you get the batterylow event when you're charging and cross that boundary? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/115/edit . 09:18:41 ACTION: François to craft a sentence for ISSUE-114 09:18:41 Sorry, couldn't find user - François 09:19:29 robin: do we know what do implementations? 09:20:09 ernesto: in the case of disabled animations, you may want to wait before reenabling the animations when charging 09:21:05 robin: the application may decide when receiving the charging event. 09:23:30 francois: what about when you are already low? 09:23:55 robin: maybe going with one event and not 3 may be a better approach 09:24:05 bryan: do we know what means low and critical? 09:24:33 robin: this is implementation dependent. We hope that similar OSes will give similar answers for the same platform. 09:25:07 ... for different platforms, the same OS may have different answers (kindle/iphone example) 09:25:44 bryan: it may be simpler to not do any distinction between low and critical 09:26:34 robin: semantics of low and critical are quite different. 09:27:49 ernesto: most systems already have the numbers that define low/critical 09:28:53 josh arrived 09:29:53 robin: some concerns about the low/critical semantics, possibility to redesign with one event 09:30:13 ... may not be ready for LC 09:33:27 discussions about why the current design and new proposed design 09:33:52 richt has joined #dap 09:34:08 lgombos: do we have a float attribute for battery level? 09:34:15 robin: yes, a nullable float 09:34:38 proposal would be to add a third attribute. 09:34:54 ACTION: Robin to draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical 09:34:54 Created ACTION-426 - Draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical [on Robin Berjon - due 2011-07-26]. 09:36:35 READ THIS THREAD: http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/thread.html#msg9 09:37:25 TOPIC: Privacy BP 09:37:45 fjh: I created a first draft 09:38:00 ... dom had some comments 09:38:14 http://dev.w3.org/2009/dap/privacy-practices/ 09:38:29 ... tried to deal with all comments together 09:39:01 ... Examples are still missing 09:39:13 ... it seems to be in a state where we can publish it 09:39:28 bryan: focus is on developers practices or implementations? 09:39:45 fjh: those who create web pages that use these APIs 09:40:07 fjh: privacy goes beyond the APIs 09:42:31 bryan: developers like concrete information. Should we add links to particular technologies? example of encryption with https 09:43:30 Zakim has left #dap 09:43:44 robin: should get some feedback from accessibility people. They have real experience with outreach documents, targeted at developers. 09:44:19 ... would be good to contact the people from WAI 09:45:24 bryan: would be good to have something that test the conformance of a web site. 09:45:36 fjh: it seems premature 09:46:49 fjh: would prefer to publish this first WD and get feedback sooner. 09:50:50 discussions about the short name of the document 09:51:33 shortname - sp-privacy-practices 09:51:43 sp-privacy-bp 09:51:56 service-privacy-bp 09:52:17 app-privacy-bp 09:52:21 bryan: +1 for bp for consistency 09:54:51 proposed RESOLUTION: use short name app-privacy-bp for app privacy best practices, update document title to Application Privacy Best Practices, publish FPWD 09:55:16 RESOLUTION: use short name app-privacy-bp for app privacy best practices, update document title to Application Privacy Best Practices, publish FPWD 09:55:51 Re developer guidance and app testing, some more concrete guidance would be good to include, for methods / technologies etc for adherence to best practices. In the MWI (http://www.w3.org/Mobile/) MWBP (http://www.w3.org/TR/mobile-bp/) and MWABP (http://www.w3.org/TR/mwabp/) for example there were concrete examples ("what it means" and "how to do it" info) and a compliance framework supporting application adherence testing (http://validator.w3.org/mobile/). 09:56:01 Josh_Soref has joined #dap 09:56:04 [you might want the title to be "Web Application" rather than "Application"] 09:56:36 [FWIW, the doc extends the privacy bp we had in Mobile Web Application Best Practices: http://www.w3.org/TR/mwabp/#bp-inform-personalinfo ] 09:56:41 +1 to title change 09:58:50 action: fjh to prepare web app best practices for FPWD publication, including title change, shortname change, and adding reference to MWBP 09:58:50 Created ACTION-427 - Prepare web app best practices for FPWD publication, including title change, shortname change, and adding reference to MWBP [on Frederick Hirsch - due 2011-07-26]. 10:00:12 http://www.w3.org/2001/tag/doc/APIMinimization.html 10:01:21 close ACTION-365 10:01:21 ACTION-365 Help raise the COW closed 10:09:49 BREAK 11:04:18 Cathy has joined #dap 11:10:47 Cathy has joined #dap 11:11:25 Present+ Cathy_Chan 11:12:09 I plan to phone in when the meeting resume after lunch. 11:29:03 SungOk_You has joined #dap 11:31:09 ernesto_jimenez has joined #dap 11:34:29 rrsagent, generate minutes 11:34:29 I have made the request to generate http://www.w3.org/2011/07/19-dap-minutes.html fjh 11:40:01 zakim, code? 11:40:44 zakim, who is here? 11:41:06 robin has joined #dap 11:41:14 trackbot: start meeting 11:41:16 RRSAgent, make logs world 11:41:16 Zakim has joined #dap 11:41:18 Zakim, this will be DAP 11:41:18 ok, trackbot; I see UW_DAP(WGF2F)2:00AM scheduled to start 341 minutes ago 11:41:19 Meeting: Device APIs and Policy Working Group Teleconference 11:41:19 Date: 19 July 2011 11:41:24 wonsuk has joined #dap 11:42:12 Zakim, code? 11:42:12 the conference code is 94323 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Josh_Soref 11:42:22 UW_DAP(WGF2F)2:00AM has now started 11:42:26 lgombos_ has joined #dap 11:42:29 +Orange 11:42:30 francois has joined #dap 11:42:43 present+ Ingmar_Kliche 11:42:44 shan_ has joined #dap 11:43:06 Present+ Josh_Soref 11:43:10 Present+ Wonsuk_Lee 11:43:16 RRSAgent, make minutes 11:43:16 I have made the request to generate http://www.w3.org/2011/07/19-dap-minutes.html Josh_Soref 11:44:30 cmarc has joined #dap 11:44:48 Cathy_ has joined #dap 11:45:41 bryan has joined #dap 11:45:53 Cathy_ has joined #dap 11:45:53 zakim, who is here? 11:45:53 On the phone I see Orange 11:45:54 On IRC I see Cathy_, bryan, cmarc, shan_, francois, lgombos_, wonsuk, Zakim, robin, ernesto_jimenez, SungOk_You, Cathy, Josh_Soref, richt, ceyrigno, Youngsun, Johnson, Kihong_Kwon, 11:45:57 ... RRSAgent, fjh, lgombos, ilkka, ingmar, dom, trackbot 11:46:29 scribenick: bryan 11:46:45 kyungtak has joined #dap 11:46:49 Present+ Cecile_Marc 11:47:18 Present+ Cathy_Chan 11:48:08 Cathy has joined #dap 11:48:15 Present+ Cathy_Chan 11:48:45 + +1.781.266.aaaa 11:48:56 zakim, aaaa is Cathy 11:48:56 +Cathy; got it 11:49:30 Jun: today Canon is only observing the meeting, and will leave earlier 11:49:47 +richt 11:50:02 Present+ Rich_Tibbett 11:50:04 s/earlier/earlier [i.e. before the end of today's meeting]/ 11:50:27 ... Fujisawa-san (SVG WG), Shibayawa-san (AC Rep), Youenn Fablet (EXI, SOAP, WSDL) 11:51:29 ... Canon is very interested in DAP. Device APIs should not be limited to smartphones, but should be open to other devices as well 11:51:40 ... such as cameras, printers, etc. 11:52:04 ... we have no current product plan, but are very interested in contributing to this group in order to create and standardise new APIs 11:52:25 youenn has joined #dap 11:52:27 ... for example, we are interested in UCs involving TV, printer, etc working together in the home network 11:52:34 ... and very interested in Discovery 11:53:05 ... so we are working on joining the group, but need to wrap up on EXI first, so will join inside of a year 11:53:38 ... we have been working with Robin on SVG and EXI and are looking forward to working again with him on DAP 11:54:06 fjh: is there any reason for waiting before joining? Perhaps participating at a lower level first and increasing it later when EXI is wrapped up 11:54:35 ... there is an advantage to joining earlier in contributing 11:55:04 Shibayama-san: we have to work with the internal process 11:55:18 josh: so it's mostly the internal process rather than waiting for EXI 11:55:33 Shibayama-san: yes, and we need to assign personnel 11:55:41 zakim, who is here? 11:55:41 On the phone I see Orange, Cathy, richt 11:55:42 On IRC I see youenn, Cathy, kyungtak, bryan, cmarc, shan_, francois, lgombos_, wonsuk, Zakim, robin, ernesto_jimenez, SungOk_You, Josh_Soref, richt, ceyrigno, Youngsun, Johnson, 11:55:45 ... Kihong_Kwon, RRSAgent, fjh, lgombos, ilkka, ingmar, dom, trackbot 11:56:16 Topic: Contacts LC feedback 11:56:19 Present+ Kihong_Kwon 11:58:01 DAP Last Call tracker is here: http://www.w3.org/2006/02/lc-comments-tracker/43696/ 11:58:12 robin: want to process LC feedback. Which feedback items are substantive (not editorial) and important? 11:59:06 richt: internationalization is a large concern. Should take other emails in turn. 11:59:35 fjh: we will enter issues as we go 12:00:10 richt: first is contacts fields (whether they should be URLs or not). First is photo field. 12:00:11 actual tracker for contacts: http://www.w3.org/2006/02/lc-comments-tracker/43696/WD-contacts-api-20110616/ 12:00:37 http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0024.html 12:01:18 issue-111? 12:01:18 ISSUE-111 -- Should (some of the) ContactField objects use URLs rather than free-form strings? -- pending review 12:01:18 http://www.w3.org/2009/dap/track/issues/111 12:01:20 jun has joined #dap 12:01:27 close issue-111 12:01:27 ISSUE-111 Should (some of the) ContactField objects use URLs rather than free-form strings? closed 12:02:45 richt: bug in the WebIDL for the caller attribute. 12:02:59 http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0106.html 12:03:10 robin: it hasn't been fixed yet 12:03:46 http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0000.html 12:03:55 richt: applies also to calendar API. Need to remove Caller. 12:04:40 richt: problem with the example. No response received, just needs an editorial correction. 12:07:49 josh: why is there a nointerfaceobject attribute in the WebIDL? 12:08:06 robin: because we don't want an interface object 12:08:23 richt: so you can't do typeof on the interface 12:09:19 richt: if you don't put the attribute, then an interface object is defined for the window which would not be correct 12:09:24 [actually instanceof] 12:11:25 robin: the example comment was that the example looks like a multiple find case, but the boolean for multiple defaults to false. 12:11:34 youenn has joined #dap 12:12:06 I'd suggest having two examples 12:12:09 one for each case 12:12:10 richt: In the example, multiple needs to be true, or we change it to a single contact returned. 12:12:25 robin: as editorial, left up to richt 12:12:30 they're both useful and it's better to walk people through how to use them 12:13:10 http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0001.html 12:13:23 [ robin added multiple: true to the options, making the comment correct ] 12:14:46 richt: next is about privacy. The privacy requirement should be non-normative. Richt agrees. Not quite clear how to do it though. Happy with it as it is, so may reject this comment. 12:15:05 robin: we should be fine with the language as-is 12:15:58 robin: there are MUSTs that we cannot test for, and thus should be SHOULDs 12:16:30 richt: MAYs and SHOULDs. Robin to make the changes. 12:17:18 q+ to make sure is stricken 12:17:37 richt: the section is really guidelines. We should maybe make the section non-normative in general and make the SHOULDs etc lower case. 12:17:56 [change applied MUST -> SHOULD] 12:18:38 fjh: the recommendations should not get buried in the guideline, even if not testable. In this case the RFC language is about testing code, and this is different. 12:19:39 bryan: SHOULD should also be tested, as the only "out" is technical limitation 12:19:57 update list of comments, http://www.w3.org/2006/02/lc-comments-tracker/43696/WD-contacts-api-20110616/ 12:20:19 fyi, Testing and RFC 2119 discussion is here: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0351.html 12:20:39 bryan: we should not use the RFC 2119 language if this is not intended to be tested or normative 12:21:00 josh: should be lower-case shoulds 12:21:01 [change applied] 12:21:15 next issue: http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0005.html 12:21:45 richt: next is coordination on address interfaces with geolocation 12:22:08 richt: want to get to the same address interface as geolocation 12:22:24 robin: this requires major rewiring 12:22:40 richt: this affects existing implementations and conformance of them 12:23:01 Geolocation v2 address api: http://dev.w3.org/geo/api/spec-source-v2#address_interface 12:23:40 robin: we need a core object for the properties and two different interfaces for the different API usages 12:24:17 richt: we could use inhertance 12:24:52 josh: multiple inheritance is a risk 12:25:24 robin: no one "owns" address at this point, and we can coordinate with geolocation on its definition 12:25:57 josh: would prefer two different interfaces - also nointerfaceobject is used here too which is incorrect or unnecessary 12:27:01 josh: the impact to existing implementations is important 12:27:25 robin: sent an email earlier on the differences 12:28:01 http://lists.w3.org/Archives/Public/public-device-apis/2011May/0052.html 12:28:10 richt: seems to be a general feeling that DAP Contacts should change, due to implementations in the wild 12:28:33 robin: geolocation V1 implementations are not impacted 12:29:02 josh: no address field beyond coordinates is defined in V1 12:29:29 josh: V2 is still at editor's draft 12:30:21 josh: what are the use cases, e.g. can I ask for the coordinates of the address? 12:31:43 richt: take examples, e.g. Japanese or from Oslo, they are going to be very different and not fit into the geolocation definition. Also the names e.g. county and city are problematic. 12:32:00 richt: of the two proposals, I would recommend the DAP one. 12:32:51 robin: no one will have a perfect solution. We have a strict requirement to align with portable contacts, which geolocation agree (is a requirement on DAP, but not geolocation) 12:33:37 josh: can provide feedback based upon input to be provided to geolocation 12:33:45 s/of the address/of an address/ 12:34:17 robin: will make a proposal based upon DAP Contacts 12:34:29 ACTION: Robin to make a proposal for a common Address interface for Geo/Contacts that keeps Contacts aligned with PoCo, provides a base class, shows how Geo could derive on its side 12:34:30 Created ACTION-428 - Make a proposal for a common Address interface for Geo/Contacts that keeps Contacts aligned with PoCo, provides a base class, shows how Geo could derive on its side [on Robin Berjon - due 2011-07-26]. 12:34:47 DKA has joined #dap 12:34:52 richt: we should have one W3C address interface. We need Geolocation to continue to discuss this. 12:35:35 fjh: since the usage is different, and we can have two different interfaces, why do we need to align 12:35:42 [note to robin: there's one remaining SHOULD in section 3. Is that intended? Plus flag section 3.1 (or the whole section 3 is last SHOULD gets removed) as non-normative? Only 3.2 and 3.3 are flagged as such right now.] 12:36:10 richt: the usage of the address will overlap and thus it needs to be consistently defined 12:36:28 next issue: http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0007.html 12:36:39 [thanks, oversight!] 12:37:28 richt: next issue, it's not clear from the specification how to use name.formatted, displayName and nickName properly 12:37:43 richt: we don't have clear rules for this 12:37:54 robin: could we link to the POCO rules? 12:38:55 robin: is what POCO did I18N friendly? 12:39:16 josh: they recently published a draft discussing this, which we can take as input 12:39:55 [ http://www.w3.org/International/questions/qa-personal-names ] 12:40:16 robin: suggest way forward is to reference POCO rules unless its I18N un-friendly 12:40:34 s/its/it's/ 12:40:47 [ the assumption is that it probably is unfriendly, but... ] 12:40:49 ACTION: Josh to figure out if the PoCo handling of personal names is okay under I18N rules 12:40:49 Created ACTION-429 - Figure out if the PoCo handling of personal names is okay under I18N rules [on Josh Soref - due 2011-07-26]. 12:41:24 zakim, who is here? 12:41:24 On the phone I see Orange, Cathy, richt 12:41:25 On IRC I see DKA, youenn, jun, Cathy, kyungtak, bryan, cmarc, shan_, francois, lgombos_, wonsuk, Zakim, robin, ernesto_jimenez, SungOk_You, Josh_Soref, richt, ceyrigno, Youngsun, 12:41:28 ... Johnson, Kihong_Kwon, RRSAgent, fjh, lgombos, ilkka, ingmar, dom, trackbot 12:43:04 richt: we could make structured read-only 12:43:29 s/we could make structured read-only/we could make 'formatted' read-only/ 12:45:14 robin: why are we keeping formatted (from PoCo)? 12:45:24 richt: it's well represented in Vcard as well 12:45:31 robin: is it required in either? 12:45:59 [ http://portablecontacts.net/draft-spec.html ] 12:46:36 richt: think its required in PoCo. I18N compliance is worrying though. We could drop it also. 12:46:49 josh: would recommend dropping it 12:46:55 richt: agree 12:47:19 richt: dropping formatted only on the name 12:48:06 [ note that FN in vCard 3.0 is Formatted Name -- http://en.wikipedia.org/wiki/VCard ] 12:48:21 robin: on address it's easier, just need the rules for each country, which do have standards. but fine with dropping it on address also if it makes coordination with geolocation easier. 12:49:51 RESOLUTION: 'formatted' removed 12:50:40 ingmar: are we required to have another LC on Contacts? 12:51:01 robin: yes, as soon as a change affects implementations a new LC is required 12:52:17 skipping the I18N issues for now... next issue: http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0021.html 12:52:52 q? 12:53:03 richt: editorial issues 12:53:09 ack me 12:53:09 Josh_Soref, you wanted to make sure is stricken 12:53:15 josh: skip it for now 12:53:16 q+ to make sure is stricken 12:54:43 http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0056.html 12:55:39 http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0083.html 12:56:36 richt: More of a design question "Implementation issue of most of device API on the Webkit" 12:57:35 richt: webkit is pushing back on Calendar and Contacts, requiring changes (e.g. URL-based approach). 12:58:29 robin: this is an issue we have discussed before. Resolution was to develop the APIs using WebIDL and to decide at LC whether to define a REST-based binding or stick with Javascript. 12:59:27 robin: it's possible, but there is no defined way to generate REST binding from WebIDL 13:00:11 robin: we would also prefer to give developers one design path to use the API 13:01:48 josh: Javascript can't manipulate the chrome, and that makes it difficult for vendors to implement 13:02:06 richt: where are we with WebIDL to REST binding? 13:02:35 robin: have some prototype code, but in the last year not much development has occurred 13:03:00 fjh: isn't there expectation of developers to use Javascript? 13:04:12 robin: the conclusion last time was that both are used and familiar, and that we can use libraries to bridge the gaps (at least one direction) 13:04:43 richt: Adam Barth is saying we should do this as a REST-based API 13:05:18 robin: we can publish the binding as a note. But there are a lot of details. 13:05:47 agreed there are a lot of details but I have faith in you Robin (and I'm willing to help where possible ;)) 13:06:10 josh: are there no loops in the objects, e.g. friends 13:06:14 robin: no 13:06:51 s/no/correct, there are no loops/ 13:07:57 robin: if we address the REST case, we will lose 6 months on the REC track 13:08:09 rest approach applicable to pim apis, not necessarily event based like battery 13:08:48 HTTP binding would probably assume a different security model as well (e.g. CORS) 13:10:16 bryan: REST brings in the same-origin policy etc 13:10:23 robin: the browser can white-list certain URLs 13:10:55 e.g. when received from Web Introducer 13:11:02 q? 13:11:18 moving on to the next issue? 13:11:35 bryan: would this imply implementations would not need to support the Javascript binding? 13:12:38 robin: wrapping a JS lib around an HTTP API is overall much easier than emulating an HTTP API atop a JS API (even if it's possible by screwing with XHR) 13:12:39 ack josh_soref 13:12:39 Josh_Soref, you wanted to make sure is stricken 13:12:53 next issue: http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0115.html 13:13:23 richt: next issue, "Specs need to avoid demanding UIs show URIs to users (especially as a "security" measure)" 13:14:06 josh: users don't "get" URIs - everyone is moving away from depending upon user interpretation of URIs 13:14:27 josh: thus it's a bad idea to show URIs to users 13:15:01 richt: it's a bad idea NOT to show the URI rather, e.g. for iframes 13:15:38 josh: the current spec calls for showing the whole URI 13:15:45 robin: all done on non-I18N issues 13:16:27 fjh: people share URIs etc 13:16:28 josh: but also to trick people 13:17:07 josh: just because foo.com is trusted it doesn't prevent delivery of the location to any other origin 13:17:29 richt: it has been downgraded already to SHOULD 13:18:03 josh: SHOULD limits to good technical reasons, and they do existin e.g. inability to display the URI 13:18:43 you've shifted your trust from being enforced by URL to the browser implementing the correct dialogs. It's a solution with an added problem (try requesting geoloc in an iframe within FF or Chrome...oops) 13:18:53 but anyway, it's SHOULD now in the spec. 13:19:15 josh: browser vendors will figure it out 13:19:49 bryan: this is also being worked on for privacy, e.g. the icons as discussed in the W3C privacy workshop in London 13:20:15 josh: it's better to let the browser vendors compete on implementation 13:21:44 fjh: so there should be a general requirement on a means for the user to confirm trustworthiness etc, and not get more specific 13:22:12 bryan: it's premature to get too specific on the UI 13:24:51 proposal - replace "The user interface must include the document base URL. " to "The user interface should allow the user to verify trust in the web application, one possibility is to display the document base URL" 13:24:56 bryan, check out how browsers do geolocation requests in full-screen for example. 13:25:00 ...for chromeless operation. 13:25:15 allow => try to enable 13:25:28 -richt 13:58:55 Zakim, who's on the phone? 13:58:55 On the phone I see Orange, Cathy 13:59:55 +richt 14:00:35 robin: I18N issues next 14:01:20 http://www.w3.org/mid/E1Qdoe8-0006HN-Vf@stu.w3.org 14:01:41 "It isn't clear if the find() method is case sensitive or not. Section 5, which talks about "Contact Search Processing" uses the term "match" without closely defining what constitutes a match. We think case sensitivity of the find() method and search processing in general should be defined." 14:02:20 first I18N Contacts issue: I18N-65 http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0020.html 14:02:27 robin: Issue 65 from I18N "It isn't clear if the find() method is case sensitive or not." 14:03:59 richt: processing rules have been removed recently 14:04:57 the solution to this issue is probably in: http://www.w3.org/mid/1309870066.1774.285.camel@altostratustier 14:05:04 robin: the rules were removed for good reasons. We just expect the result to be passed back as-is. 14:06:18 [ http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0054.html ] 14:07:14 search request hint passed to back end without additional processing 14:07:43 PROPOSED RESOLUTION: rename 'match' argument to 'hint' 14:08:05 RRSAgent, where am I? 14:08:05 See http://www.w3.org/2011/07/19-dap-irc#T14-08-05 14:09:30 [ http://dev.w3.org/2009/dap/contacts/#search-filters ] 14:09:32 So we don't want to re-instate ANY of the following? http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html.diff?r1=1.125;r2=1.126;f=h 14:09:37 PROPOSED RESOLUTION: rename 'filter' argument to 'hint' 14:09:58 robin: the text refers to this as a hint already, so we should be covered 14:10:28 josh: feedback was that hint would be better than filter 14:11:15 Comparing two strings in a compatibility caseless manner means using the Unicode 14:11:15 compatibility caseless match operation to compare the two strings. [[!UNICODE]] 14:11:16 e.g. bring back '' 14:11:41 that came out wierd :) 14:13:26 richt: we could restore from the change log, the description of case handling without getting to specific on how 14:14:19 another quote we could re-instate: "A partial value match refers to both syntactic and semantic partial matching of an input filter value with a corresponding value in the address book and denotes that a corresponding match was found in the address book that begins with, contains or ends with the value of the input filter value, or any variation thereof." 14:15:05 ernesto_jimenez_ has joined #dap 14:16:02 ACTION: josh to provide sample input with potential outputs. 14:16:03 Created ACTION-430 - Provide sample input with potential outputs. [on Josh Soref - due 2011-07-26]. 14:17:03 robin: I think that the spec should do nothing, because we don't have control of how the contacts db backend implements search 14:17:18 ACTION-430: related to search fields in contacts, and use of hint with case sensitivity or not, fuzzy match etc 14:17:19 ACTION-430 Provide sample input with potential outputs. notes added 14:17:19 bryan_ has joined #dap 14:17:28 ... in many implementations it'll be fuzzy and case insensitive (according to whatever internal rules) and the UA can't change that 14:17:47 rrsagent, generate minutes 14:17:47 I have made the request to generate http://www.w3.org/2011/07/19-dap-minutes.html fjh 14:17:55 scribenick: bryan_ 14:19:21 robin: this one we can't do anything about 14:19:53 josh: is there a away to say there are no implementation constraints? 14:19:56 s/you're/your/ 14:20:00 s/no/known/ 14:20:38 robin: examples will clarify the spec - propose to include Josh's examples and explain to I18N why we can't do more 14:20:49 sounds good to me. 14:21:16 RESOLUTION: to include Josh's examples and explain to I18N why we can't do more 14:21:40 RRSAgent, where am I? 14:21:40 See http://www.w3.org/2011/07/19-dap-irc#T14-21-40 14:21:55 http://www.w3.org/mid/E1Qdoy0-0000TO-Ca@barney.w3.org 14:22:33 robin: next issue I18N-66 "I18N-ISSUE-66: find() method sensitivity to Unicode normalization [Contacts API]" 14:22:33 proposed reply to this one: http://www.w3.org/mid/10FB5B63-B7A4-4FEF-B8E8-F9D46DC82E4D@berjon.com 14:22:52 robin: essentially the same answer as the last one 14:23:03 may have to wrap my head around these two issues. will wait for Josh's response on list. 14:23:27 PROPOSED RESOLUTION: rename 'filter' argument to 'hint' 14:23:43 [ repeated because scribe lost connection before pasting ] 14:23:46 RESOLUTION: rename 'filter' argument to 'hint' 14:25:54 robin: for I18N-66 we can't do anything. reading the guidelines published we are doing the right thing. so we should adopt the reply prosposed 14:27:02 PROPOSED RESOLUTION: to adopt the reply http://www.w3.org/mid/10FB5B63-B7A4-4FEF-B8E8-F9D46DC82E4D@berjon.com for issue I18N-66 14:27:49 robin: if we pass a string to a backend that uses a different normalization, there's no guarantee the strings will match anyway 14:27:53 josh: we can't ask the backends to change 14:28:31 alternate PROPOSED RESOLUTION: No changes to be made, as search is not implemented by UA, backend may or may not perform normalization and may or may not match normalized input. Adopt reply http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0036.html 14:28:37 richt: so the issue isn't ours, its the back-end implementations 14:28:46 s/its/it's/ 14:28:59 RRSAgent, where am i? 14:28:59 See http://www.w3.org/2011/07/19-dap-irc#T14-28-59 14:28:59 RESOLUTION: to adopt the reply http://www.w3.org/mid/10FB5B63-B7A4-4FEF-B8E8-F9D46DC82E4D@berjon.com for issue I18N-66 14:29:07 I18N-ISSUE-67: http://www.w3.org/mid/E1Qdoza-0000US-Qe@barney.w3.org 14:29:41 I18N-ISSUE-68: http://www.w3.org/mid/E1Qdp3g-0006Vd-5J@stu.w3.org 14:30:01 robin: next I18N-67 is typos 14:31:15 robin: I18N-68 is unclear "document doesn't define a specific version supported by the API. Version 2.1 included a CHARSET type parameter that version 3.0 eliminates. " 14:32:16 robin: we have asked for clarification and are waiting. If they are talking about VCard it's not our problem., because we don't implementation serialization to VCard ourselves. 14:32:29 I18N-ISSUE-69: http://www.w3.org/mid/E1Qdp9i-0002gA-KU@lowblow.w3.org 14:32:58 would like to see these as extensions. vcard uses X-PHONETIC-FIRST-NAME and X-PHONETIC-LAST-NAME 14:33:07 RE: I19N-ISSUE-69 14:33:23 robin: issue I18N-69 "Support for reading/phonetic/pronunciation fields [Contacts API]" 14:34:07 robin: entirely agree this is needed, but if the lower-level things don't support it, there is no way we can support it. 14:34:10 my response: http://www.w3.org/mid/D148D14B-1F53-4161-B916-A9B236A95A4D@berjon.com 14:34:32 richt: VCard has this as extensions, so happy to keep it at extensions 14:35:13 josh: the I18N ask is supportable via the displayName field 14:36:10 robin: extension fields in VCard are unreliable. this needs to be supported first in VCard (as more than an extension). 14:36:51 proposed response: WG considers first obtaining standard for defining these fields in vCard so API could interact with meaningful con 14:37:05 RRSAgent, where am I? 14:37:05 See http://www.w3.org/2011/07/19-dap-irc#T14-37-05 14:37:07 robin: VCard has a sound field, but you can't sort on a sound field 14:38:04 s/meaningful con/meaningful content/ 14:38:11 I18N-ISSUE-70: http://www.w3.org/mid/E1QdpIP-0000f6-6w@barney.w3.org 14:38:27 RE: I18N-70: IMO multiple family names should be placed in the familyName field 14:38:44 RESOLUTION: to adopt Robin's response http://www.w3.org/mid/D148D14B-1F53-4161-B916-A9B236A95A4D@berjon.com 14:39:00 my response: http://www.w3.org/mid/BBA5DAFB-B25E-4737-8A32-80BE68BC765E@berjon.com 14:39:16 robin: next issue I18N-70 "Support multiple family names [Contacts API]" 14:40:34 robin: people can have multiple family names, but different punctuation is used. simpler is to use a single string with multiple names. 14:41:46 PROPOSED RESOLUTION: to adopt Robin's response http://www.w3.org/mid/BBA5DAFB-B25E-4737-8A32-80BE68BC765E@berjon.com 14:43:03 RESOLUTION: to adopt Robin's response http://www.w3.org/mid/BBA5DAFB-B25E-4737-8A32-80BE68BC765E@berjon.com 14:43:05 RRSAgent, where am i? 14:43:05 See http://www.w3.org/2011/07/19-dap-irc#T14-43-05 14:43:13 I18N-ISSUE-71: http://www.w3.org/mid/E1QdpQ1-0006hk-6x@stu.w3.org 14:43:15 RE: I18N-71: we can add the proposed text to the spec. 14:43:49 robin: next issue I18N-71 "clarify culturally-linked references to name position [Contacts API]" 14:44:28 maybe we should use some more I18N names in the spec's examples. 14:44:31 ...as suggested 14:44:39 robin: largely editorial, may have been addressed. the feedback is that family name is referred to as last name. this varies in different cultures 14:45:03 fyi, this has already been fixed in the spec. 14:45:21 http://www.w3.org/TR/contacts-api/#widl-ContactName-familyName 14:45:24 josh: agree with the complaint , but not their proposed change 14:46:54 bikeshedding? maybe we can change familyName to historicTitleThatEvolvedFromTheNameMyAncestorsChose. Good? 14:48:53 +1 to richt's suggestion, if it can be made longer 14:49:03 > This attribute contains the family name (also referred to as the last name) of this Contact. 14:49:11 bryan: :) 14:49:26 PROPOSED RESOLUTION: Change that line to: "This attribute contains the family name (also referred to in American English as the last name) of this Contact." 14:49:47 fjh: after discussion, the only problem is how to map to what is used in the US, e.g. last/first 14:49:57 PROPOSED RESOLUTION: Change "This attribute contains the family name (also referred to as the last name) of this Contact." to: "This attribute contains the family name (also referred to in American English as the last name) of this Contact." 14:50:18 [for the "There is no such thing as US English" reference: http://urbanlegends.about.com/library/blrevocation_cleese.htm] 14:50:33 teehee. on american passports it says 'Surname'. 14:50:38 RESOLUTION: Change that line to: "This attribute contains the family name (also referred to in American English as the last name) of this Contact." 14:50:55 RESOLUTION: same as above for "first name" 14:51:35 RRSAgent, where am I? 14:51:35 See http://www.w3.org/2011/07/19-dap-irc#T14-51-35 14:52:24 "s/also referred to as/also referred to in American English as/" 14:53:45 fjh: should we send an official reply now? 14:54:15 Last call tracker info - http://www.w3.org/2006/02/lc-comments-tracker/43696/WD-contacts-api-20110616/ 14:54:18 robin: we should check the list and formulate a response 14:54:32 fjh: done that, we can review them 14:55:38 all: thanks for all your help in reviewing all that Contacts feedback. Appreciated :) 14:57:53 robin: testing discussion will be first thing in the morning 14:58:07 Recess 14:58:09 RRSAgent, draft minutes 14:58:09 I have made the request to generate http://www.w3.org/2011/07/19-dap-minutes.html francois 15:00:08 -Cathy 15:00:35 see you tomorrow. 15:00:51 -richt 15:01:21 thanks richt, see you in the morning! 15:01:29 oh, I spoke too soon :) 15:01:41 hey, you're only getting wise-cracks because we can't do phone-beer! 15:02:58 s/hi all. are you guys set up?// 15:36:07 -Orange 15:36:08 UW_DAP(WGF2F)2:00AM has ended 15:36:10 Attendees were Orange, +1.781.266.aaaa, Cathy, richt 16:16:47 Zakim has left #dap