09:50:14 <RRSAgent> RRSAgent has joined #wot-di
09:50:14 <RRSAgent> logging to http://www.w3.org/2016/01/27-wot-di-irc
09:50:18 <Zakim> Zakim has joined #wot-di
09:54:50 <mdadas> mdadas has joined #wot-di
09:54:59 <mdadas> present+ Mohammed
09:55:23 <Soumya> present+ Soumya
10:08:37 <tidoust> tidoust has joined #wot-di
10:08:45 <tidoust> RRSAgent, draft minutes
10:08:45 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/27-wot-di-minutes.html tidoust
10:08:49 <dom> dom has joined #wot-di
10:09:06 <tidoust> RRSAgent, make logs public
10:09:35 <Arne_Broering> Arne_Broering has joined #wot-di
10:09:51 <tidoust> Meeting: WoT IG F2F - Discovery TF breakout
10:09:57 <tidoust> Chair: Soumya
10:11:13 <tidoust> Scribe: Francois
10:11:17 <tidoust> ScribeNick: tidoust
10:11:24 <tidoust> Present+ Francois_Daoust
10:11:30 <tidoust> RRSAgent, make logs public
10:11:33 <tidoust> RRSAgent, draft minutes
10:11:33 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/27-wot-di-minutes.html tidoust
10:11:57 <tidoust> Soumya: Different topics to discuss today. First one is to finalize the tech landscape
10:12:04 <dom> -> https://www.w3.org/WoT/IG/wiki/Discovery_Categories_and_Tech_Landscape Discovery Categories and Tech Landscape
10:12:31 <tidoust> ... So far, we have 6 categories, each of them listing technologies.
10:12:56 <tidoust> ... For each technologies, we identified the base technology, and other properties such as the maximum range where applicable.
10:13:08 <tidoust> ... So far, this particular wiki looks complete.
10:13:29 <tidoust> ... It would be good to port it to GitHub, as part of the deliverable we're going to submit for this Task Force.
10:13:41 <tidoust> ... Do you see other technologies?
10:14:59 <tidoust> Francois: Thinking about the Push API, now implemented in some Web browsers.
10:15:06 <tidoust> Soumya: Category could be "searching in Directories".
10:15:31 <tidoust> ... For battery-based devices, the Push API could be of interest.
10:16:12 <tidoust> Arne: The list looks good to me.
10:17:02 <tidoust> Soumya: In that case, I would suggest to freeze the Wiki for one week and transition it to the GitHub doc.
10:17:30 <romain> romain has joined #wot-di
10:17:38 <tidoust> Soumya: Second point about the interaction patterns.
10:17:57 <tidoust> ... Lists interaction workflows for the different categories.
10:17:58 <dom> -> https://github.com/w3c/wot/blob/master/TF-DI/Interactions.md WoT Discovery Interaction Patterns
10:18:23 <tidoust> ... This is also complete that we could merge with the previous document.
10:18:34 <tidoust> ... The two together would form the technology landscape survey
10:18:39 <dom> -> https://www.w3.org/WoT/IG/wiki/Tech_Landscape_Evaluation Tech Landscape Evaluation
10:18:50 <tidoust> ... Then we come to the Tech Landscape Evaluation
10:19:09 <tidoust> ... In Sapporo, we came up with a list of criteria to evaluate each technology.
10:19:57 <tidoust> ... Examples are the interaction pattern, or the mention of lifetime / sleepy nodes, whether there is support for local/remote discovery of things.
10:20:10 <tidoust> ... We haven't looked at the richness of query yet, but should do yet.
10:20:39 <tidoust> ... One thing we understood is that not all criteria are applicable to all technologies
10:21:57 <tidoust> ... Take category 1, UriBeacon, there are no ranking of results, also the discovery is triggered by manual interaction.
10:22:28 <tidoust> Mohammed: As we want to compare the technologies, we should keep the 8 criteria and explain why some of them are not applicable.
10:22:47 <tidoust> ... It's clearer if we have the same criteria for all technologies.
10:22:59 <tidoust> Soumya: OK, thanks for the feedback.
10:23:27 <tidoust> ?1: If we find more technologies, can we amend the list?
10:23:44 <tidoust> Soumya: Sure!
10:23:57 <tidoust> ?1: For example, I'm thinking about Wifi beacn.
10:24:35 <tidoust> s/?1/Andrew/g
10:25:53 <tidoust> ACTION: Soumya to include the Wifi beacon technology in the tech landscape
10:25:54 <trackbot> Error finding 'Soumya'. You can review and register nicknames at <http://www.w3.org/WoT/IG/track/users>.
10:26:13 <tidoust> ACTION: Francois to provide text on the Push API for inclusion in the tech landscape
10:26:13 <trackbot> Created ACTION-23 - Provide text on the push api for inclusion in the tech landscape [on François Daoust - due 2016-02-03].
10:26:49 <dom>  ACTION: Soumya to include the Wifi beacon technology in the tech landscap
10:26:55 <dom> ACTION: Soumya to include the Wifi beacon technology in the tech landscap
10:26:55 <trackbot> Created ACTION-24 - Include the wifi beacon technology in the tech landscap [on Soumya Kanti Datta - due 2016-02-03].
10:27:00 <Soumya> rrsagent, draft minutes
10:27:00 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/27-wot-di-minutes.html Soumya
10:27:38 <tidoust> Soumya: Do you all agree about keeping the same set of criteria for all technologies?
10:27:42 <tidoust> [no objection]
10:28:18 <tidoust> Soumya: OK. Looking at category 2 about "Finding things on my network", we need to complete the table, looking for expertise here.
10:28:36 <tidoust> ... Any volunteer?
10:28:57 <tidoust> ... Also, if you know more technologies for category 4 (right now, only CoAP RELOAD)
10:29:16 <tidoust> ... We'll ask again in the joint session with Thing Description Task Force.
10:30:00 <tidoust> ... Moving on, another aspect we've looked into with Arne is to look at the different solutions that other IoT consortia have been looking into.
10:30:20 <tidoust> Mohammed: I can take care of the OMA line in this table.
10:30:46 <tidoust> ACTION: Mohammed to fill out the OMA line in the Discovery Solution IoT Consortia table
10:30:46 <trackbot> Created ACTION-25 - Fill out the oma line in the discovery solution iot consortia table [on Mohammed DADAS - due 2016-02-03].
10:31:09 <RuiFerreiraDaCosta> RuiFerreiraDaCosta has joined #wot-di
10:31:21 <dom> -> https://www.w3.org/WoT/IG/wiki/Discovery_Solutions_Iot_Consortia Discovery Solutions Iot Consortia
10:31:37 <tidoust> Soumya: For oneM2M, we need to add the missing "Semantic search" category.
10:32:12 <tidoust> Arne: This AIOTI is from the EU Commission. I don't think it specifies any technology.
10:32:21 <tidoust> Dom: More a cloud than a consortium.
10:32:26 <dom> s/cloud/club
10:32:26 <tidoust> Arne: It could be removed from the list.
10:33:15 <tidoust> Soumya: ThreadGroup is developing technologies on top of IPv6
10:33:29 <tidoust> ... HyperCat, in category 3.
10:34:45 <tidoust> ... Not sure about the Open Group.
10:35:22 <tidoust> Francois: Should be at lower levels. Relevant standards are O-DF and O-MI. Should be active.
10:36:06 <tidoust> Soumya: They seem to be working on a standard for open IoT lifecycle management. To keep in mind as we're considering it for discovery and provisioning.
10:36:39 <Soumya> http://www.opengroup.org/getinvolved/workgroups/iot
10:37:09 <andrew> andrew has joined #wot-di
10:37:15 <tidoust> Soumya: OGC SWE should be category 3 and 5.
10:37:51 <tidoust> Soumya: Now, I'd like to move to discussing of a general discovery framework.
10:37:58 <tidoust> ... Looking at the building blocks of discovery.
10:38:12 <tidoust> ... So many devices using different discovery and communication protocols.
10:38:27 <tidoust> ... Even if you discover a URI, you need to know which protocols it supports.
10:38:46 <tidoust> ... There was the question: should we create an abstraction layer for communication?
10:45:52 <tidoust> ... [presenting slide of Proposed discovery framework]
10:46:47 <tidoust> Arne: This layer will be realized as an API in the end, right?
10:47:15 <tidoust> Soumya: I guess so. Question is, do we need this layer? Do we want to expose the abstraction as metadata?
10:47:46 <tidoust> Arne: A generic mechanism in the API would be complicated from an implementation perspective.
10:47:53 <tidoust> Soumya: I agree.
10:48:00 <yuki_> yuki_ has joined #wot-di
10:48:23 <tidoust> Mohammed: Even if it is not exposed by the API, the metadata needs to be available at the discovery layer.
10:50:06 <tidoust> Francois: Experience in W3C suggests that the API should not expose the information, security and privacy implications.
10:50:24 <tidoust> ... However, the metadata is certainly needed for the user agent to establish the communication channel.
10:50:59 <tidoust> Soumya: At what stage of operation should that metadata appear?
10:51:15 <tidoust> ... In the reply? As a response to another GET operation? During filtering.
10:51:27 <tidoust> Mohammed: Ideally, it should be done during the first exchange.
10:51:57 <tidoust> ... Otherwise, if you don't know the available metadata, you're going to add extra round-trips that may end up being entirely useless.
10:52:11 <tidoust> Arne: Maybe you can also show the proposal from Louay regarding the API.
10:52:27 <tidoust> ... He proposed already this very simple API that has also discovery parts in it.
10:52:48 <tidoust> ... We had also a brief discussion if there should be some sort of generic discovery mechanism in that API.
10:53:15 <dom> -> https://github.com/w3c/wot/blob/master/TF-AP/thing-api/thing-api-webidl.md Thing API WebIDL
10:53:19 <tidoust> [Projecting Louay's slides on screen]
10:54:05 <tidoust> [Arne going through the code example]
10:54:39 <dom> [I'm reminded of https://www.w3.org/TR/discovery-api/#requesting-networked-services ]
10:54:44 <tidoust> Arne: The filter is the main mechanism for discovery. Here a type and promixity, but this could be much richer.
10:55:12 <tidoust> ... Then the code creates a ThingRequest object and calls start().
10:55:30 <tidoust> ... Under the hoods, this is where the generic mechanism would be implemented.
10:55:54 <tidoust> ... Then it uses the Thing.
10:56:26 <tidoust> ... For us, the question would be "do we need a ThingRequest" or do we need a "BluetoothThingRequest"?
10:57:02 <tidoust> Dom: It's hard to say in general. Depending on the protocol, the request may have to be gated through different user interactions mechanisms.
10:57:29 <tidoust> Arne: That's true. This proposition does not consider security at all.
10:58:27 <tidoust> Mohammed: If we want to define something generic, you'll still need to define the type, proximity. Security parameters could be added.
10:59:03 <tidoust> ... Whether devices will want to use the same vocabulary is not something we know today.
11:00:07 <tidoust> ... It's sometimes easier when the thing explains the parameters that it is ready to give. No additional security needed. No need to request information.
11:01:05 <tidoust> Arne: Basically a role-based mechanism.
11:01:29 <tidoust> Mohammed: right, the first call to the device will give you the right information.
11:01:57 <andrew> The filter may have a security attribute. For example, the filter has "security-level", it could be "public", "private" and so on.
11:03:35 <tidoust> Francois: I note the "filter" in the example may or may not passed by the user agent as discovery parameters. The user agent may discover devices and filter them afterwards. Or pass the parameters, e.g. when querying a directory.
11:04:13 <tidoust> Soumya: For constrained devices, server filtering makes sense.
11:05:01 <tidoust> Arne: The question for me is whether we can make this generic enough.
11:05:10 <tidoust> Soumya: My experience is that it is complex.
11:05:33 <tidoust> ... If you know the use cases that you want to target, it's easier to target specific technologies.
11:06:23 <tidoust> Dom: More generically speaking, if you want to talk to a Bluetooth device, you will want to specify the GUID of the service. Very different from an NFC use case.
11:06:38 <tidoust> ... Starting from generic is extremely unlikely to succeed.
11:07:16 <dom> tidoust: this depends on your use case
11:07:38 <dom> ... if you know the technology you want to build on, a specific API is ok
11:07:52 <dom> ... if you just want access to any matching device, a generic API would work
11:08:07 <dom> ... but you can't have the same level of control
11:08:17 <dom> ... that's the model of the Presentation API
11:09:21 <dom> dom: I think the key is to have something specific: either you're generic on the protocol, or you're generic on the type of device
11:09:34 <dom> ... being generic on both sounds like a combinatorial nightmare
11:09:53 <dom> soumya: that matches my experience
11:10:18 <dom> i/tidoust: this/scribenick: dom
11:10:30 <dom> tidoust: I don't think that means we should abandon the ThingRequest API
11:11:03 <dom> ... it provides a way to connect a larger set of things in which browser vendors are interested
11:11:21 <dom> ... (looking at some scenarios with connected things)
11:12:30 <dom> arne: another thing we can look at the type of filters we would want
11:12:39 <dom> ... id for objects that have already been connected to
11:12:46 <dom> ... types
11:13:00 <dom> soumya: this could be based on the Thing Description vocabulary
11:13:36 <dom> arne: the thing description is looking at defining properties
11:13:47 <dom> ... a filter could be "I want things that have property "brightness"
11:15:06 <dom> soumya: the IPSO alliance is building a list of types
11:15:08 <dom> ... http://www.ipso-alliance.org/
11:15:16 <dom> dom: how can such a list be exhaustive though?
11:15:41 <dom> soumya: good question; they're building it from the various organizations that standardize protocols
11:16:39 <tidoust> dom: The option of using a property-based filter would seem more scalable than assuming that all objects are classified. If I have a device that combine multiple functions, how would it answer requests on type?
11:17:23 <tidoust> ... What the developer will want is to be able to call a given method. You'll want to get things that respond to that.
11:17:49 <dom> dom: filtering could be around duck typing more than formal typing
11:17:57 <dom> ... (I want an object that "quacks")
11:18:51 <dom> tidoust: the generic sensor api defines a pattern that concrete sensors implement
11:19:13 <dom> ... e.g. the ambient light — each concrete sensor defines its own data format
11:21:17 <tidoust> dom: The idea of being able to reconnect to an object you've already interacted with. Similar mechanism in getUserMedia with the notion of deviceId. It's a very useful mechanism but it may, or may not be applicable to all protocols.
11:21:59 <tidoust> ... There is also the question of whether the ID is a concrete one used by the protocol or whether it's an ID made up for the occasion, as done in getUserMedia for security reasons.
11:22:52 <tidoust> Soumya: Don't you need to know the ID beforehand?
11:23:08 <tidoust> Francois: First interaction will give you the ID, both in getUserMedia and in the Presentation API.
11:24:03 <tidoust> Dom: One thing that is ambiguous with the API we're looking at is that it's meant to be used in browsers and server environment. In the browser, you probably do not want to use concrete IDs.
11:24:38 <tidoust> Arne: OK, these are key questions. How generic the discovery request should be? And how to do the filtering?
11:24:46 <tidoust> ... In the end, this is much related to the API.
11:24:49 <tidoust> Soumya: True.
11:25:20 <tidoust> Dom: That's an important point. There may be no need to distinguish discovery and API. At this point, it becomes an API question.
11:25:49 <tidoust> i/dom: The idea of being able/scribenick: tidoust/
11:27:17 <tidoust> Arne: For the filtering, one approach is clearly defined filters (id, type, action, property). Another approach would be generic filtering with key-value pairs.
11:28:07 <tidoust> Francois: Doesn't the second approach include the first one?
11:28:16 <tidoust> Arne: Yes, the second one is much more powerful.
11:28:47 <tidoust> i/dom: The option of using/scribenick: tidoust/
11:29:00 <tidoust> i/dom: filtering could be around/scribenick: dom/
11:29:46 <tidoust> Soumya: Conclusion is we addresed 4 main points. The Landscape document and a very good discussion around the building blocks.
11:29:58 <tidoust> ... One thing that I did not put here is ranking of the discovered results.
11:30:12 <tidoust> ... How are we going to rank the results when we show them to the client?
11:30:27 <tidoust> ... Can we envision something similar to search engine ranking mechanisms?
11:31:07 <tidoust> ... Thanks all for the discussion.
11:31:12 <tidoust> RRSAgent, draft minutes
11:31:12 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/27-wot-di-minutes.html tidoust
12:30:05 <Yuki_Matsuda> Yuki_Matsuda has joined #wot-di
12:41:51 <Yuki_Matsuda> Yuki_Matsuda has left #wot-di
12:50:03 <tidoust> tidoust has joined #wot-di
12:53:33 <kaz> kaz has joined #wot-di
12:55:33 <akeranen> akeranen has joined #wot-di
12:57:49 <Zakim> Zakim has left #wot-di
13:45:09 <dsr> dsr has joined #wot-di
13:45:49 <mdadas> mdadas has joined #wot-di
13:46:05 <dsr> meeting: joint session of DI and SP task forces
13:46:07 <mdadas> present+ Mohammed
13:46:11 <dsr> scribenick: dsr
13:46:21 <dsr> present+ Dave_Raggett
13:46:36 <RuiFerreiraDaCosta> RuiFerreiraDaCosta has joined #wot-di
13:46:42 <romain> romain has joined #wot-di
13:47:09 <dsr> Soumya introduces the agenda
13:47:44 <dsr> Oliver: we want to protect access to particular capabilities, not just discovery
13:47:56 <dsr> rrsagent, set logs public
13:48:21 <Soumya_> Soumya_ has joined #wot-di
13:48:33 <dsr> Oliver will recap the approaches we’ve been looking at in the SP task force
13:48:56 <Soumya_> present+ Soumya, Dave, Oliver, Francoise, mdadas, Andrew, Rui
13:49:39 <andrew-kwisa> andrew-kwisa has joined #wot-di
13:50:01 <dsr> Oliver: we attach a security token with protocol requests
13:50:39 <dsr> We have a client side authentication server (CAS) that provides this security token.
13:51:13 <dsr> To get this the client needs to provide certain credentials
13:51:43 <dsr> A complication is dealing with protected and unprotected end-points
13:52:35 <dsr> The client side authentication server itself communicates with a separate authentication server that manages accesses to resources.
13:53:10 <dsr> You might grant rights to turn on/off the lights, but not the heating (as an example)
13:53:55 <dsr> This isn’t being claimed as the final solution, but is a valuable step in the right direction.
13:55:00 <dsr> A similar approach can be applied to discovery
13:57:14 <dsr> Soumya introduces the various discovery patterns: “find things near me”, “find things on my network” which
13:57:29 <dsr> s/“find things near me”, “find things on my network” which//
13:57:57 <dsr> “find things near me” which looks for physically nearby devices
13:58:18 <dsr> “find things on my network” which is IP based
13:58:51 <dsr> “find things on a registry” - where things have previously been registered
13:59:11 <dsr> “find things semantically” based upon semantic relationships
13:59:41 <dsr> The latter also relates to finding things based upon social relationships (Social IoT)
14:00:20 <dsr> Oliver: most people need a high level human friendly approach
14:00:46 <dsr> This has strong implications for authorisation of discovery
14:02:04 <dsr> Oliver: for finding things near me, this often involves a short range broadcast, e.g. Bluetooth beacons.
14:02:39 <dsr> There is thus a proximity model.
14:02:59 <dsr> The classical authentication approach involves a request/response pair which doesn’t work here
14:03:38 <dsr> Francois, if the broadcast gives an address then the classical approach can be applied.
14:03:57 <dsr> s/address/address of a server end-point/
14:05:50 <tidoust> This reminds me of the "Named Web Socket" proposal: endpoints would share some secret, used to encrypt a message in mDNS that only authorized endpoints could decrypt and use to communicate with the endpoint advertizing itself
14:06:15 <dsr> Dave: a further idea is for the client to broadcast a request “hello who is near me” and for devices to respond. This can be combined with a security token as a basis for access control.
14:06:42 <tidoust> -> https://github.com/namedwebsockets/networkwebsockets Named Web Socket proposal (with encryption)
14:07:07 <tidoust> (Note I'm not aware of any recent development of the Named Web Socket proposal)
14:08:02 <dsr> Dave: for example using infrared, ultrasound of a wireless message of some kind
14:08:12 <dsr> s/of a/or a/
14:08:36 <dsr> Soumya moves on to IP based techniques for finding things on my network
14:10:28 <dsr> He shows a diagram whereby a client sends a multcast query message to a network entry point which relays this to all listening things.
14:11:06 <dsr> The things send an advertisement message with their end-point address
14:11:18 <dsr> s/multcast/multicast/
14:13:21 <dsr> Oliver: what about clients that were previously unknown?
14:13:39 <dsr> Dave: the client could provide a credential from a trusted third party
14:15:35 <dsr> Oliver: we would need to look at the details of whether end-points are protected or not
14:15:47 <dsr> Francois: what are we trying to protect?
14:16:09 <dsr> Oliver: we’re discussing how to limit who can discover what
14:17:34 <dsr> Francois: do existing protocols e.g. SSDP support passing such security tokens?
14:18:17 <dsr> Oliver: good question, this is something being discussed in the IETF
14:20:15 <dsr> For HTTP, this is straightforward, for datagram based protocols, this is harder.
14:20:36 <dsr> We want to avoid overcomplicating things
14:22:00 <dsr> Soumya: what about searching in a directory/registry?
14:23:04 <tidoust> [Re. datagram based protocols, see the introduction to Secure DNS based Service Discovery (DNS-SSD) proposal part of the Named Web Socket idea mentioned above: https://github.com/namedwebsockets/networkwebsockets/wiki/Introduction-to-Secure-DNS-based-Service-Discovery-(DNS-SSD) ]
14:24:45 <dsr> Oliver: this is similar to the first approach I described
14:25:54 <dsr> Oliver: for this plugfest we took several shortcuts.
14:27:44 <dsr> Soumya: accessing thing metadata. This is very similar in principle
14:31:11 <dsr> Dave wonders if we are only thinking about HTTP, what about let’s say bluetooth, where access is predicated on first having peered with a device.
14:32:53 <dsr> Francois: for MDNS/SSDP, the advertisements may be sent unsolicited
14:33:26 <dsr> Dave: yes, these are unsecured discovery solutions
14:35:04 <dsr> Dave: Oliver drew the CAS and AS as separate from the client and server, but in principle the CAS can be merged with the client and the AS with the server.
14:35:07 <dsr> Oliver: yes
14:36:45 <dsr> Dave wonders what we could potentially learn from the new W3C WG based upon the submission from the FIDO alliance.
14:37:16 <dsr> This pertains to assurances as to the human owner of a client device.
14:37:58 <dsr> Oliver: quite so
14:43:01 <Soumya_> rrsagent, draft minutes
14:43:01 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/27-wot-di-minutes.html Soumya_
14:55:14 <tidoust> tidoust has joined #wot-di
15:23:22 <yingying> yingying has joined #wot-di
15:26:24 <dape> dape has joined #wot-di
15:26:40 <dom> dom has joined #wot-di
15:26:51 <kaz> scribenick: kaz
15:26:59 <kaz> topic: TF-AP/TF-DI joint
15:27:08 <kaz> soumya: shows the agenda wiki
15:27:31 <kaz> -> https://www.w3.org/WoT/IG/wiki/F2F_meeting_2016,_January,_26th_%E2%80%93_28th,_France,_Nice#TF_AP_Agenda wiki
15:27:59 <kaz> soumya: APIs for registering and discovery
15:28:08 <kaz> ... boundary between registration and discovery
15:28:16 <kaz> johannes: WG charter discussion as well
15:28:20 <kaz> soumya: ok
15:28:33 <kaz> johannes: discussions on proposed APIs
15:28:43 <Soumya_> Joint session AP-DI
15:28:47 <kaz> ... discovery API discussion this morning as well
15:29:08 <kaz> rrsagent, draft minutes
15:29:08 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/27-wot-di-minutes.html kaz
15:29:43 <kaz> soumya: shows the minutes from the DI-TF session
15:30:09 <kaz> -> https://www.w3.org/2016/01/27-wot-di-minutes.html DI minutes
15:30:21 <kaz> soumya: building block for discovery
15:30:37 <kaz> ... make sense to generic abstract layer?
15:30:49 <kaz> ... should try a subset?
15:31:22 <kaz> ... then WebIDL notation
15:31:46 <kaz> -> https://github.com/w3c/wot/blob/master/TF-AP/thing-api/thing-api-webidl.md Thing API repo
15:32:16 <kaz> johannes: this morning we had discussion on discovery
15:32:34 <kaz> ... the start will give you list of thing descriptions
15:32:42 <kaz> ... universal enough?
15:32:56 <kaz> ... not so sure how to proceed with Filter
15:33:12 <kaz> ... generic key/value pair
15:33:26 <kaz> ... something simpler specific type
15:33:44 <kaz> ... what simple/powerful enough API would be?
15:33:46 <dsr> dsr has joined #wot-di
15:34:06 <kaz> soumya: we're on the same page
15:34:25 <kaz> louay: tech landscape to cover different technologies
15:34:38 <kaz> ... there are multiple use cases
15:34:46 <kaz> ... simple discovery
15:34:56 <kaz> ... discover for temperature sensor, etc.
15:35:21 <kaz> ... and more complex type of discovery
15:35:32 <kaz> ... local discovery requests discover things
15:35:45 <kaz> ... UPnP, BLE, or other protocols
15:36:17 <kaz> ... need to specify the types
15:36:48 <kaz> ... same APIs for physically different sensors
15:37:09 <kaz> ... some sort of hybrid solutions possible?
15:37:22 <Hitoshi_> Hitoshi_ has joined #wot-DI
15:37:37 <kaz> ... put filter for SPARQL and other technologies
15:38:01 <kaz> soumya: good addition
15:38:15 <kaz> johannes: this is very generic approach
15:38:39 <kaz> ... could have SPARQL, etc.
15:39:06 <kaz> ... could have simpler approach, though
15:39:37 <kaz> ... the resolution could be we don't specify concrete protocol for discovery
15:40:04 <kaz> ... and continue this generic approach
15:40:13 <crispus> crispus has joined #wot-di
15:40:46 <kaz> soumya: next
15:40:55 <kaz> ... APIs for registering and discovery
15:41:07 <kaz> johannes: some repository-based discovery?
15:41:22 <kaz> ... don't want to dig in the details now
15:41:34 <kaz> soumya: shows the DI-TF wiki
15:41:40 <kaz> ... then github repo
15:42:13 <kaz> -> https://github.com/w3c/wot/blob/master/TF-DI/Interactions.md TF-DI repo - interactions.md
15:42:32 <kaz> soumya: exaple of distributed cities
15:42:45 <kaz> ... pulled up into the cloud
15:42:49 <kaz> ... quite simpler
15:43:04 <kaz> johannes: not aware of the registry
15:43:12 <kaz> ... using server-side API?
15:43:56 <kaz> ... during the plugfest, we had some central repo
15:44:11 <kaz> ... server generates thing description
15:44:39 <kaz> ... you could register TD
15:44:48 <kaz> soumya: just send a payload
15:46:01 <kaz> johannes: we are not very sure about this API
15:46:10 <kaz> ... could be automatically done
15:46:16 <kaz> ... using Thing Description
15:46:24 <kaz> soumya: any other points?
15:46:32 <kaz> claes: not seen yet
15:46:45 <kaz> ... but how the exact interaction is done?
15:47:11 <kaz> soumya: the matter of MIME type
15:47:22 <kaz> johannes: within the HTTP post?
15:47:24 <kaz> soumya: yes
15:47:58 <kaz> kaz: are you planning to add that kind of clarification to the repo document?
15:48:01 <kaz> soumya: yes
15:48:38 <kaz> action: soumya to add clarification to the tech landscape and the discovery interaction pattern doc based on the f2f discussion
15:48:40 <trackbot> Created ACTION-28 - Add clarification to the tech landscape and the discovery interaction pattern doc based on the f2f discussion [on Soumya Kanti Datta - due 2016-02-03].
15:48:53 <kaz> soumya: shows the IG main wiki
15:49:04 <kaz> ... and then WG work items
15:49:04 <Claes> Claes has joined #wot-di
15:49:33 <kaz> -> https://www.w3.org/WoT/IG/wiki/Proposals_for_WoT_WG_work_items proposals for WoT WG work items
15:49:47 <mabauer> mabauer has joined #wot-di
15:49:56 <kaz> soumya: we can try to see interaction for discovery
15:50:32 <kaz> joerg: how to handle the discovery topics?
15:50:51 <kaz> soumya: had discussion with Sebastian
15:51:04 <kaz> joerg: TF report discussion tomorrow morning
15:51:34 <kaz> soumya: would see their (=TF-TD) opinions as well
15:51:45 <kaz> johannes: would see as one of the WG topics
15:51:56 <kaz> ... what the scope for the WG should be?
15:52:06 <kaz> ... include in the deliverables?
15:52:28 <kaz> ... WoT scripting APIs
15:52:36 <kaz> ... how to describe discovery things
15:53:06 <kaz> ... some of the discovery APIs may be related to the protocols
15:53:14 <kaz> s/protocols/protocol mapping
15:53:40 <kaz> ... something to describe the mechanism of discovery
15:53:51 <kaz> ... API viewpoint and TD viewpoint
15:53:58 <kaz> soumya: anyone has any points?
15:54:16 <kaz> joerg: could be something to be done during the discussion
15:54:41 <kaz> ... need to see if included in the deliverables
15:54:56 <kaz> ... would make sense to make sure
15:55:54 <kaz> soumya: those are three topics in my mind
15:56:46 <kaz> claes: interested in seeing if we should have the API
15:57:00 <kaz> joerg: what's important?
15:57:11 <kaz> s/what's/would see what's/
15:57:21 <kaz> s/important?/important tomorrow/
15:57:29 <kaz> johannes: objectives
15:58:04 <kaz> soumya: clicks the objective section
15:58:08 <kaz> https://www.w3.org/WoT/IG/wiki/Proposals_for_WoT_WG_work_items#Linked_Data_Vocabulary_For_Describing_Data_Models
15:58:19 <kaz>     Design and development of a technology independent discovery for Web of Things.
15:58:19 <kaz>     Provide guidelines for binding to APIs and protocols for efficient interaction with things.
15:58:19 <kaz>     Utilize an uniform catalog of descriptions (as defined in things description) for discovery of things and their metadata.
15:58:20 <kaz>     Provide means of ranking the discovery results (when presented to end users or other M2M applications).
15:58:43 <kaz> johannes: tx all!
15:59:53 <kaz> [ break and go back to the main room ]
15:59:59 <kaz> rrsagent, draft minutes
15:59:59 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/27-wot-di-minutes.html kaz
16:00:04 <Soumya_> rrsagent, draft minutes
16:00:04 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/27-wot-di-minutes.html Soumya_
16:00:11 <dom> dom has left #wot-di
16:08:19 <Hitoshi_> Hitoshi_ has left #wot-di
17:19:35 <Vicetone> Vicetone has joined #wot-di