01:00:20 sicking has joined #dap 01:02:38 npdoty has joined #dap 04:54:41 hta has joined #dap 06:00:52 tomoyuki has joined #dap 06:21:22 kensaku has joined #dap 06:55:09 darobin has joined #dap 07:02:11 Hidetoshi has joined #dap 07:17:02 Hidetoshi has joined #dap 07:18:45 hta has joined #dap 07:27:27 kotakagi has joined #dap 07:29:25 kotakagi has joined #dap 07:30:41 Hidetoshi has joined #dap 07:36:09 tomoyuki has joined #dap 07:42:24 Hidetoshi has joined #dap 07:42:36 Yoshiharu has joined #dap 07:42:46 shan has joined #dap 07:42:48 kensaku has joined #dap 07:42:49 Hidetoshi has joined #dap 07:43:15 kotakagi has joined #dap 07:43:56 sakkuru has joined #dap 07:44:22 jsoh has joined #dap 07:44:45 GregBillock has joined #dap 07:47:46 darobin has joined #dap 07:49:29 Youngsun has joined #dap 07:49:54 AnssiK has joined #dap 07:50:23 a12u has joined #dap 07:56:50 sakkuru has joined #dap 07:57:50 dnkim has joined #dap 07:59:20 youenn has joined #dap 07:59:25 nkic has joined #dap 08:00:01 Hidetoshi has joined #dap 08:00:29 kinji has joined #dap 08:01:04 dom has joined #dap 08:01:43 yamaday has joined #dap 08:02:25 tlr has joined #dap 08:02:43 jcdufourd has joined #dap 08:03:08 kotakagi has joined #dap 08:04:45 Yoshihiro has joined #dap 08:04:45 giuseppe has joined #dap 08:05:00 sato has joined #dap 08:05:32 nwidell has joined #dap 08:05:42 Claes has joined #dap 08:06:02 Present+ Claes_Nilsson 08:06:12 nwidell has joined #dap 08:06:27 Jungkee has joined #dap 08:06:27 shoko_ has joined #dap 08:06:29 present+ giuseppe 08:06:33 RRSAgent, pointer 08:06:33 See http://www.w3.org/2012/11/02-dap-irc#T08-06-33 08:06:38 Present+ Jungkee_Song 08:06:47 trackbot, start meeting 08:06:49 RRSAgent, make logs world 08:06:49 Zakim has joined #dap 08:06:51 Zakim, this will be DAP 08:06:52 Meeting: Device APIs Working Group Teleconference 08:06:52 Date: 02 November 2012 08:06:53 I do not see a conference matching that name scheduled within the next hour, trackbot 08:07:00 s/Teleconference/F2F 08:07:07 Chair: fjh 08:08:52 Takahiro has joined #dap 08:09:15 bryan has joined #dap 08:09:28 present+ Bryan_Sullivan 08:09:39 Scribe: giuseppe 08:09:42 christine has joined #dap 08:09:46 Scribenick: giuseppe 08:10:00 rigo has joined #dap 08:10:06 Topic: Privacy 08:10:20 Present+ Hiroyuki_Aizu 08:10:23 Milan_Patel has joined #dap 08:10:38 Present+ Kensaku_Komatsu 08:10:53 Present+ Milan_Patel 08:11:08 Present+ Norifumi_Kikkawa 08:11:10 geun_hyung has joined #dap 08:11:26 Present+ Niklas_Widell 08:11:35 Present+ Youenn_Fablet 08:11:40 Present+ Soonbo_Han 08:11:46 gmandyam has joined #dap 08:11:49 +Present Yoshiharu_Dewa 08:11:54 dcheng3 has joined #dap 08:11:54 Yuan has joined #dap 08:11:59 Present+ Diana_Cheng 08:12:02 Present+ Naoyuki_Sato 08:12:03 Hi. Christine Runnegar (Internet Society and co-chair of the Privacy Interest Group (PING)). 08:12:04 RRSAgent, make minutes 08:12:04 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html giuseppe 08:12:05 Giri Mandyam from Qualcomm Innovation Center (QuIC) 08:12:13 i'll help, giuseppe 08:12:33 Present+ Dominique_Hazael-Massieux_(w3c) 08:12:48 present+ gmandyam 08:12:58 Presetnt+ GeunHyung_Kim 08:13:13 shige__ has joined #dap 08:13:34 waynecarr has joined #dap 08:14:53 JonathanJ1 has joined #DAP 08:15:08 ???: I'll start with the demo 08:15:14 leetv has joined #dap 08:15:33 ... not the full demo like yesterday but I'll show the demo and the spec and we can discuss potential problems 08:15:38 robint has joined #dap 08:15:48 leetv2 has joined #dap 08:15:58 hitoshi has joined #dap 08:16:05 s/???/Jungkee/ 08:16:23 Jungkee Song, Samsung 08:16:23 Present+ Jean-Claude_Dufourd 08:16:41 ... pick contant and pick media intents 08:16:45 Present+ Anssi_Kostiainen 08:17:02 ... they use web intents 08:17:23 JonathanJ1 has joined #DAP 08:17:28 fjl: should we explain what are we doing at high level first? 08:17:54 jungkee: we want to retrieve contacts on local devices but also on remote services 08:18:00 s/fjl/fjh/ 08:18:10 Pick Contacts Intent spec: http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html 08:18:11 anant has joined #dap 08:18:24 npdoty has joined #dap 08:18:47 present+ Josh_Soref 08:19:12 Present+ Yuan_Ji 08:19:12 ... (explains the demo) 08:19:15 s/+Present/Present+/ 08:19:17 sunghan has joined #dap 08:19:39 fjh has joined #dap 08:19:55 zakim, who is here? 08:19:55 sorry, fjh, I don't know what conference this is 08:19:56 On IRC I see fjh, sunghan, npdoty, anant, JonathanJ1, hitoshi, leetv2, robint, leetv, waynecarr, shige__, Yuan, dcheng3, gmandyam, geun_hyung, Milan_Patel, rigo, christine, bryan, 08:19:56 ... Takahiro, Zakim, shoko_, Jungkee, nwidell, Claes, sato, giuseppe 08:20:07 zakim, this is dap 08:20:07 sorry, fjh, I do not see a conference named 'dap' in progress or scheduled at this time 08:20:13 present+ Christine_Runnegar 08:20:28 RRSAgent, draft minutes 08:20:28 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 08:20:52 SungOk_You_ has joined #dap 08:21:00 kawakami has joined #dap 08:21:13 jungkee: the code used for the demo is similar to the example code in the spec 08:21:22 ... we use a pick action 08:21:27 s/Presetnt/Present/ 08:21:56 RRSAgent, draft minutes 08:21:56 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 08:22:06 ... "action: http://intents.w3.org/pick" 08:22:29 ... type: "http://intents.w3c.org/type/contact" 08:22:48 ... so we use pick intent and contact type 08:23:14 rrsagent, draft minutes 08:23:14 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html JonathanJ1 08:23:18 ... after creating this intent the client call startActivity with this intent object 08:23:36 ... when the user has selected a service and is in the service page 08:23:44 ... then the callback is called on the client side 08:23:50 bjkim has joined #dap 08:23:54 Present+ Jonathan_Jeon 08:24:13 ... let me show the Service part 08:24:30 ... I'll show pick media since I didn't have time to add this to the pick contact spec 08:24:38 ... but pick media is versy similar 08:24:58 richt has joined #dap 08:25:11 ... the service side call postResult with the result that wants to send back to the client 08:25:19 sees at least 4 different relevant parties: the user, the user agent, the client, the implementer of the service 08:25:24 ... after postResult is called, the callback is invoked in the client 08:26:03 can someone post the URI of the Draft? 08:26:04 Present+ Rich_Tibbett 08:26:26 Contact Picker Intent draft: http://www.w3.org/TR/contacts-api/ 08:26:37 ... (goes through the attributes of the contact class) 08:26:51 s/Contact class/ Contact dictionary/ 08:26:57 s/Contact Picker Intent draft:/->/ 08:27:06 Wonsuk has joined #dap 08:27:16 s|/|/ Contact Picker Intent draft| 08:27:28 shoko_ has joined #dap 08:28:08 RRSAgent, draft minutes 08:28:08 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 08:28:29 Pick Media Intent draft: http://www.w3.org/TR/gallery/ 08:28:51 s|s/Contact class/ Contact dictionary/ Contact Picker Intent draft|| 08:29:01 s|Pick Media Intent draft:|->| 08:29:07 s|/|/ Pick Media Intent draft| 08:29:32 s|api/|api/ Contact Picker Intent draft| 08:29:34 is this really a hint? the draft says "MUST NOT return defined fields on the contact objects that it provides other than those present in this list" 08:29:37 RRSAgent, draft minutes 08:29:37 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 08:29:50 Pick Contacts Intent Editor's Draft: http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html 08:29:50 although `search` is explicitly a hint, this seems like a hard requirement 08:30:03 +1 on npdoty 08:30:15 [I think there are substantial changes from the published WD?] 08:30:26 dom: I think what is a hint is the search parameter, not the list of fields 08:30:29 s|Pick Contacts Intent Editor's Draft: http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html|-> http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html Pick Contacts Intent Editor's Draft| 08:30:43 RRSAgent, draft minutes 08:30:43 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 08:31:02 ... you can always limit which fields are returned 08:31:19 ... if the service allows it the user can also select other fields 08:31:36 smaug has joined #dap 08:32:00 q+ Josh_Soref to say i'm willing to give up removing the search bit as long as we rename the field to include `hint` 08:32:01 fjh: the question is what else can we do for privacy 08:32:08 q? 08:32:19 rigo: I have questions 08:32:32 ... afaiu you can use this for personal contact 08:32:44 hao_ has joined #dap 08:32:47 ... you can get contact from your devices but also use a directory service 08:33:00 jungkee: yes 08:33:03 adrianba has joined #dap 08:33:10 rigo: the distrinction you should made in your spec 08:33:25 ... is that the attac model is different if you are using local contact or directory services 08:33:44 s/attac/attack/ 08:34:12 JonathanJ3 has joined #dap 08:34:16 ... we don't need to be prescriptive but we can provide guidelines, best practices 08:34:40 q+ are you sure it's required? 08:34:45 q+ to suggest that we address overall service design guidelines outside the spec as needed 08:34:46 q+ to ask are you sure it's required? 08:35:26 josh: I don't think this is a really issue, a directory service should be really broken if it gives you back more than the user asked you 08:35:33 q+ 08:35:37 ... so I don't think this is an issue in reality 08:35:42 ack Josh_Soref 08:35:42 Josh_Soref, you wanted to say i'm willing to give up removing the search bit as long as we rename the field to include `hint` 08:35:47 ack bryan 08:35:47 bryan, you wanted to suggest that we address overall service design guidelines outside the spec as needed 08:35:47 ... we cannot fix broekn services 08:35:56 bryan: I think is good if we develop best practices 08:35:58 s/broekn/broken/ 08:36:05 http://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/ 08:36:07 s/josh:/Josh_Soref:/ 08:36:09 ... we cannot prevent poorly designed services 08:36:30 ... but the API is user driven, intended to optimize user experience 08:36:54 (in practice, any query-able directory service has already a way to prevent this kind of problem) 08:37:12 I agree that the Web Application Privacy Best Practices doc may be good to point to 08:37:22 ringo: ok, I get this, but still for web developers is important to understand the difference between accessing contacts from the device and contacts from the web 08:37:26 ... though perhaps it could be more specific for intent service implementers 08:37:45 s/ringo/rigo/ 08:38:18 ... in the second case, you have to deal with all sort of issues like why are they accessing these data, how long they want to keep them, what they want to do with them etc 08:38:24 [we need compatibility with vcard] 08:38:42 q? 08:38:55 q+ 08:39:08 ... we should look into what ??? have done, they have a schema for contacts 08:39:19 The Web API Design Cookbook may be useful in this discussion also (based on our experiences designing these APIs) -> http://www.w3.org/TR/2012/NOTE-api-design-20121002/ 08:39:23 Milan_Patel has joined #dap 08:39:38 Present+ Milan_Patel 08:39:44 Josh_Soref: we need to have compatibility with vcard format 08:39:45 SungOk_You__ has joined #dap 08:39:47 ack npdoty 08:39:47 npdoty, you wanted to ask are you sure it's required? 08:39:56 ???: I have few comments 08:40:13 ... first of all the limit fields is an excelent practice 08:40:14 s/???/npdoty/ 08:40:23 shepazu has joined #dap 08:40:28 s/excelent/excellent/ 08:40:47 is there use of https? I think that's the first thing the data protection authorities will ask for 08:41:08 ... I think DAP has done some work for some API to be user initiatied 08:41:25 ... we where talking about web intents in web apps early this week 08:41:31 if they could be user initiated 08:41:34 rigo, were you suggesting in your comments that we include intended uses (expressed by the app) and allowed/agreed uses (expressed by the user through the service provider) as parameters of the interface? 08:41:39 s/if/... if/ 08:42:09 bryan, only as a hint that you could do so using RDFa, not proscribing anything 08:42:18 ... so question is: is always the app that starts the intent or is the user that initiates it? 08:42:28 ok 08:42:30 ???: yes now the spec says it needs to be user initiaited 08:42:33 q- 08:42:41 RRSAgent, draft minutes 08:42:41 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html shan 08:43:11 timeless: yes we need user initiated, but is not a MUST 08:43:34 Present+ Mounir_Lamouri 08:43:35 ... is user agent best practices, we cannot mandate what the user agent does 08:43:41 Present+ Wonsuk_Lee 08:44:35 q+ 08:45:04 timeless: the input field data model already have events, doesn't matter from where this content come from and should not be exposed to the web page 08:45:18 s/timeless/Josh_Soref/ 08:45:21 s/timeless/Josh_Soref/ 08:46:00 npdoty: I think there are 4 relevant parties, the user, the user agent, the client and the implementing service 08:46:13 ... the privacy consideration section put different considerations on different parties 08:46:25 ... but I'm not usse if we addres each one and if we address them in the same way 08:47:25 s/usse/use/ 08:47:29 s/addres/address/ 08:47:36 s/addres /address / 08:47:41 s/addresss/address/ 08:47:50 fjh: we don't have requirements for clients and user agents, we only have best practices because we decided that this is implementation dependent 08:48:22 jfmoy has joined #dap 08:48:24 q+ 08:48:26 ... we are not making normative requirements on privacy, that of course limit how much you can enforice if ppl decide to ignore the best practices 08:49:05 npdoty: ok so the spec probably has some bugs since some section are marked as normative and some other seems to use a normative wording 08:49:50 ... I've done an investigation on sites using geolocation and I've noticed that most of them don't use the best practices given by the geolocation spec 08:50:00 ... maybe because they don't read the spec 08:50:26 Josh_Soref: I want to point out that there is a difference between the contact spec and the general web intents spec 08:52:08 fumitakaW_ has joined #dap 08:52:43 Josh_Soref: there's distinction between Contacts Intent spec and Intents general spec; a UA implementing Intents can and likely will not implement any random spec, and thus wouldn't know about any MUST/SHOULDs in that Intent, and wouldn't be involved unless it was one of the direct parties (e.g. as a pick/contact intent magic source for 08:52:43 Contacts) 08:52:46 npdoty: the last thing is a general design consideration, we have seen problems with the UI, i.e. is not always clear to the user the communication flow. in firefox OS or activities in android everything is modal so is a bit easier to understand 08:52:56 s/timeless/scribe/ 08:52:59 s/timeless/scribe/ 08:53:11 s/Contacts/... Contacts/ 08:53:18 ... but it may not be obvious when you have this model when you open a new tab 08:53:36 ... and this get more complicated if you have multiple intents and then multiple tabs 08:53:58 q+ to suggest a hint for a presentation before sending, see demo again 08:54:32 q+ to ask why Nock thinks that such information would benefit users, and not confuse them 08:54:37 ack fjh 08:54:43 s/Nock/Nick/ 08:55:08 fjh: I want to add that web intents has explicit intents 08:55:09 s/Nick/npdoty/ 08:55:22 ... that means you can compose multiple services and use them all in one app 08:55:24 my point is that it might help users to feel more comfortable using this sort of service if they have a clear understanding of where the data is going to go back to, which is harder when it's just several tabs 08:55:25 q- bryan 08:55:32 ... so for the user it looks like one app 08:55:40 q+ bryan to ask why npdoty thinks that such information would benefit users, and not confuse them 08:55:41 ... and there could be security issues there 08:55:55 to fjh, we have to get the borders right. Privacy is only if it goes over the border to another controller 08:55:56 ... and proivacy concerns, and may be different from the normal intents 08:55:59 ack mounir 08:56:06 ... we may want to go back to that later 08:56:12 q+ 08:56:26 s/proivacy/privacy/ 08:56:53 mounir: Sys Apps is also developing a Contacts API and we should make sure we coordinate with them 08:56:57 rich: I think is very unfortunate that we have replace the contact API with the pick intent based appraoch 08:57:04 s/rich:/richt:/ 08:57:06 .. any chance we can bring it back? 08:57:23 dom: should be in cvs, we should be able to bring it back 08:57:35 are we talking about making sure it's the same data format? or replacing one API with another? 08:57:35 s/proivacy/privacy/ 08:57:47 richt: nothing bad with the old one, we did a lot of work 08:57:53 In addition to using webintents to support user mediated selection of services, webintents supports the creation of composed apps that are created from a variety of services without user interaction - we may also wish to discuss privacy considerations of this 08:57:58 ack christine 08:58:44 christine: is there any thinking that this pick contact intents can be used with services that are actually using other services to retrieve data 08:59:35 takeaways - clarify privacy sections regarding what appear to be normative statements in an informative section, clarity regarding statements about various actors 09:00:18 ... my question was to follow on on what you said on explicit intents 09:00:40 fjh: but they are actually more a client/app issue rather then service issue 09:00:58 christine: how you protect the data during your transaction 09:01:20 timeless:I have an open action item to decide if to mandate ssl or not 09:01:25 .. but is difficult we can mandate it 09:01:38 .. and we always receive push back when we try to enforce 09:01:46 jbourhis has joined #dap 09:01:46 GregBillock has joined #dap 09:01:57 ... we cannot useful enforce it, so the answer is no 09:02:21 ... the UA promise that the delivery is done in a trusted manner 09:02:36 ... between the servive page and the client page 09:02:38 rigo suggested rate limitation on service offering data 09:02:43 ... and is impossible to validate 09:02:52 s/timeless:/Josh_Soref:/G 09:03:53 ???: I understand that iun some cases you don't want to use https, but I can assure you that you have problem with the autoirities if you transmit data over the wire without any guarntee of protection 09:03:54 it could be confusing that if I load a site over https and then I start using services and some of them aren't implemented over https, I might be upset that I thought I was accessing the web securely but really wasn't 09:04:00 s/???/rigo 09:04:10 ... so at least we need some recommendation on what to use in some cases 09:04:29 Josh_Soref: this probaly needs to go in a best practice 09:04:32 rigo asks if data can be transferred confidentiality - data protection requirement for transfer of data outside user sphere - need to provide hint or recommendation 09:04:54 rigo - need a should to address concern 09:05:03 q? 09:05:23 ???: no, this is a conformance issue, if you have a SHOUL then if you have a good reason for not using SSL than is ok, but if you don't have a good reason for doing it then you are not conformant and the autirity can question you conformance with the spec 09:05:58 S/SHOUL/SHOULD/ 09:05:58 bryan: you cannot know what the service provider is doing with the data 09:06:04 s/???/rigo 09:06:05 ... the UA has no way to track data 09:06:06 q+ Josh_Soref to note there's a risk of conflating Intents in general and Contacts Intent 09:06:18 q+ 09:06:37 ack rigo 09:06:37 rigo, you wanted to suggest a hint for a presentation before sending, see demo again 09:06:39 q+ 09:06:45 dom: on the service provider side we should say what you are expected to do if you transmit confidential data 09:06:46 q+ to ask about CSP 09:06:47 rigo notes legal system can enforce it 09:06:51 q? 09:06:56 richt: you can use a should 09:07:02 q? 09:07:03 s/SHOUL/SHOULD/ 09:07:24 s/SHOULDD/SHOULD/ 09:07:37 christine - groups are sensitive information as well 09:07:53 christine: my understanding is that the server is able to remember what the user does, which information was selected on which day 09:08:15 ... (we are talking only about contact intents, not intents in general) 09:08:56 ... a service can only know what is given to a user, not what other services are giving to the user, right? 09:08:56 q+ 09:09:03 several ppl: yes 09:09:07 Josh_Soref: unless the server is incestuous with those other providers 09:09:11 s/timeless/scribe/ 09:09:25 fjh: do we need to document this in the spec? 09:09:51 s/you can use a should/you can use a should and then we can forget about it because it's not technically enforceable and should requirements are generally not useful./ 09:10:03 ack bryan 09:10:03 bryan, you wanted to ask why npdoty thinks that such information would benefit users, and not confuse them 09:10:14 s/and should requirements are generally not useful/and 'SHOULD' requirements are generally not useful/ 09:10:16 rigo - should have statement in spec to clarify that service providers do not have visibility into other data requested (need to clarify this) 09:10:45 lxq has joined #DAP 09:10:58 rigo: if you write it as a normative statement into the spec everybody will have to implement it that way (about the same origin constraints) 09:11:33 RRSAgent, draft minutes 09:11:33 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 09:11:38 bryan: yesterday we had a discussion about multiple tabs and it was clear that we need to do more work on the user exprience 09:11:59 ... we cannot give too much info to the user on what's going on otherwise it could be even more confusin 09:12:12 s/this probaly/this probably/ 09:12:22 npdoty: of course is not that more information is better, I agree. 09:12:28 s|S/SHOUL/SHOULD/|| 09:12:38 ack fjh 09:13:05 npdoty: just that there is a privacy implication to that usability concern, that the user doesn't know where the data is going may make them lose data or make them hesitant to use intents if they don't know where the data is going back 09:13:25 fjh: we have been straggling on how to make privacy by design but we dont have anormative way to enforce it. 09:13:38 ... maybe we need a normative way to document this 09:13:40 ack Josh_Soref 09:13:40 Josh_Soref, you wanted to note there's a risk of conflating Intents in general and Contacts Intent 09:13:56 opoto has joined #dap 09:14:39 q+ to ask about other specs 09:15:03 we could help them -- pick and choose from these relevant privacy sections as are applicable to the data type that you are considering 09:15:21 rigo: personal information is the new money, so transmitting information is like transmitting money 09:15:35 Josh_Soref: if we had to have the same privacy text for every one of thousands of intents specs, that's not good as surely some of them will forget 09:15:55 ... so we need to be careful, so if you are working on a contact information you need to make sure to enforce a certain level of privacy enforced 09:16:19 Josh_Soref: I want to write it in the intents spec, not in each spec using intents 09:16:25 rigo: no way 09:16:51 fjh: maybe we should take this discussion offline 09:16:59 q? 09:17:04 ack giuseppe 09:17:07 I think it might be overstating things to say that no one will ever bring a spec to w3c if we have a privacy discussion about it, but I agree that where we can make useful privacy considerations for all intents, that would be efficient 09:17:08 ack GregBillock 09:18:25 RRSAgent, draft minutes 09:18:25 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 09:18:34 GregBillock: I think what the intents spec is missing is indication on how to guarantee privacy when you transmitts data from a service to a client 09:19:01 Takahiro has joined #dap 09:19:17 s/several ppl:/Several_People:/ 09:19:21 Alexandre_Morgaut has joined #dap 09:19:34 s|s/priovacy/privacy/|| 09:19:45 q? 09:19:45 q? 09:19:57 s/initiaited/initiated/ 09:20:20 s/???:/GregBillock:/ 09:20:55 fjh: I think what you are saying is that the spec is pretty generic and we cannot anticipate what is going to happen 09:21:09 ... so the user agent must be the trustee in the transaction 09:23:08 greg notes that privacy restrictions would be an issue for debugging capability in production system to enable implementations 09:23:16 GregBillock: we cannot prohibit the UA to make available data to 3rd , because it can be useful for example to implement debuggin tools 09:23:56 do we have to ask the service to honor the data minimization? I thought the user agent could actually prohibit too much data 09:24:37 rigo: these are different issues, if you collect data for debugging that is fine, as far as you discard them later 09:25:04 .. the concern is that several services can accomulate data from an individual over time 09:26:00 GregBillock, can't the user agent prohibit extra fields from flowing through this Intent? 09:27:04 Josh_Soref: we envision pass through validation intents 09:27:09 s/timeless/scribe/ 09:27:13 ???: is not useful to put normative text that we cannot test, since it will be useless 09:27:16 made all my points, you have to get the terms for the actors right that participate in the contact intent scenario, give them consistent names and this will allow you to have a much clearer understanding of what's happening 09:27:18 q? 09:27:20 s/???/dcheng/ 09:27:22 q- rigo 09:27:22 ack dcheng3 09:27:25 ack dcheng3 09:27:26 ack npdoty 09:27:26 npdoty, you wanted to ask about CSP 09:27:26 ack dcheng 09:27:31 fjh: we may still need normative text for legal reasons even if we cannot test it 09:27:38 q? 09:27:49 +1 to avoiding unverifiable requirements 09:27:52 Josh_Soref: we also envision Intent reputation services 09:27:55 s/timeless/scribe/ 09:28:07 q+ for the demo thing 09:28:33 npdoty: do we think that the contact security policy should give sites limitation on where the data are injected 09:29:07 Josh_Soref: data comes via a callback and the user has decided to approve that transaction 09:29:31 ... is a client decision if he wants to trust the service 09:29:55 s/the service/intent service provided data/ 09:29:57 Josh_Soref: to tag the data with the origin that it came from might itself be an additional privacy concern 09:30:06 s/npdoty/scribe/ 09:30:23 fjh: there is a concern in the group that in the attempt to enforce privacy we put too many restriction or untestable requirements 09:30:47 ... but there are also a regulatory requirements 09:31:03 ... so we may want to discuss a bit more to find the right balance 09:31:05 Zakim, close the queue 09:31:06 ok, dom, the speaker queue is closed 09:31:32 I think Josh_Soref's response is probably right here, I was just throwing the origins/CSP idea out there 09:31:54 s/will be useless/will be useless -as was the case in GeoLocation where we mandated an explanation of how data was going to be used, and no one did anything for it/ 09:32:04 ... the second issue , if you look at the dap page, we have a list of specs that may or may not raise privacy concerns 09:32:25 ... maybe we can talk with the privacy groups and review with them these specs 09:32:45 ... we did some work on privacy and there are documents listed from the home page 09:33:03 ... we don't need to repeat that work 09:33:34 ... maybe we should consider to let the Ping WG to discuss this so we don't take time from this group 09:33:35 q? 09:33:46 JonathanJ3 has joined #dap 09:33:50 cristine: sounds good but we want at least few experts from this group to help 09:33:58 ack fjh 09:33:58 fjh, you wanted to ask about other specs 09:34:06 fjh and Bryan volunteer to help 09:34:11 ack ri 09:34:11 rigo, you wanted to discuss the demo thing 09:34:12 ack rigo 09:34:37 fjh: I can help 09:34:41 bryan: I can help 09:35:02 I suggest we continue privacy conversation in PING by looking at some of the other DAP specs to see which issues and suggestions might apply 09:35:04 rigo: in your demo you pushed a button and got the data 09:35:21 Excellent idea to continue these privacy discussions in PING. Thank you Frederick. We very much appreciate the work DAP has already done on privacy and your offer to continue working on this with us. 09:35:21 ... the user wants to know here these data are going 09:36:15 I note that the WG has raised legitimate concerns about testability and ability to enforce normative privacy requirements that go beyond minimization - should discuss in PING how to suggest WGs add requirements on actors outside the implementers scope and do this in clear and usable manners. 09:36:19 s/manners/manner/ 09:36:23 ... in general is a good idea to make clear who does what, who controls what and where the information flow 09:36:31 I want to ask about normative requirements and testing, but per dom I'll talk with people over coffee rather than add myself to the q 09:36:32 q/? 09:36:38 Q? 09:36:39 ... so the user can understand when to pay attention 09:36:43 close queue 09:37:26 Josh_Soref: note that producer doesn't know who is the consumer and the consumer doesn't know who is the producer 09:37:43 ... and this is to guarantee privacy 09:38:17 PING has calls Thursdays once a month at 10am PT 09:38:18 fjh: let me know who is intersted in joining the PING calls 09:38:31 christine: we could have a call once a months, or more if you want 09:38:32 Josh_Soref: i could probably dial in 09:38:35 s/timeless/scribe/ 09:38:54 Everyone. Thank you for this very useful discussion. 09:39:01 if it were useful, we might be able to have dedicated PING calls if a group wants a particular privacy review of a document 09:39:21 Good idea Nick 09:39:21 +1, thanks to dap for talking with us, this was great 09:39:23 fjh: now break 09:39:28 ... back in 30 minutes 09:39:31 ... until 11 09:39:47 RRSAgent, draft minutes 09:39:47 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html shan 09:42:29 shunan has joined #dap 09:45:00 shunan has joined #DAP 09:50:42 xiaoqiang has joined #DAP 09:50:48 kensaku_ has joined #dap 09:52:29 hao_ has left #dap 09:53:30 hao_ has joined #dap 09:54:31 kinji has joined #dap 09:56:18 kawakami has joined #dap 09:59:05 opoto has joined #dap 10:02:03 nwidell has joined #dap 10:05:03 Takahiro has joined #dap 10:07:32 leetv has joined #dap 10:07:51 Youngsun has joined #dap 10:08:04 a12u has joined #dap 10:10:03 leetv2 has joined #dap 10:10:48 tlr has joined #dap 10:11:30 nsakai has joined #dap 10:11:53 kenji has joined #dap 10:12:51 sakkuru has joined #dap 10:12:57 Hidetoshi has joined #dap 10:14:52 Alexandre_Morgaut has joined #dap 10:15:11 SungOk_You has joined #dap 10:15:26 nwidell has joined #dap 10:15:45 jfmoy has joined #dap 10:17:15 noriya_ has joined #DAP 10:18:13 jbourhis has joined #dap 10:18:55 Wonsuk has joined #dap 10:19:19 Geunhyung has joined #dap 10:19:19 fumitakaW_ has joined #dap 10:19:31 Takahiro has joined #dap 10:19:39 npdoty has joined #dap 10:19:42 Milan_Patel has joined #dap 10:20:31 topic: WebIntents Addendum - Local Services 10:20:42 scribe: timeless 10:21:10 kinji has joined #dap 10:22:07 fjh: after lunch, Network Service Discovery 10:22:09 ... then Search 10:22:11 ... then Signage 10:22:43 Claes: how many of you were not at the break out session on Web Intents yesterday? 10:22:53 [ perhaps a dozen hands ] 10:22:58 Claes: i want to show this to you 10:23:04 ... so you can see what we're doing 10:23:16 robint has joined #dap 10:23:24 ... the idea is to allow web apps to find a new service, situated anyway 10:23:26 ... not just the cloud 10:23:31 ... but also devices in the local network 10:23:43 ... we experimented w/ extending Web Intents to find local services 10:23:53 [ Web Intents for local network services ] 10:24:01 -> http://www.w3.org/wiki/WebIntents/SonyMobile_-_Local_Network_Service_Discovery WebIntents/SonyMobile - Local Network Service Discovery 10:24:02 [ Dynamic Service Registration 1] 10:24:16 -> http://www.w3.org/wiki/images/2/2e/V4_W3C_Web_Intents_-_Local_UPnP_Service_Discovery.pdf Claes' slides 10:24:21 Claes: user presses `remote` button 10:24:34 [ Dynamic Service Registration 2] 10:24:50 [ Service Execution 1] 10:24:53 [ Service Execution 2] 10:25:11 Claes: service page implements low level communication stuff 10:25:17 ... for communicating w/ TV/whatever 10:25:32 [ UPnP: SSDP Packet -> Notify ] 10:25:43 Claes: we added Web Intents ServiceType 10:25:43 s/Claes' slides/slides Claes presented during the TPAC breakout/ 10:25:48 [ UPnP: SSDP Packet -> Search ] 10:26:10 RRSAgent, draft minutes 10:26:10 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 10:26:35 Claes: here's our experimental web page with the chromium implementation 10:26:44 ... we select view 10:26:47 ... here's the service picker 10:26:51 ... we select the tv 10:26:57 ... the service page is displayed 10:27:05 ... we control it in the service page 10:27:10 ... and it plays back on the TV 10:27:23 tomoyuki_ has joined #dap 10:27:46 ... Another way is to receive the service page from the TV, and execute it in the background 10:27:54 ... keeping control available to the Client 10:28:01 ... here's an example 10:28:17 ... i get a service page 10:28:21 ... we used a JS shim 10:28:32 ... now i'm able to control it from the client page 10:28:52 ... it's doing work from the background 10:28:58 Josh_Soref: i like that implementation 10:29:21 sato: Pick image 10:29:27 [ Pic image ] 10:29:35 sato: Pick image from DSC to web service 10:29:42 GregBillock has joined #dap 10:29:44 [ sato reads slide ] 10:30:32 s/DSC/DSC (Digital Still Camera)/ 10:31:11 [ Sony Cyber-Shot ] 10:31:22 [ My Memories Online ] 10:31:37 sato: you get a ui page from the DSC 10:31:45 dom: based on mDNS discovery? 10:31:51 sato: with some glue 10:32:18 fjh: how did you get to the web page w/ the camera? 10:32:25 sato: web intents service registration 10:32:34 ... with Claes's impl 10:32:45 ... local discovery protocol supports mDNS/SSDP 10:32:53 ... the registration page returns url 10:32:59 ... so browser knows the UI page to load 10:33:17 npdoty: the device is using a broadcast protocol to tell the browser 10:33:24 ... and your camera is running a web server? 10:33:27 sato: yes yes 10:33:33 ... but with a bit of fake 10:33:43 [ Demo ] 10:33:46 thx for the clarification 10:33:49 kensatu:Kensatu, QQQQ 10:33:51 dcheng3 has joined #dap 10:33:54 s/:/: / 10:34:04 ... demo is just for existing devices 10:34:06 s/QQQQ/from NTT communication 10:34:19 ... this demonstration isn't for Addendum 10:34:39 ... i have to leave after lunch 10:35:07 ... demo with YouTube video and TV 10:35:17 [ Browser to TV demo ] 10:35:30 kensatu: this page is now controlling tv 10:35:35 ... first you click service discovery 10:35:39 ... find tv with upnp 10:36:00 ... select devices and 10:36:07 ... [loading...] 10:36:50 [ Diagram for the demo ] 10:37:08 kensatu: YouTube -> view activity video/mp4 10:37:25 ... obtain server uri via explicit intent 10:37:32 rigo has joined #dap 10:37:48 .. implemented background process 10:37:54 s/../.../ 10:37:59 ... connected with XHR2 10:38:30 ... the background service uses a reverse proxy w/ DLNA to talk to TV via socket APIs 10:38:34 ... but DLNA isn't enough 10:38:49 ... but current devices have a restriction to talk to local services 10:39:02 ... so i needed to use a reverse proxy to connect YouTube 10:39:21 ... but flexibility to implement this would be great for future services 10:39:28 ... so it's important to consider a sockets api 10:39:41 ... perhaps a sysapps api for sockets 10:39:43 ... thanks 10:40:15 richt: the TV was playing the demo 10:40:25 [ There's a TV in the center of the room 10:40:37 s/room/room ]/ 10:40:56 [ the screen projecting the computer is at the far end of the room ] 10:41:10 [ some people foolishly had eyes only on the projected computer screen and speaker ] 10:41:12 q? 10:41:28 [ and missed the TV showing the demo showing YouTube content ] 10:41:45 fjh: wanted to understand what you were saying w/ sysapps 10:42:00 richt: he was saying that this was something we'd look at there as well 10:42:07 ... extra requirements for a reverse proxy 10:42:11 ... not sure about here/just sysapps 10:42:16 ... but sysapps will work on that 10:42:48 kensatu: current implementation uses (needs?) a socket api 10:42:55 q+ 10:42:58 ... sysapps wg will be discussing a raw socket api 10:43:26 fjh: isn't there an api in webapps? 10:43:31 dom: that's WebSockets 10:43:43 richt: chrome has a Raw sockets api for chrome extensions 10:43:58 Claes has joined #dap 10:44:14 fjh: raw sockets in sysapps, websockets in webapps, intents in dap 10:44:40 timeless: their TV needed to get the data, but only speaks HTTP 10:45:05 s/bryan/scribe/ 10:45:07 ... so they needed a proxy to answer the HTTP GET and provide the data back from youtube 10:45:16 s/timeless:/Josh_Soref:/ 10:45:18 s/bryan/scribe/ 10:45:26 dom: so they built a web server in their browser? 10:45:29 Josh_Soref: yes 10:45:46 Claes: our demo shows how we can use WebIntents, but it requires WebIntents enabled devices 10:45:54 ... even though those changes are quite minor 10:46:10 ... [their demo allows for no changes to existing deployed DLNA TVs] 10:46:18 ... there could be many choices if you use web intents 10:46:27 ... you could use cloud service, or device on local network 10:46:29 ... or whatever 10:46:37 ... that's why we based our solution on web intents 10:46:46 ... flexible choice about how to execute the service 10:46:53 open queue 10:46:55 Zakim, reopen the queue 10:46:55 ok, dom, the speaker queue is open 10:46:58 q+ 10:46:59 ... trying to hear WG's oppion 10:47:05 q+ gmandyam 10:47:07 richt: i like this mechanism 10:47:13 ... it's a bootstrap into web intents 10:47:23 ... right now you have and discover by browsing 10:47:32 ... this is another way to add other service providers 10:47:36 sato has joined #dap 10:47:38 ... it sits in this web intents model 10:47:52 ... i can connect to this thing, but this device needs to speak web intents 10:48:03 q+ to request clarification on whether decision on "long-life intents" impacts on these proposals 10:48:07 ... one thing w/ web intents, especially w/ Share 10:48:14 q? 10:48:14 ... is you have to open service page to share the video 10:48:26 ... the web developer loses control over the direction of their UX 10:48:30 q+ 10:48:32 ... they hand off control 10:48:38 ... we [Opera] do differently 10:48:41 q+ 10:48:42 ... is background with XHR 10:49:00 ... but your bootstrap and control change is because it's WebIntents 10:49:04 ... it isn't necessarily bad 10:49:07 sakkuru_ has joined #dap 10:49:12 ... but it isn't UPnP/mDNS as we know it too 10:49:18 Claes: yes, with a visible page from the tv 10:49:29 ... the web developer has less control over the tv 10:49:34 ... but that may be an advantage 10:49:39 ... the tv may have more options for the user 10:49:46 ... the other alternative is a hidden service page 10:49:49 ... which is our proposal 10:49:52 sakkuru has joined #dap 10:49:56 ... which would leave control to the web developer 10:50:05 q? 10:50:15 ack fjh 10:50:23 fjh: what are we trying to do in this session? 10:50:32 ... seems like we decided we'll have more than one way to do 10:50:39 richt: no need to have competition 10:50:45 ... don't want to debate one way or another 10:50:53 marcin_hanclik has joined #dap 10:50:53 fjh: if we've learned things, we want to share 10:51:00 ... if we have nothing to learn, we should end early 10:51:12 ... what are you looking for? 10:51:15 q+ 10:51:17 Claes: i'd like feedback on the basic ideas 10:51:21 q+ Josh_Soref 10:51:30 Claes: looking for feedback on the spec 10:51:34 ack gmandyam 10:51:45 s/don't want to debate one way or another/don't want to debate one way or another. They address the use cases in different ways and can both be valid./ 10:52:01 q+ 10:52:09 gmandyam: presumably there would be a socket spec 10:52:17 ... we don't think there's a need 10:52:41 ... it shouldn't be assumed there'd be a need for a new sockets api 10:52:53 fjh: you're saying sysapps may not provide a sockets api 10:53:14 q? 10:53:15 gmandyam: we may not need Web Intents in sysapps 10:53:24 richt: raw sockets is building anything on top of TCP/UDP 10:53:32 dom: outside of scope for this group 10:53:40 ack nwidell 10:53:40 nwidell, you wanted to request clarification on whether decision on "long-life intents" impacts on these proposals 10:53:41 q? 10:53:48 nwidell: what's the impact of removing long lived intents 10:53:51 ... will this still work? 10:53:56 Claes: in the second UC 10:54:00 ... w/ the hidden service page 10:54:09 ... control buttons in client starting page 10:54:17 ... we have long lived connection between client and service 10:54:24 ... we use Channel Messaging to send commands 10:54:46 ... we use simple commands like "Play" "Pause" 10:54:58 q? 10:55:00 ... GregBillock, you said you weren't aware of an application using it 10:55:06 ... we were using it for our demo 10:55:07 ack Claes 10:55:21 [ After invoke the service - hidden page will be provided by Service. ] 10:55:34 Claes: left is Browser w/ controls using channel messaging 10:55:41 ... hidden page which talks to the tv 10:55:52 overall, I think the UX will benefit from keeping control in the app page (and not a service page, just for a remote control function) 10:56:00 dom: does the new direction of web intents with a restriction on single shot exchanges problematic? 10:56:26 Claes: for having a UC where UI stays in client page, we need longer lasting relation with service page 10:56:33 ... that's why we propose hidden 10:56:43 ack GregBillock 10:56:54 GregBillock: i wanted to talk about a couple of things 10:57:06 ... FIFO/LIFO... 10:57:06 if the use case is a remote control, and you need for example an indication of the video timeline, single shot exchanges will not work 10:57:08 [ laughter ] 10:57:20 GregBillock: relationship to network discovery mentioned by richt/Claes 10:57:31 ... similar to relationship between getUserMedia and Media Capture 10:57:38 ... in getUserMedia, client retains control 10:57:51 ... in Media Capture, the client says "get back to me when you're done" 10:58:00 good analogy from GregBillock 10:58:00 ... i think the same division of UCs is present here 10:58:12 ... second part to talk about 10:58:24 ... long lived connections are right now because we pass structured clones through web intents 10:58:29 ... the spec specifically supports transferables 10:58:42 ... we mentioned UI issues for coordinating long lasting connections between tabs 10:58:48 ... more difficult to address in UX of browser 10:58:56 ... Web Intents spec may need to change 10:59:03 ... to address these communications 10:59:17 ... there's a legitimate reason to not allow that because we don't know how to do it in the UI 10:59:24 ... this is a good example where it comes into play 10:59:35 ... not exactly sure what the outcome will be of that thinking 10:59:40 ... a profitable direction to explore 10:59:52 ... is to think about casting Web Intent style interactions as Navigation style interactions 11:00:04 ... window.open() which use url endpoints 11:00:29 ... if you do long lived interaction, maybe you do url discovery and set that up w/ webMessaging 11:00:50 ... we could build the kinds of UCs out of the ingredients that already exist 11:00:54 ... not a concrete proposal 11:01:02 ... it's a potential solution to problems we're facing 11:01:17 ... leaves Request/Response stuff that we initially envisioned 11:01:36 ... and fits nicely w/ this concept of delegation 11:01:55 ... the generic UIs fit in request/response 11:02:04 ... and don't lend themselves to long lived 11:02:08 ... it's not a concrete proposal 11:02:10 q? 11:02:19 fjh: action? 11:02:24 GregBillock: we spoke about this yesterday 11:02:29 ... we'll hash this out 11:02:34 ... what we'll do w/ web intents 11:02:39 ... talk w/ web activities 11:02:50 ... trying to address these in a way that's more concrete 11:03:06 ... perhaps let's not exchange structured clones 11:03:28 q? 11:03:35 Claes: we don't know where we'll end up w/ Web Intents 11:03:42 ... but you understand the need for long lived connections 11:04:10 naively, it does seem like removing long-lived connections makes it easier to harmonize acitivities/intents proposals and to address the usability issues we've come across 11:04:36 ... but you don't think we'll have structured clones in web intents? 11:04:46 Josh_Soref: i think structured clones may drop from intents 11:04:54 ack marcin_hanclik 11:04:54 ... but you may get a url from web intnts 11:05:03 ... and be able to use web messaging w/ that url 11:05:15 marcin_hanclik: we have a spec called CHTML 11:05:18 s/intnts/intents/ 11:05:29 ... one of the most important aspects to discuss 11:05:33 .... is the security 11:05:34 s/CHTML/CE-HTML/ 11:06:15 marcin_hanclik, we're not allowing the web site to browse the whole network. There will be user opt-in at a per service level in both current proposals. 11:06:30 ...just to clarify that. 11:06:52 the UA will do the discover and broker the service provision to web pages. 11:07:57 bryan: i think it's better to keep UI in app rather than in service page if possible 11:08:02 ... apps use a lot of external data + helpers 11:08:03 ... using XHR, websockets, SSE 11:08:27 Wonsuk has joined #dap 11:08:29 ... apps like background bits 11:08:29 ... i don't know users will like/understand modality 11:08:52 ack J 11:08:59 ack bryan 11:09:08 ack Josh_soref 11:09:32 yay lunch! 11:09:44 Wonsuk has left #dap 11:09:49 RRSAgent, draft minutes 11:09:49 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html shan 11:10:11 kenji has left #dap 11:11:23 Geunhyung has left #dap 11:14:28 npdoty has joined #dap 11:16:56 kawakami has joined #dap 11:18:39 a1zu has joined #dap 11:20:28 kawakami_ has joined #dap 12:14:20 RRSAgent has joined #dap 12:14:20 logging to http://www.w3.org/2012/11/02-dap-irc 12:14:37 great 12:14:42 s/great// 12:14:44 please ping me if you need anything else 12:14:50 Yoshiharu has joined #dap 12:14:50 s/please ping me if you need anything else// 12:14:54 RRSAgent, darft minutes 12:14:54 I'm logging. I don't understand 'darft minutes', timeless. Try /msg RRSAgent help 12:14:58 RRSAgent, draft minutes 12:14:58 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 12:14:59 amy has left #dap 12:15:18 shan has joined #dap 12:15:28 Present+ SungOk_You 12:15:32 nwidell has joined #dap 12:15:55 s|s/please ping me if you need anything else//|| 12:16:05 robint has joined #dap 12:16:18 tomoyuki has joined #dap 12:16:22 topic: Network Service Discovery 12:16:42 youenn has joined #dap 12:16:55 sato has joined #dap 12:17:17 opoto has joined #dap 12:17:35 Latest published draft: http://www.w3.org/TR/2012/WD-discovery-api-20121004/ 12:17:36 Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France 12:17:48 Milan_Patel has joined #dap 12:17:50 nkic has joined #dap 12:17:50 s/published draft:/published draft ->/ 12:17:54 Network Service Discovery (NSD) API in Opera -> http://dev.opera.com/articles/view/network-service-discovery-api-support-in-opera/ 12:18:04 rrsagent, generate minutes 12:18:04 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html fjh 12:18:17 Chair: Frederick_Hirsch 12:18:18 Ryosuke has joined #dap 12:18:26 Present+ Frederick_Hirsch 12:18:29 dnkim has joined #dap 12:18:35 Claes has joined #dap 12:18:35 noriya has joined #DAP 12:18:44 hiroki has joined #dap 12:18:52 s/Latest published draft // 12:18:57 Yoshihiro has joined #dap 12:18:58 s/Chair: fjh/Chair: Frederick_Hirsch/ 12:19:07 nsakai has joined #dap 12:19:07 s|04/|04/ Latest published draft| 12:19:12 Shinji has joined #dap 12:19:15 richt: the UA does the discovery 12:19:21 ... using common available protocols from the network 12:19:25 ... UPnP and ZeroConf 12:19:30 ryosuke has joined #dap 12:19:35 ... ZeroConf is DNS SDP 12:19:46 ... this draft abstracts away the underlying discovery protocol 12:19:53 s/Network Service Discovery (NSD) API in Opera // 12:20:00 a12u has joined #dap 12:20:01 s|a/|a/ Network Service Discovery (NSD) API in Opera| 12:20:18 ... the way the communication works it's URL based 12:20:25 ... we've taken that as the underlying principle of this 12:20:33 ... we're sharing URLs to be able to control services on the network 12:20:43 ... when we have a URL, we can reuse the entire toolchain in browsers 12:20:49 ... we can send messages w/ XHR 12:20:50 Hidetoshi has joined #dap 12:20:53 ... you could use WebSockets 12:20:59 ... you could do webMessaging 12:21:05 ... it's a flexible thing 12:21:09 ... we get a lot for free w/ URLs 12:21:19 ... a lot of things we get for free are semantics 12:21:23 ... we can hook into Status codes 12:21:35 ... we want services using this to be able to hook into it with that level 12:21:41 ... the url we get can be used in many different ways 12:21:51 ... the spec today only allows XHR 12:22:01 ... we need XHR because UPnP requires HTTP headers 12:22:06 ... there's a special SOAP header 12:22:10 ... don't blame me, not my design 12:22:17 ... we need that ability, which is why we use XHR 12:22:40 ... UPnP is sending messages w/ HTTP, it could work 10 times and fail on the 11th 12:22:51 ... HTTP lets us catch that failed 11th w/ a timeout 12:22:57 ... it's prescriptive about what's allowed 12:23:02 ... it's not restrictive on what's allowed 12:23:09 ... it allows exposing a control point URL 12:23:14 ... you're aware of how you can use it 12:23:21 ... based on the service type that exposed it 12:23:27 ... one could be a WebSocket based service 12:23:32 ... i setup a websocket service 12:23:39 ... you could do UPnP over ZeroConf 12:23:48 ... there's AirPlay, iTunes advertise over ZeroConf 12:24:01 ... choose your messaging format, JSON, KeyValue pairs, whatever 12:24:05 ... based on the URL system 12:24:10 ... we can push URLs wherever 12:24:19 ... there's a mechanism to whitelist the URLs 12:24:21 q+ 12:24:26 q+ Josh_Soref to ask about lifetime for URLs 12:24:35 ... there's only one API 12:24:39 ... called getNetworkServices 12:25:06 q+ 12:25:08 ... that's the entire API, it's one method 12:25:16 ... it's important to minimize the impact on the DOM 12:25:34 ... you get back a DOM object 12:25:39 ... with lots of things 12:25:45 ... between calling this and getting a response 12:25:51 ... it goes through the UA/UI 12:25:56 q? 12:26:00 ... the UA makes the user opt in 12:26:03 ... before anything returns 12:26:04 q+ 12:26:08 ack gmandyam 12:26:12 ack gmandyam 12:26:14 GregBillock: going beyond mDNS and UPnP 12:26:21 ... we were thinking of other network service discovery 12:26:27 ... could reuse this spec 12:26:34 ... i didn't see rules for URL construction 12:26:41 ... you have examples for UPnP/ZeroConf 12:26:51 q- 12:26:52 ... is there's a schema for others? 12:26:55 richt: it's extensible 12:27:02 ... UPnP / ZeroConf aren't hard coded in 12:27:10 ... you could have your own discovery protocols 12:27:15 Geunhyung has joined #dap 12:27:17 yamaday has joined #dap 12:27:17 ... commonality is you get back a network service object 12:27:20 Present+ Naoyuki_Sato 12:27:29 q+ 12:27:29 ... how messaging works, you're requesting a specific service type 12:27:30 kensaku has joined #dap 12:27:43 gmandyam: but how does a UA know which SDP is being used? 12:28:08 richt: if you want to communicate from a web page to a resource, you must use an HTTP url 12:28:13 ... anything else will not work 12:28:17 ... XHR won't work 12:28:24 ... UDP resources wouldn't work 12:28:36 ... there's a lose binding between what you're requesting and the messaging 12:28:42 ... there's no rules beyond that 12:28:46 ... either HTTP or not 12:28:53 gmandyam: Caching discovery results? 12:28:58 ... do you have rules on freshness? 12:29:02 ... or is that up to UAs? 12:29:08 ... spec talks about not Caching 12:29:21 q+ 12:29:24 ... we've had feedback about allowing preferences for services user has previously selected 12:29:29 ... we hope to add that 12:29:33 ... similar to GeoLoc 12:29:50 s/... spec/richt: spec/ 12:29:59 gmandyam: for cellular, control point could be chatty 12:30:14 ... some companies clearly violate specs in enumerating remote directories 12:30:20 richt: there's a lot of stuff out of scope 12:30:26 ... this is a bootstrap 12:30:30 ... we prototyped this 12:30:34 ... we implemented it 12:30:42 ... we published a version of Opera with this 12:30:50 q? 12:31:22 richt: you have to switch it on in prefs, there's no ui 12:31:31 ... a few restrictions 12:31:35 ... only UPnP 12:31:38 ... two No UI 12:31:46 ... on via opera:config 12:32:03 ... UPnP was the delivery for our TV team 12:32:10 ... i see this as more for ZeroConf 12:32:17 q+ 12:32:20 ... "btw, you can use UPnP on the side" 12:32:31 ... both get abstracted to the same object 12:32:39 ... ZeroConf is interesting because it's lightweight 12:32:42 kawada has joined #dap 12:32:46 ... ZeroConf you can have JSON 12:32:53 ... I can show a live demo 12:32:58 topic: Opera Demo 12:33:08 richt: i've got a media server and xmbc on my mac 12:33:37 ... before, kensaku did a demo 12:33:44 ... now i'm browsing that media server 12:33:50 ... that should work 12:33:55 ... maybe not 12:34:05 kenji has joined #dap 12:34:16 gmandyam: there are implementations that query all the way down that directory tree 12:34:23 ... even though the user didn't select thaat 12:34:25 Kiyoshi has joined #dap 12:34:25 s/thaat/ 12:34:32 s/select/select that/ 12:34:51 ... now the demo is playing 12:35:03 ... i can control it in the app 12:35:08 ... this is similar to getUserMedia 12:35:13 ... you're responsible for more 12:35:19 ... you have more control 12:35:28 ... Intents is more the Media Capture 12:35:55 fjh: is this demo on your site? 12:36:20 [ richt plays music silently ] 12:36:27 naomi has joined #dap 12:36:30 Network Service Discovery (NSD) API in Opera -> http://dev.opera.com/articles/view/network-service-discovery-api-support-in-opera/ 12:36:35 giuseppe has joined #dap 12:36:45 richt: there are some restrictions here, it isn't perfect 12:36:55 RRSAgent, draft minutes 12:36:55 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html giuseppe 12:36:56 ... we're investigating how much we can do w/ this model 12:37:03 ... the api itself may change 12:37:10 ... we have lots of feedback online, offline 12:37:11 q? 12:37:19 ... we may change how the api's look/respond 12:37:26 ... we're trying to keep the underlying principles 12:37:33 ... this is a proposal in that direction 12:37:37 topic: Questions 12:37:39 ack Josh_Soref 12:37:39 Josh_Soref, you wanted to ask about lifetime for URLs 12:38:39 Josh_Soref: a problem HTML/MC/WebRTC/DAP had for URLs 12:38:43 ... was lifetime 12:38:53 ... ensuring the underlying resource could be GCd 12:39:03 richt: URLs have ways to say they expired 12:39:07 ... we can do a 404 12:39:08 q? 12:39:15 sunghan has joined #dap 12:39:27 ... at the point they're provided, they're live 12:40:04 Josh_Soref: i'm more worried about recycling of urls 12:40:09 richt: each message is separate 12:40:22 ... you aren't creating a dialog across multiple request/responses 12:40:30 ... i'm doing an action 12:40:35 ... if the resource changes/moves 12:40:39 ... and i hit a different resource 12:40:44 ... i'm performing an action on the new one 12:40:55 ... there's no concept of a session in this UPnP stuff 12:41:01 jfmoy has joined #dap 12:41:08 ryosuke has joined #dap 12:41:23 kotakagi has joined #dap 12:41:47 [ Concept of delete ] 12:42:02 richt: these services are meant to be interactive, but not with write support/delete 12:42:10 ... they might have update and create new things 12:42:17 ... you can't do that at the basic network level 12:42:25 ack GregBillock 12:42:33 GregBillock: cool richt 12:42:37 Wonsuk has joined #dap 12:42:40 ... i like using URLs as the interaction primitives 12:42:46 ... couple of q's looking through the spec 12:43:00 ... all relate to permission models 12:43:07 ... when user is connecting up client to services 12:43:12 ... how long lived is ... 12:43:16 ... what are the semantics 12:43:21 ... few ways this could work 12:43:27 ... one is that when i get a network service 12:43:37 ... i get permission to interact anything satisfying that query 12:43:44 ... or only one for that selected one 12:43:52 ... or i get back a geolocation style permission 12:44:00 ... what's the permissions model? 12:44:06 richt: beyond what we want to do in W3C spec 12:44:10 ... we don't want to restrict UI 12:44:19 ... there's a clear approach we have in mind 12:44:22 ... I request service type 12:44:29 ... UA searches "network" 12:44:36 ... finds devices with that service type 12:44:42 ... user is presented w/ that list 12:44:47 ... we don't authorize a service 12:44:52 ... we authorize to a device 12:44:59 ... "Google set top" 12:45:02 ... "PS3" 12:45:13 ... what page gets back is a specific binding for a service on a device 12:45:26 ... if i request 12:45:37 ... i can request a media renderer and an AV transport controller 12:45:46 ... (the api allows 2 requests at a time) 12:45:48 q? 12:46:01 ... the user can select the PS3 which fulfills both 12:46:06 shinichi has joined #dap 12:46:19 ... spec requires user opt in 12:46:32 GregBillock: does permission persist across page sessions? 12:46:35 richt: right now, no 12:46:45 GregBillock: so, right now i want to control PS3 now 12:46:50 .. and next time maybe something else? 12:47:00 richt: there might be a remember my preference option 12:47:09 ... we'd auto-fulfill the request the next time 12:47:32 ... we know if the service is online, offline 12:47:42 ... you could get back 3 offline objects 12:47:52 ... if there are devices still available 12:48:10 GregBillock: there's an overlap with the kind of service connection for web intents 12:48:19 ... the selection process is the same hook me up together with my stuff 12:48:25 ... my apps, tv tuner, router, whatever 12:48:28 ... we may want to 12:48:35 ... pick a division of labor between 12:48:39 hta has joined #dap 12:48:43 ... who's responsible for maintaining state of connections 12:48:46 zakim, who is here? 12:48:46 On the phone I see +1.781.362.aaaa, Salon_Pasteur 12:48:47 On IRC I see hta, shinichi, Wonsuk, kotakagi, jfmoy, sunghan, giuseppe, naomi, Kiyoshi, kenji, kawada, yamaday, Geunhyung, Hidetoshi, a12u, Shinji, nsakai, Yoshihiro, hiroki, 12:48:47 ... noriya, Claes, dnkim, nkic, Milan_Patel, opoto, sato, youenn, tomoyuki 12:48:57 zakim, aaaa is cathy 12:48:57 +cathy; got it 12:48:58 ... "where does the scan for wifi connection appear" 12:49:11 ... network services have updates 12:49:18 ... but if you want other services 12:49:28 ... they'd hit "show more networks" 12:49:40 ... in the client page? 12:49:53 ... is it a long lived permission across loads 12:49:56 ... or per task 12:50:09 trackbot has joined #dap 12:50:13 ... unlike geoloc permission 12:50:22 richt: it's about specific devices 12:50:29 ... there's no normative restrictions on how you do this 12:50:33 ... it's a UA design choice 12:50:45 ... remembering services only 12:50:50 ... it's a design choice 12:50:57 GregBillock: if the model is a persistent connection 12:51:07 ... it might make sense to expose network services object directly to page 12:51:32 ... the way it's written, it might not need that 12:51:35 q? 12:51:37 ack jcdufourd 12:51:40 jcdufourd: 4 questions 12:51:48 ... you have top in navigator 12:51:50 q? 12:51:51 ... is object live? 12:51:57 ... what about successive calls? 12:52:05 ... our indexes kept/do they change? 12:52:10 ... offline about exposing services? 12:52:19 richt: object is immutable 12:52:24 ... once given, it doesn't change 12:52:29 ... helps for more requests 12:52:34 ... new requests give new objects 12:53:00 jcdufourd: successive network services objects 12:53:04 ... if i have 3 objects 12:53:07 ... and a fourth appears 12:53:14 ... are the index id's the same or not? 12:53:19 richt: each object has an id 12:53:33 ... it's unique enough to identify it within the session 12:53:42 richt: network services is an array like object 12:53:57 jcdufourd: why in navigator? 12:54:10 richt: don't care about where it goes 12:54:18 ... parallel to getUserMedia 12:54:23 ... similar signature 12:54:33 ... same structure 12:54:37 ... we didn't put it on window! 12:54:43 ... but it's arbitrary, really 12:54:50 tpacbot has joined #dap 12:54:53 adrianba has joined #dap 12:54:53 ... this seems like a logical fit 12:54:59 fjh: we did this discussion before 12:55:04 richt: to death, think we have a note on it 12:55:36 richt: exposing services 12:55:44 ... not getting too far ahead of ourselves 12:55:54 ... we want to allow web pages to advertise itself on the network 12:55:58 ... don't know if we'll do it 12:56:15 ... navigator.registerNetworkService 12:56:26 ... give it an identifier, receive incoming requests 12:56:33 ... push requests 12:56:40 ... it'll be ZeroConf only 12:56:52 ... if you want to do UPnP service, there's a significant startup cost 12:57:09 ... entire structure in an xml file 12:57:20 ... we'll do DNS SD only 12:57:27 ... reuse HTTP/urls 12:57:32 ... we have a loopback address 12:57:39 ... if you only want to advertise to your address 12:57:43 ... i could use that 12:57:48 ... i could use my network ip 12:57:54 ... we've got public ip address as well 12:58:37 ... not just about web pages 12:58:47 ... i could advertise it to native apps too 12:58:48 q? 12:58:50 ack fjh 12:58:56 Zakim, close the queue 12:58:56 ok, timeless, the speaker queue is closed 12:58:58 q+ 12:59:16 jcdufourd: disagree about can't be done w/ UPnP 12:59:19 ... but i'll work on that 12:59:24 Zakim, open the queue 12:59:24 ok, timeless, the speaker queue is open 12:59:34 GregBillock has joined #dap 12:59:48 q+ GregBillock 12:59:53 Zakim, close the queue 12:59:54 jfmoy has joined #dap 12:59:54 ok, timeless, the speaker queue is closed 12:59:59 npdoty has joined #dap 13:00:06 fjh: what about confidentiality? 13:00:22 richt: i haven't seen UPnP services doing https 13:00:26 ... but we can argue it's a url 13:00:30 ack youenn 13:00:31 shoko_ has joined #dap 13:00:40 youenn: we're very interested in this api 13:00:47 ... first question 13:00:59 ... seems very tied to local network 13:01:04 ... is it related to local network 13:01:09 ... or is it related to privacy? 13:01:17 ... is it to avoid home-work network crossing? 13:01:27 richt: we have a Cross-Origin Resource Sharing 13:01:36 ... if that service opts in w/ HTTP headers 13:01:47 ... if a server allows it, we'll let sites do it 13:01:53 ... this spec allows Reverse CORS 13:01:57 ... user opts a site in 13:02:07 ... spec goes in to how we whitelist the url 13:02:12 ... for that user opted in service 13:02:18 ... and subresources 13:02:33 richt: it's part of the proposal 13:02:42 youenn: if you get an error, it can point to anything 13:02:57 ... in the spec, if you don't do upnp/zeroconf, you can get an error 13:03:09 richt: anything to be done will be done by UA 13:03:11 q? 13:03:20 richt: it's all local network 13:03:27 ... using loopback is local device 13:03:33 ... DNS SD does wide area discovery 13:03:47 ... my browser can look at dns when i go to google 13:03:50 ... or mozilla 13:03:56 ... and say there are services there too 13:04:11 ... it's part of what we're saying 13:04:23 youenn: we did experiments 13:04:30 ... enabling web as services 13:04:33 ... it's very useful 13:04:38 ... please continue this work 13:04:47 richt: please play w/ it, please give feedback 13:04:53 ... don't think this is all it is 13:04:53 I was going to ask, will you regret the name "NetworkServices" do you think? With the last couple questions? 13:04:57 .... UPnP is a sideeffect 13:05:07 s/GregBillock/scribe/ 13:05:17 s/I was/GregBillock: I was/ 13:05:23 Topic: Web Based Signage 13:05:41 RRSAgent, draft minutes 13:05:41 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html shan 13:05:53 hatano: Futomi Hatano, Newphoria Corporation 13:05:56 ... we're new to W3C 13:06:06 ... could the signage guys please join me 13:06:11 present+ Futomi_Hatano 13:06:21 ... i'd like to describe our requirements 13:06:29 ... we're discussing Requirements for Web Based Signage 13:06:33 Present+ Hiroyuki_Aizu 13:06:34 darobin has joined #dap 13:06:34 ... we collected many requirements 13:06:36 ... one relates to this WG 13:06:42 ... i'd like to describe our requirements 13:06:49 [ Requirement R5 ] 13:06:51 Present+ Shinji_Ishii 13:06:57 moystard has joined #dap 13:07:05 shoko_ has joined #dap 13:07:10 http://www.w3.org/community/websignage/ 13:07:19 [ UC 1 ] 13:07:30 hatano: view same document shown on signage terminal at office 13:07:41 fumitakaW_ has joined #dap 13:08:00 ... small display, big room 13:08:15 -> http://www.w3.org/community/websignage/wiki/Web-based_Signage_Use_cases_and_Requirements#R5._Discovered_by_personal_devices Web-Based Signage use cases and requirements, R.5 service discovery 13:08:19 ... colleagues find displays in the room 13:08:27 ... which can then display the app 13:08:28 s/UPnP is a sideeffect/UPnP is only one aspect of this API. I believe that Zeroconf is a much more flexible discovery protocol and will spur a lot of innovation. but, btw, you can also do UPnP./ 13:08:30 [ UC 2 ] 13:08:58 hatano: viewer can't reach the displays showing display 13:09:01 Thanks! dom 13:09:03 q+ 13:09:07 ... viewer pulls out phone 13:09:17 ... phone finds Signs nearby 13:09:19 open queue 13:09:23 q+ 13:09:31 ... lets viewer see what's displayed on Sign 13:09:37 [ Motivation ] 13:09:44 Zakim, open the queue 13:09:44 ok, timeless, the speaker queue is open 13:09:45 zakim, open queue 13:09:45 ok, adrianba, the speaker queue is open 13:09:47 q+ fjh 13:09:53 q- GregBillock 13:10:02 s/open queue// 13:10:19 Travis has joined #dap 13:10:19 [ Gap analysis ] 13:10:23 shige has joined #dap 13:10:37 hatano: we found Web Intents and Network Service Discovery 13:10:44 ... we'd like to know if they satisfy our requirements 13:10:47 q? 13:11:10 richt: um 13:11:17 q+ 13:11:17 ... i was talking about wide area service discovery 13:11:27 q+ to talk about captive networks and routing problems 13:11:30 sangwhan has joined #dap 13:11:31 q- timeless 13:11:37 q+ Josh_Soref to talk about captive networks and routing problems 13:11:50 fjh: could you discover these signs with a web application? 13:11:56 it will be difficult on a typical WAN to access signs that are inside a CDN service domain 13:12:24 bryan: typically there's a firewall 13:12:34 richt: isn't this kensaku's demo? 13:12:44 bryan: typically there's a service provider network 13:12:48 dom: that's the case currently 13:12:53 ... but if there's a value to exposing them 13:13:00 Travis has left #dap 13:13:00 q+ 13:13:02 bryan: so it's more than exposing devices 13:13:15 dom: i'm in this mall 13:13:25 ... using WiFi network that's being provided for free 13:13:31 GregBillock, we may come to regret the naming 'NetworkServices'. Didn't want to use 'Services' though so... 13:13:32 ... i'm in a position to discover nearby screens 13:13:36 ... i see things nearby 13:13:42 Hidetoshi has joined #dap 13:13:43 ... i can discover screen 13:13:51 ... get information related to what the screen shows 13:13:52 kinji has joined #dap 13:13:56 Travis has joined #dap 13:13:58 Takahiro has joined #dap 13:14:09 shiyo: yes 13:14:12 bryan: i think it is 13:14:20 s/shiyo/shigeo/ 13:14:23 ... if you're at a meeting room of a conference on a lan 13:14:30 dom: some of this is beyond scope 13:14:34 ... network topology 13:14:49 ... but we can assume some topologies where you want to discover devies 13:14:54 s/devies/devices/ 13:15:17 ... an interesting exercise would be to see how much of the UCs offered can be enabled by the apis 13:15:25 richt: a service that allows me to discover it 13:15:31 ... maybe there's a queue 13:15:36 ... or a way to give auth to project 13:15:46 ... enable users in room to connect to service 13:15:50 ... i think this is absolutely in scope 13:15:58 ... this requires server side innovation 13:16:02 q? 13:16:09 ack fjh 13:16:13 fjh: maybe for some portion of it 13:16:30 ... in some cases, this may work straightforwardly 13:16:36 ... in some cases external changes may be needed 13:16:48 ... in some cases w/ Local network, it might just work w/o much effort 13:16:56 ... in some cases, there may be some constraints 13:17:31 hatano: thank you for your time 13:17:32 q= 13:17:39 queue= 13:17:58 [ Signage guys leave ] 13:19:40 jbourhis has joined #dap 13:20:51 a1zu has joined #dap 13:22:31 kenji has left #dap 13:23:34 hiroki has joined #dap 13:23:35 tokamoto has joined #dap 13:25:07 kawada has joined #dap 13:26:14 kawada has left #dap 13:26:18 nwidell has joined #dap 13:26:23 agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France 13:26:25 kinji has joined #dap 13:26:28 timeless has changed the topic to: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France 13:26:35 topic: Agenda Review 13:26:41 fjh: Pick Contact 13:26:44 ... Pick Media 13:26:46 ... Break 13:26:49 ... CoreMob update 13:27:20 ... Media Capture / Streams 13:27:32 RRSAgent, draft minutes 13:27:32 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 13:27:49 moystard has joined #dap 13:27:51 ... Calendar 13:27:58 ... Issues + Action Review 13:28:44 ... Sensors 13:28:50 s/CoreMob/Testing + CoreMob/ 13:29:16 hta: I have an item 13:29:21 ... i'm leaving @ 3:15pm 13:29:32 sangwhan has joined #dap 13:29:38 sangwhan1 has joined #dap 13:30:02 topic: Media Capture / Streams 13:30:12 fjh: great work, thanks 13:31:40 [ Update from Media Capture Task Force ] 13:31:42 kotakagi has joined #dap 13:31:49 Travis: Travis Leithead 13:31:51 ... just a brief update 13:31:59 ... i'll send a link to the slides to the DAP ML later 13:32:09 ... not going to talk about HTML MC 13:32:14 ... not going to talk about WebRTC document 13:32:22 ... (sorry about the blue text) 13:32:30 Claes has joined #dap 13:32:32 ... MC TF is looking at 4 documents since last year's TPAC 13:32:38 ... 1. Media Stream Captures Scenarios 13:32:58 ... 2. getUserMedia "Media Capture and Streams" 13:33:11 ... 3. Track Enhancements and snap photos 13:33:15 ... 4. XXQ 13:33:23 Topic: MediaStream Capture Scenarios 13:33:30 Travis: it describes 6 scenarios 13:33:35 ... photo + audio capture 13:33:40 ... video + audio together 13:33:43 ... streamed 13:34:01 ... retrieve modify camera capabilities / switch cameras 13:34:06 ... pause resume capture 13:34:09 ... peer to peer streaming 13:34:21 ... - Issues 13:34:28 ... we'll remove "design considerations" 13:34:40 ... by converting them into Requirements/enhancing Scenarios 13:34:42 Shinji has joined #dap 13:34:47 ... many things in there are addressed by TF 13:34:56 Topic: Media Capture and Streams (getUserMedia) 13:35:11 Travis: we now have a complex first parameter (constraints) 13:35:22 ... getUserMedia(constraints, successCallback, failureCallback) 13:35:29 ... constraints have ordered optional constaints 13:35:35 ... and mandatory constraints 13:35:46 ... UA will evaluate constraints and decide what you could be given 13:35:56 ... MediaStream object is defined in spec 13:36:04 ... used for RealTime Streaming and Local capture 13:36:08 ... separate audio/video tracks 13:36:11 ... concept of generic track 13:36:16 ... - Issues 13:36:20 ... slightly underspecified 13:36:47 ... directly assigned to video elements or view URL.createObjectURL() 13:36:52 s/DNS SDP/DNS-SD/ 13:36:53 ... -- lifetime issues 13:37:08 Topic: Settings API (proposal) 13:37:30 Travis: puts control at Track level 13:37:34 ... instead of stream 13:37:43 ... we split tracks into distinct kinds 13:37:49 ... video, audio, camera, microphone 13:38:05 ... settings/capabilities live on tracks 13:38:10 ... drops Local Media Stream 13:38:16 ... defines Take Picture API 13:38:20 ... provides a device list 13:38:28 ... - Issues 13:38:38 q+ 13:38:40 ... Applying settings via an interesting api path 13:38:51 ... may want to move closer to constraints model 13:39:00 ... Privacy/Fingerprinting implications of device list 13:39:10 ... making it into reality is tricky 13:39:22 Topic: Recording API (proposal) 13:39:33 JonathanJ1 has joined #DAP 13:39:48 ... g 13:39:53 s/g/get data at end/ 13:39:56 ... get data incrementally 13:39:59 ... - Issues 13:40:05 ... track level v. Stream 13:40:10 ... Audio/Video together? 13:40:14 ... Group would like them together 13:40:27 ... complications involving MediaStreams and recording 13:40:30 ... state machine 13:40:35 ... adding/removing tracks to/from a Stream 13:40:44 JonathanJ1 has joined #DAP 13:40:47 ... or dynamic setting changes (resolution) 13:40:53 ... Container format constraints 13:41:18 bjkim has joined #dap 13:41:23 fjh: refactoring Tracks looks good 13:41:29 ... for Privacy/Fingerprinting discussion 13:41:34 ... should we involve PING? 13:41:44 ... if someone from TF could join a PING call 13:41:51 ... it might help resolve it 13:41:52 kotakagi has joined #dap 13:41:56 Travis: +1 13:42:09 ... someone from TF should set that up 13:42:10 s/how does a UA know which SDP/how does a UA know which control protocol/ 13:42:14 Kiyoshi has joined #dap 13:42:17 hta: chairs will take it under advisement 13:42:25 ... we attended XXE 13:42:35 ... some people say if you can run JS, it's game over 13:42:41 ... not everyone has given up yet 13:42:58 fjh: PING is the privacy people 13:43:04 q? 13:43:06 ack fjh 13:43:14 Travis: talking to them, seeking their advice may not be entirely wasted 13:43:20 q? 13:43:28 fjh: anything DAP needs to do? 13:43:29 [I think the risk with listing devices is not only a fingerprinting issue http://lists.w3.org/Archives/Public/public-media-capture/2012Oct/0047.html ] 13:43:47 Travis: i think we're ok 13:43:51 shepazu has joined #dap 13:44:18 fjh: join Media Cap TF/ML 13:44:26 dom: at session on Wednesday 13:44:30 ... there was a discussion 13:44:39 giuseppe has joined #dap 13:44:45 Travis: very interesting discussions 13:44:52 ... my presentation didn't capture the latest thinking 13:45:07 s/Wednesday/Tuesday afternoon 13:45:15 hta: we found cases where we couldn't wait for response from users 13:45:25 s/a discussion/a discussion that might lead to fairly important changes to getUserMedia 13:46:46 topic: Pick Contacts 13:46:54 fjh: did the CfC for removing search 13:46:56 naomi has joined #dap 13:47:01 PROPOSED RESOLUTION: Keep search 13:47:30 Jungkee: i think we reached a consensus 13:47:47 contact search option: http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html#idl-def-ContactIntentExtras 13:48:00 media search option: http://dvcs.w3.org/hg/dap/raw-file/tip/gallery/Overview.html#idl-def-MediaIntentExtras 13:48:05 q? 13:48:06 q? 13:48:07 Josh_Soref: i want to change the property to be searchHint 13:48:13 q+ 13:48:38 nwidell: we moved extras from Intents 13:48:44 ... where's the replacement? 13:48:56 Jungkee: i think we add the attributes in the Intent 13:49:04 tomoyuki_ has joined #dap 13:49:29 GregBillock: you put it in the Intent object 13:49:45 q? 13:49:47 RRSAgent, draft minutes 13:49:47 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html giuseppe 13:49:47 ack nwidell 13:50:12 ... but extras disappeared 13:50:29 GregBillock: i'd put the metadata in the type itself 13:50:37 q? 13:50:57 s/type/data schema/ 13:51:28 GregBillock has joined #dap 13:52:14 -> http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#widl-Intent-data data field in Intent object 13:52:20 So new Intent({ action: x, type: y, data: { query_info: { fields: ["displayName", ...], query: "query_hint" } } }) 13:53:04 MyNickName has joined #dap 13:53:37 so that means dictionary Contact { ... ContactIntentExtras? query_hints } 13:54:50 new Intent({ action: "http://intents.w3.org/pick", type: "http://intents.w3.org/type/contact", data: { fields: ["displayName", "emails"] }}); 13:55:05 LGTM 13:55:29 PROPOSED RESOLUTION: field and searchhint move to data 13:55:39 propose RESOLUTION: retain search in Pick Contacts using a dictionary in the data for this information 13:56:04 PROPOSED RESOLUTION: Pick Contacts using dictionary in for searchhint and field restrictions 13:56:12 q+ 13:56:18 ack nwidell 13:56:41 noriya has joined #DAp 13:56:52 nwidell: search or filter? 13:56:57 Jungkee: two capabilities 13:57:07 ... 1. who they're looking for (roughly) 13:57:14 ... 2. what they want to know about that entity 13:57:30 +1 to proposed resolution 13:57:33 PROPOSED RESOLUTION: Pick Contacts and Pick Media using dictionary in for searchhint and field restrictions 13:57:43 PROPOSED RESOLUTION: Pick Contacts and Pick Media using dictionary for searchhint and field restrictions 13:57:58 PROPOSED RESOLUTION: Pick Contacts and Pick Media using dictionary for searchhint and field restrictions (field on media if applicable) 13:58:08 RESOLUTION: Pick Contacts and Pick Media using dictionary for searchhint and field restrictions (field on media if applicable) 13:58:16 [ Break ] 13:58:48 Travis_ has joined #dap 13:59:17 RRSAgent, draft minutes 13:59:17 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html shan 13:59:42 -cathy 14:00:10 nsakai has left #dap 14:03:26 tomoyuki_ has joined #dap 14:07:47 nwidell has joined #dap 14:09:02 shepazu has joined #dap 14:12:23 Takahiro has joined #dap 14:13:35 Geunhyung has joined #dap 14:19:39 Travis_ has joined #dap 14:19:48 nwidell has joined #dap 14:24:10 Wonsuk has joined #dap 14:25:53 Hidetoshi has joined #dap 14:26:31 jfmoy has joined #dap 14:35:30 tomoyuki_ has joined #dap 14:35:52 rrsagent, generate minutes 14:35:52 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html fjh 14:37:22 Yoshihiro has joined #dap 14:37:26 Topic: HTML Media Capture 14:37:30 I checked with the W3C team - we can publish a LC even during an exclusion period, no problem. 14:38:22 hiroki has left #dap 14:38:51 Topic: Pick Media Intent 14:39:35 metadata: http://dvcs.w3.org/hg/dap/raw-file/tip/gallery/Overview.html#metadata-properties 14:39:49 bjkim has joined #dap 14:39:49 scribenick: bryan 14:40:05 q+ 14:40:08 q= 14:40:11 q- 14:40:17 Jungkee: would like to get feedback on the list on this link, after the F2F 14:40:28 q+ to ask if this metatdata has been defined as standard elsewhere as to meaning 14:41:17 ... want to explain the criteria 14:41:32 ... considered a number of platforms and services 14:41:42 +cathy 14:41:54 ... group review on the metadata definition, with feedback is requested 14:41:54 q+ 14:42:06 ack fjh 14:42:07 fjh, you wanted to ask if this metatdata has been defined as standard elsewhere as to meaning 14:42:30 fjh: see you have picked the core from the metadata of different specs 14:43:15 Jungkee: refer to a core set of media ontology specs 14:43:38 ... media ontology core has 29 properties, most included here 14:43:49 ... som core properties are not used in real life 14:44:01 -cathy 14:44:01 ... those have been excluded 14:44:02 http://www.w3.org/TR/mediaont-10/#core-property-lists 14:44:23 +cathy 14:44:35 q? 14:44:51 ack gmandyam 14:45:08 Gmandyam: why did you not go with an approach like Tizen media content? 14:45:30 Jungkee: in Tizen 2.0 we dropped a lot of the media metadata functionality 14:45:47 ... we just need some practical properties used in real life 14:46:24 robint has joined #dap 14:46:28 Gmandyam: it would be desirable for sysapps to reference an actual spec (they are looking to the Tizen media spec) 14:46:33 Takahiro_ has joined #dap 14:46:57 ... would like to bring this to SysApps for possible use in the gallery API to be done there 14:47:23 ... Google has an exploratory API, Mozilla has one also 14:47:27 q? 14:47:32 tomoyuki has joined #dap 14:49:46 q+ 14:49:52 ack nwidell 14:50:41 bryan: is there a similar prevalent metadata spec for media as Vcard is for contacts? 14:51:00 richt: the mozilla version has a slightly different list 14:51:41 ... we should avoid a long process since we will never get it right anyway 14:51:55 Jungkee: we will try to align the data as much as possible 14:52:15 richt: another approach is just to define a container, and not define the details 14:52:16 nsakai has joined #dap 14:52:31 bryan: do you need a format attribute 14:53:04 richt: no, it would be a JSON object 14:53:25 ... developers want to have agreement and to do it themselves 14:54:25 nwidell: given this will be behind web intents, should be ensure the attributes are consistent with what is typically used in other intents? 14:54:51 Jungkee: that's where I need feedback. I tried to abstract some of the properties 14:55:44 ... it will be a more practical approach e.g. in section 5.x in which you can extend the dictionary with a prefix 14:56:20 ... in the demo it gets a practical (actually used) data as examples 14:56:52 topic: interop & testing 14:57:09 dom: there are some discussions on structure of the repository 14:57:46 ... that is being revised in the testing IG, and changes in how tests are approved may result 14:58:07 s/developers want to have agreement and to do it themselves/developers want to have agreement and to do it themselves. It's in their interest to agree on a structure but this DAP group has previously rejected this approach./ 14:58:37 ... these are W3C-wide discussions, but what matters is implementing, writing, and reviewing tests 14:58:37 kotakagi has joined #dap 14:58:51 ... key is focusing on getting to CR 14:59:06 topic: CoreMob update 14:59:47 Gmandyam: (introduces CoreMob) 15:00:07 ... F2F in London in Oct, with a few results 15:00:23 ... http://rng.io 15:00:23 Wonsuk has left #dap 15:00:35 ... is the URI for Ringmark 15:01:10 ... initially looking at converting Ringmark into conformance specs, the group is revisiting that with use cases and reqs 15:01:47 q+ 15:01:54 ... no draft of that yet, hopefully use cases that are complementary will result 15:02:19 ... other things of interest, the group is going back to FB's original research 15:02:32 ... a pretty good set of data 15:03:02 ... we will not be targeting performance for the 1st release, CoreMob 2012 15:03:24 fjh: why go back to use cases and requirements? 15:03:45 Kiyoshi has joined #dap 15:03:57 Gmandyam: it was a mistake, using Ringmark as the basis, as they had to justify the Ring 0 vs Ring 1 etc 15:04:11 ack fjh 15:04:14 q? 15:04:23 ... Ringmark is useful but we needed more care in the criteria 15:04:42 s/Gmandyam:/gmandyam:/ 15:05:16 Josh_Soref: they went back as the UC & Reqs weren't developed, and there was no explanation of where they had arrived 15:05:37 ... this was a big lesson, to document the problem being addressed 15:05:58 ... Ring 0 vs 1 was a side topic 15:06:35 ... FB contributed the research, but we focused on the Ringmark tests instead, and that side-trcked us from the useful things 15:06:56 ... so the initial input (their analysis) got buried 15:07:22 ... and the chain of relevance was not defined 15:07:39 ... organization issues also got in the way 15:08:07 fjh: what's the plan with DAP, will they be included some time? who makes that happen? 15:08:28 s/trcked/tracked/ 15:09:05 dom: DAP does not have to worry or do it. DAP may need to answer queries as to the APIs that have been defined per CoreMob priorities 15:09:13 smaug has joined #dap 15:09:42 Josh_Soref: e.g. it was found there were no real-world use cases for the battery API 15:10:17 ... the original idea was to build upon the lower rings but the specs are not dependent in the way that supports that 15:10:48 ... probably will address the use cases individually 15:11:05 bryan: the HTML Media Capture was listed as a key API 15:11:23 shepazu has joined #dap 15:11:31 bryan: one UC was capturing of images and file upload 15:11:34 s/timeless/scribe/ 15:11:44 bryan: that was the one API listed by coremob 15:11:45 s/timeless/scribe/ 15:12:13 topic: sensors 15:12:47 ?Q 15:12:50 s/?Q// 15:12:51 q? 15:12:59 Zakim, open the queue 15:12:59 ok, timeless, the speaker queue is open 15:13:21 q+ Josh_Soref 15:13:33 nwidell: 1 year ago we discussed sensor APIs and there was a decision to move ahead with Web Intents based sensors, until the DOM based sensor proposals came from Mozilla 15:13:59 virginie_ has joined #dap 15:14:07 ... are we interested in local network sensors? the Web Intents approach did not seem to work out 15:14:23 ... the other case was doing everything yourself 15:14:52 q+ 15:14:53 fjh: not sure what us being asked for 15:15:20 nwidell: a generic sensor API is in the charter, and there are a lot of use cases for sensors not on the device 15:15:23 q+ Josh_Soref to talk about sensors in Cars 15:15:29 -cathy 15:15:39 q? 15:15:43 Zakim, who's on the call? 15:15:43 On the phone I see Salon_Pasteur 15:15:43 ... these might be discoverable via some networking; also use cases for sensors in the car 15:15:46 q+ 15:16:06 q+ richt 15:16:11 ... on the browser side, this would have to be a generic API 15:16:25 -Salon_Pasteur 15:16:26 Team_(admin)12:11Z has ended 15:16:26 Attendees were +1.781.362.aaaa, Salon_Pasteur, cathy 15:16:50 richt: the 1st step is use cases, then we agree, but network service discovery could be useful for the networked sensors use cases 15:18:02 ... there are a lot of use cases for networked sensors 15:18:05 +1 to documenting use cases to understand the approach 15:18:10 ... e.g. (showing use cases) 15:18:55 ... fitness, devices without integrated sensors (as users of externa sensors), home sensors 15:19:17 ... we can't connect all the dots, but we can provide a framework for the client side 15:19:38 ... since the Web is maturing as a platform, providing these adapters is a good thing 15:19:47 q? 15:20:08 q? 15:20:14 ... 1st though is whether there is a priority in anything beyond device-local sensors 15:20:18 q+ Claes, gmandyam, richt 15:20:26 q+ Josh_Soref to talk about sensors in Cars 15:20:38 ack Josh_Soref 15:20:38 Josh_Soref, you wanted to talk about sensors in Cars 15:21:21 Josh_Soref: W3C is wrapping up a car-focused activity; we are also having people talking about running apps anywhere 15:21:45 ... the phone might be in the glove box or a dock, displaying on the car screen 15:21:48 josh_soref: also about displaying anyway, like signage 15:22:36 ... if the phone is in the glove box and it's dark, the phone can't use its own sensor, and the car may need to provide the sensor for this case 15:23:10 ... it would be nice for the phone to be able to use the car screen, and the car's light sensor 15:23:29 ... I see a need for this, and considering how Intents mght enable this 15:24:12 ... re the roadmap for the car stuff, it may be a bit longer as the lifecycle and time to market is longer 15:24:24 q? 15:24:42 ack Claes 15:24:43 s/wrapping/ramping/ 15:24:52 Claes: I wanted to say the same things 15:25:21 ack gmandyam 15:25:21 ... I think we shoud start on this 15:25:53 rrsagent, generate minutes 15:25:53 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html fjh 15:26:04 Gmandyam: it's good to take a step back, consider alternatives, e.g. HTTP to COAP mapping. what's nice is no change in the browser 15:26:35 ... it would be good to take a step back and explain why other industry efforts are insufficent 15:26:46 richt: a number of issues need to be discussed first 15:27:08 ... discovery, configuration, interaction (an interface available)? 15:27:28 ... without this, it is purely theoretical 15:27:31 s/COAP/CoAP/ 15:27:49 ... the UPnP specs provide nothing, some lighting and HVAC 15:28:01 -> http://en.wikipedia.org/wiki/Constrained_Application_Protocol CoAP 15:28:06 s/timeless/gmandyam/ 15:28:17 ... is the remote sensors industry ready for this? there is a lot of underlying work needed first 15:29:10 q+ 15:29:14 ack r 15:29:19 nwidell: this is a rapid developer market, mapping to technolgies may not be clear, but it would be good to have this on the agrenda 15:29:22 -> http://en.wikipedia.org/wiki/Machine_to_machine M2M 15:29:26 s/timeless/nwidell/ 15:29:38 Hidetoshi has joined #dap 15:29:56 richt: there is a lot to be done outside the Web, and that isn't happening 15:30:02 adrianba has left #dap 15:30:03 nwidell: it is happening 15:30:33 dom: it's clear that its coming and we should be ready, but that it's preliminary 15:30:34 npdoty has joined #dap 15:30:46 s/its coming/it's coming/ 15:31:26 s/there is a lot to be done outside the Web, and that isn't happening/there is a lot to be done outside the Web, and that is not ubiquitous today./ 15:31:33 ... the big picture of the need for standards needs to clearer 15:32:00 nwidell: we sure dont want one web solution per underlying technology 15:32:20 dom it is too early for specification work, but worthwhile to understand ecosystem and environmnet 15:32:41 Josh_Soref: re monitors, they are using Bluetooth or USB, probably serial protocols 15:33:12 ... I assert that there is an app running on those systems that implements the proprietary protocol 15:33:34 ... a local service may be running which is exposable via intents 15:33:57 richt: that seems somewhat hacky; someone needs to do the normalization work 15:34:14 ... a lot of work needed outside the Web and W3C first 15:35:33 dom: my view is that this will soon be fundamental and I hope the Web can be part of that space 15:35:56 dom: I would suggest a landscape document 15:36:19 +1 15:36:22 whatever you invent, make it discoverable. 15:36:25 s/dont/don't/ 15:38:43 bryan: i gave a presentation recently at OMA re this, an the result was that these are very interesting (for mHealth) but we probably need some time for the basic market to develop 15:39:32 dom: the landscape document would help establish what is out there, what is compatible with the Web platform, etc 15:39:38 you need to want to be part of the web. Requiring proprietary middleware to talk to proprietary sensors over USB is not an indication you (*) want to be a part of the web right now. 15:39:43 * = sensors. 15:39:45 nwidell: discovery, registration, communication problems need to be solved first 15:40:07 ... this space is big/diverse/fast 15:40:11 q? 15:40:16 ack me 15:40:17 ack dom 15:41:48 nwidell: happy to take an action, but if we don't intend to do anything it may be a waste of effort 15:42:08 action: nwidell to provide draft sensors landscape document 15:42:09 Created ACTION-592 - Provide draft sensors landscape document [on Niklas Widell - due 2012-11-09]. 15:42:19 dom: if we don't get the information needed, we surely won't be doing anything 15:43:17 http://www.openmobilealliance.org/comms/documents/bangkok_presentations/OMA%20Healthcare%20Workshop%20-%20A%20Web%20of%20mHealth%20Devices.pptx.pdf 15:43:51 topic: calendar API 15:44:16 Cathy has joined #dap 15:44:30 fjh: we don't seem to be able to move this forward, due to the extended discussions around contacts 15:45:16 bryan: I agree we should get one good intent out the door as a model first 15:45:42 bjkim has joined #dap 15:46:43 fjh: the calendar recurrence model still seems an issue, we had other problems, etc that have not been addressed in the earlier versions 15:47:17 tokamoto has joined #dap 15:47:34 dom: we can consider the next F2F 15:47:48 fjh: we were in Mass last time 15:49:19 dom: we can't make a decision now, but early April or March might be OK, will consider via an action 15:49:53 ACTION: dom to build a survey for finding a week for DAP meeting March/April 15:49:53 Created ACTION-593 - Build a survey for finding a week for DAP meeting March/April [on Dominique Hazaël-Massieux - due 2012-11-09]. 15:50:47 Topic: Actions 15:50:49 action-588: I checked with the W3C team - we can publish a LC even during an exclusion period 15:50:50 ACTION-588 Review exclusion period for Ambient light notes added 15:51:01 close ACTION-588 15:51:01 ACTION-588 Review exclusion period for Ambient light closed 15:51:27 RRSAgent, draft minutes 15:51:27 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html dom 15:51:36 Topic: Other Business 15:52:30 thank you everyone for a productive F2F. Thanks to the scribes, Josh, Bryan, Rich, Giusseppe 15:52:39 tokamoto has joined #dap 15:52:39 rrs, generate minutes 15:52:55 s|rrs, generate minutes|| 15:53:06 rrsagent, generate minutes 15:53:06 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html fjh 15:56:11 Cathy has left #dap 15:58:45 Yoshihiro has left #dap 16:05:15 kotakagi has joined #dap 16:06:47 Takahiro has joined #dap 16:07:12 kotakagi2 has joined #dap 16:07:28 Present- +1.781.362.aaaa 16:08:15 Present+ Travis_Leithead 16:09:55 Present+ Nick_Doty 16:10:23 Present+ Cathy_Chan 16:11:59 shige__ has joined #dap 16:12:24 Present+ Marcin_Hanclik 16:14:18 Present+ Rigo_Wenning 16:16:08 Present+ GregBillock 16:16:11 RRSAgent, draft minutes 16:16:11 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 16:16:56 s/kensatu:/kensaku:/g 16:17:11 s/jungkee:/Jungkee:/g 16:17:15 npdoty has joined #dap 16:17:28 s/Gmandyam:/gmandyam:/g 16:17:42 fjh has joined #dap 16:17:55 present+ Christine_Runnegar 16:17:58 RRSAgent, draft minutes 16:17:58 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 16:18:01 npdoty has joined #dap 16:18:41 present- cathy 16:18:52 present- Salon_Pasteur 16:20:16 s/cristine:/christine:/g 16:21:33 s/... get data at end/Travis: get data at end/ 16:21:47 RRSAgent, draft minutes 16:21:47 I have made the request to generate http://www.w3.org/2012/11/02-dap-minutes.html timeless 16:23:30 npdoty has left #dap 16:33:36 naomi has joined #dap 17:01:53 MikeH has joined #dap 17:10:18 kensaku has joined #dap 17:14:00 smaug has joined #dap 17:17:31 smaug has left #dap 17:46:40 naomi has joined #dap 17:56:31 leetv has joined #dap 20:42:21 tokamoto has joined #dap 20:56:50 bjkim has left #dap 21:54:38 bjkim has joined #dap 21:59:16 jsoh has joined #dap 22:18:35 kensaku has joined #dap 23:05:16 bjkim has left #dap 23:48:02 plinss has joined #dap