09:51:02 RRSAgent has joined #wot-ap 09:51:02 logging to http://www.w3.org/2016/01/27-wot-ap-irc 09:51:10 Zakim has joined #wot-ap 10:09:10 taki has joined #wot-ap 10:09:22 Meeting: TF-AP breakout 10:09:33 johannes: shows TF-AP agenda 10:09:41 ... would start with the architecture document 10:09:52 ... next scripting API 10:10:27 ... and joint session with DI, TD and SP 10:10:34 ... AP topics include 10:10:43 ... finalizing the AP tech landscape 10:10:52 ... WG item 10:11:04 ... protocol bindings 10:11:04 toru has joined #wot-ap 10:11:11 ... plugfest wrap-up 10:11:40 present+ Toru_Kawaguchi 10:11:46 -> https://www.w3.org/WoT/IG/wiki/F2F_meeting_2016,_January,_26th_%E2%80%93_28th,_France,_Nice#TF_AP_Agenda TF-AP agenda 10:12:04 i/johannes:/topic: agenda/ 10:12:22 topic: Web of Things Architecture (Kazuo Kajimoto) 10:12:33 kazuo: confusion on the architecture 10:12:46 ... and would make it clearer step by step 10:12:58 ... (Abstract architecture on TPAC 2015) 10:13:06 ... this is Johannes's generated diagram 10:13:28 ... this is an abstract model 10:13:47 Claes has joined #wot-ap 10:13:56 ... (Modified diagram of the basic WoT servient architecture) 10:14:45 ... we successfully did the plugfest last night 10:15:30 ... trying to clarify the mechanism of the WoT Servient 10:15:59 ... Physical API provider for Physical API, etc. 10:16:12 ... resource management with Thing Description 10:16:29 ... talked with Fujitsu guys, Matsukura-san and Nimura-san 10:16:48 Hitoshi_ has joined #wot-AP 10:16:53 ... protocol mapping include the capability of adapter for legacy communication devices 10:17:12 ... legacy devices use appropriate interfaces 10:17:32 ... Web client communicate with WoT Servient and Web server 10:17:44 ... Web server communiate with WoT servient and Web client 10:17:52 ... what do you think about this breaking-down 10:18:06 johannes: great to see this improved architecture diagram 10:18:21 ... difference with APIs 10:19:02 claes: not sure about the motivation of this trial 10:19:26 kazuo: we had various discussions in Sapporo with related groups, e.g., GPIO, sensors 10:20:01 ... WoT servient should have server api, client api and physical api 10:20:09 ... that is good input 10:20:25 ... and would update the abstract architecture diagram for that 10:20:43 johannes: we have two APIs for network connection (server/client) 10:20:54 ... and also should have physical APIs 10:21:30 ... the question is whether the mechanism should be also standardized or not 10:21:45 louay: good to clarify what is the client API, etc. 10:21:49 akeranen has joined #wot-ap 10:21:58 dape: good to see this 10:22:16 johannes: for the architecture, good to see what is in it 10:22:27 kazuo: (Simple example for WoT) 10:22:34 ... this is a simple example 10:22:48 ... controlling WoT devices from browsers 10:23:12 present+ Ari_Keranen 10:23:13 ... browser can call the client API (within the browser) 10:23:36 ... and send commands to the Web server part of the WoT servient 10:24:12 ... ((A) WoT servient on device (WoT device)) 10:24:28 ... device is a WoT servient, directly interprets the WoT APIs 10:24:52 ... the WoT servient on the right side is a device (=WoT device) 10:25:03 ... ((B) WoT servient on Smartphone) 10:25:21 ... within the smartphone (=two boxes on the left side) 10:25:42 ... browser and WoT servient co-exist 10:26:18 ... another possibility is another smartphone on the right side 10:26:44 ph: UI on browser for the right side picture? 10:26:56 ... what is the purpose of the right side picture? 10:27:11 kazuo: the left side picture is regarding the GotAPI model of OMA 10:28:01 kaz: so the WoT servient within the right picture includes UI capability of a Web browser 10:29:08 johannes: left side picture implies CoAP interface between the browser part and the WoT servient part 10:29:12 kazuo: right 10:29:18 ... (C) simple model 10:29:28 ... ((D) WoT Servient on Cloud Server) 10:29:51 ... application platform on the Cloud Server 10:30:27 ... legacy devices are connected to the Hub 10:30:40 ... this is the model used for the plugfest demo by panasonic yesterday 10:31:09 ... commands sent from the browser through the platform cloud server 10:31:36 ... defining this level of modules would be useful to develop actual systems 10:31:44 Louay has joined #wot-ap 10:31:55 present+ Louay_Bassbouss 10:32:09 ari: should we discuss protocol bindings, etc., as well? 10:32:18 johannes: what protocol is used and mapped? 10:32:37 ari: how do you expose the functionality 10:32:48 ... some minimal set? 10:32:57 johannes: understood 10:33:16 ... need mapping with the resource model 10:34:17 ... the conclusion here should include that the architecture should have resource management layer as well 10:36:09 RESOLUTION: we update the architecture with Kajimoto-san's proposal 10:36:27 johannes: we can use this for the WG charter deriverables as well 10:37:02 action: kazuo to send the slides to the group and update the f2f wiki with the link 10:37:03 Created ACTION-26 - Send the slides to the group and update the f2f wiki with the link [on Kazuo Kajimoto - due 2016-02-03]. 10:37:34 johannes: anything else? 10:38:04 ph: motivation of the improvement should be also recorded 10:38:26 johannes: we need to keep in mind about the structure of the document 10:38:31 ph: also the motivation 10:38:53 johannes: suggestion on the document structure on Github? 10:38:57 ... or wiki? 10:39:35 kazuo: would start with wiki 10:39:47 claes: could you put the link to the document? 10:39:50 kazuo: will do 10:40:16 rrsagent, make log public 10:40:21 rrsagent, draft minutes 10:40:21 I have made the request to generate http://www.w3.org/2016/01/27-wot-ap-minutes.html kaz 10:42:15 topic: WoT scripting APIs (Louay Bassbouss) 10:42:29 louay: shows the Github repo 10:43:40 -> https://github.com/w3c/wot/blob/master/TF-AP/thing-api/thing-api-webidl.md Github repo for Thing API 10:44:23 louay: not only discovery but look up 10:44:52 i/louay:/louay: Interface ThingRequest/ 10:45:14 louay: the goal is getting access regardless of concrete approaches 10:45:40 ... the most important is ThingFilter 10:45:57 ... collect what is in my mind 10:46:26 johannes: having two basic interfaces. right? 10:46:29 louay: yes 10:46:49 ... next Interface Thing 10:47:09 ... more or less compromise for Thing Description 10:47:18 ... getting ID of each object 10:47:29 yuki_ has joined #wot-ap 10:47:33 ... something to discuss with the TF-TD 10:48:20 ... 'reachable' is some feature to see if you can get response from the object 10:48:26 s/object/device/ 10:48:52 ... other functionalities like callAction 10:49:27 ... setProperty, getProperty 10:49:37 ... if you want to subscribe events 10:50:13 ... we have three functionalities, addListener, removeListener, and remove AllListeners 10:51:59 ... you can subscibe any APIs even if it doesn't exist 10:52:11 ... and will get an error 10:52:24 ... we need to think about that 10:53:08 johannes: how to handle actions? 10:53:24 ... explicitly define the event? 10:53:54 louay: several possibilities 10:54:16 johannes: when you implement a servient on the server side 10:54:24 ... and somebody calls an action 10:55:08 louay: there are different APIs, server API, client API and physical API 10:55:20 johannes: different class to expose the functionality? 10:55:57 ... agree we start with separate the interfaces 10:56:13 ... but in some cases we need to use some of them at once 10:56:23 claes: you don't know the name of the attributes 10:56:44 ... which are the available actions, events, etc. 10:56:58 louay: e.g., I have some BLE device 10:57:08 ... how to get attribute names? 10:57:16 ... e.g., humidity 10:57:43 claes: generic mechanism to see in Thing Description? 10:58:02 louay: if you're a developer who use this API 10:58:26 ... the developer should know about what feature is available 10:59:11 ... if we have accessory which support humidity and temperature 10:59:23 ... we need something to know the list of capability 10:59:51 claes: standardizing this would be very difficult 11:00:23 maxime: how to interact with each other 11:00:38 ... surprised if there is no mechanism to see 11:00:53 louay: the interface is already there 11:01:17 johannes: mechanism to access property is missing 11:01:36 ... you can dynamically access properties 11:02:45 louay: you can get a list of actions, but can't tell which action means what 11:03:19 ... if you discover media server from DLNA, you can tell what it means, though 11:03:27 ... the same happens here 11:03:39 ... the semantics of the thing is lost 11:04:12 johannes: how to know what action corresponds to what properties 11:04:26 ... how to handle every thing type 11:05:02 louay: next, Interface ThingEvent 11:05:12 johannes: let's see the examples 11:05:29 ... how to know the value of the component has changed? 11:05:36 louay: using the event name? 11:06:21 johannes: can use the physical API to change the actual value 11:06:28 ... have to have event name 11:06:36 ... interaction pattern 11:07:02 louay: the listener has 'eventName' 11:07:21 ... you can tell which is event 11:07:42 ... (show "Example Discover Things nearby") 11:08:47 ... if you have different set of properties and actions, you can put them 11:09:35 johannes: the name must be unique 11:09:47 ... same name for the action and the property 11:10:10 louay: three functions 11:10:31 ... when the call is done, we get the event 11:11:09 johannes: invoke or call actions 11:12:37 ... we can start with separate interfaces for the first sketch 11:13:18 louay: same abstraction is used for homekit 11:13:28 ... really hidden for applications 11:13:38 ... there is no actions 11:13:45 ... only properties 11:14:21 johannes: ok 11:14:48 ... the both interfaces are separated now 11:15:17 nimura: other thing API to access the actual device? 11:15:41 louay: for homekit you can access the devices within the range 11:15:55 ... there is a solution for homekit 11:16:49 ... maybe you need to get access for thing object 11:17:30 nimura: can we have a common API from application viewpoint? 11:17:51 louay: more or less depends on the underlying mechanism 11:18:09 ... not reachable if not connected or not at home, etc. 11:18:32 johannes: given the time, would suggest we conclude that 11:18:48 ... we want to have the interface on the server side and the client side 11:18:56 ... separate discovery of thing 11:19:08 ... we keep your wording on the github 11:20:02 kaz: would be great if you could add a diagram about your example on the Github repo :) 11:20:08 louay: ok 11:21:16 dape: create an issue on the uniqueness of the name: property name, action name 11:21:29 s/create/will create/ 11:21:36 johannes: anything else? 11:21:47 (nothing) 11:21:59 johannes: wraps-up the session 11:22:43 ... discussions on the architecture and scripting APIs 11:22:57 s/scripting/the scripting/ 11:23:07 ... thanks for your contributions 11:23:59 ... will have lunch from now 11:24:26 ... will resume at 13:30 for the joint meeting with TF-SP here at room 153 11:24:30 [ lunch ] 11:24:35 rrsagent, draft minutes 11:24:35 I have made the request to generate http://www.w3.org/2016/01/27-wot-ap-minutes.html kaz 11:29:48 present: Kaz_Ashimura(W3C), Johanees_Hund(Siemens), Daniel_Peintner(Siemens), Louay_Bassbouss(Fraunhofer_FOKUS), Claes_Nilsson(Sony_Mobile), Toru_Kawaguchi(Panasonic), Kazuo_Kajimoto(Panasonic), Maxime_Lefrancois(EMSE), Hitoshi_Hayakawa(Hitachi), Ari_Keranen(Ericsson), Yuki_Matsuda(UNI), Philipp_Hoschka(W3C), Shinji_Hoshino(ACCESS), Kazuaki_Nimura(Fujitsu), Ryuichi_Matsukura(Fujitsu) 11:29:52 rrsagent, draft minutes 11:29:52 I have made the request to generate http://www.w3.org/2016/01/27-wot-ap-minutes.html kaz 12:30:05 Yuki_Matsuda has joined #wot-ap 12:49:56 taki has joined #wot-ap 12:50:47 tidoust has joined #wot-ap 12:51:03 scribenick: tidoust 12:51:11 RRSAgent, draft minutes 12:51:11 I have made the request to generate http://www.w3.org/2016/01/27-wot-ap-minutes.html tidoust 12:51:31 Topic: Security and impacts on APIs and protocols 12:52:58 Oliver: The basic architecture is that we have a Thing, connected to a Servient component. On the other end, we have a caller component, and APIs for each one of them. 12:53:03 Louay has joined #wot-ap 12:53:33 kaz has joined #wot-ap 12:53:47 ... Encryption is not an architecture problem. If it's HTTP, then TLS should be used. DTLS in peer-to-peer. 12:53:59 ... The main problem from my perspective is at the Servient level. 12:54:15 ... It's something that runs 24/7 and that receives requests from various callers. 12:54:38 ... The Thing is a private request. The Servient exposes it at a public-facing interface. 12:55:10 ... So anyone, including the Mafia can send requests to the Servient. 12:55:37 ... There needs to be some secret sauce in there, some bits that are compliant with the protocol you're using and that protects the Servient component. 12:56:24 ... Are we on the same page? 12:56:43 Francois: Encryption often involves authentication, e.g. in TLS with certificates. 12:57:31 Oliver: Of course, as soon as you call for authorization, we have to make sure that you have some notion of trust. 12:57:47 ... Number one requirements is authorization, as mentioned by Carsten this morning. 12:58:39 ... Number two is entity authentication. 12:58:53 ... And then number three is actual encryption. 12:58:57 ... In that order. 12:59:33 ... Number three can be viewed as message authentication, which invovles the encryption. 13:00:25 ... Number three is not a priority, could be number 7 in practice. 13:00:31 Louay has joined #wot-ap 13:02:01 Oliver: My understanding at the Servient level is that we have e.g. a PUT method that proxies a request to the actual thing. 13:02:56 ... The enforcement (whether you agree to receive a PUT method and whether you're going to execute it) needs to be close to the resource. 13:03:16 ... The farther away you are from the resource, the worse the protection will be. 13:04:06 Claes: If we say that encryption is not a problem because we have DTLS for instance, cannot we say that authorization is something we have today, e.g. through OAuth? 13:04:36 ... We have standards there as well. 13:05:16 Oliver: First, I love OAuth. However, OAuth does not give you everything. The security token is mentioned in OAuth, but not its actual content. 13:05:39 ... It's up to e.g. the Google engineer to do the work. 13:05:51 ... You can think about different kinds of token. 13:05:58 ... This is nothing that the IETF is doing. 13:06:11 ... OAuth helps but only gives you half of what you need. 13:06:38 Claes: So the OAuth specification itself does not provide enough to address resilience issues? 13:07:06 Oliver: No. What I'm saying is that the security abstraction is not defined. 13:07:41 ... Also OAuth is a domain-based solution which I believe is not enough for cross-domaing authentication. 13:08:04 ... Again, I'm not complaining about OAuth. It is a wonderful approach, it is just not doing all the tricks that we need to address. 13:09:23 ... The domain model in OAuth works as follows: there is something called the "Resource Server", the "Item of Interest" and the "Authorization Service". 13:10:27 ... The spec just tells you how the client calls the Authorization Service (RFC6749), how to the client calls the Resource Service (RFC6750) 13:11:25 ... and the Registration endpoint (in another RFC) 13:11:39 ... It does not tell you what composes the authorization token. 13:12:04 ... To have a chance to get the Item of Interest, you have to have the security token. 13:12:36 ... This is what the Authorization Service gives you, but for that you need a client ID and client secret, which you obtain from the registration endpoint. 13:13:32 ... Not knowing what composes the security token is OK for a single domain (e.g. GMail). 13:14:01 ... In this case, the token is created and consumed by the same domain. The security token can be opaque for the client. 13:14:44 Claes: Your problem is that there is something missing so that the Authorization Service and the Resource Server can understand each other? 13:15:16 Oliver: Right. It may not be an issue, just a point to understand. I don't believe that there is one-token-fits-all solution. 13:15:26 ... Not being defined gives you flexibility. 13:17:07 ... You have a logical model and a physical model. If you implement all the authorization logic in the Resource Server, you cannot easily change the production of tokens. It should be external to the Resource Server. 13:17:27 ... That's a logical separation. 13:18:02 Claes: I'm just considering the problem with OAuth, whether we need to handle that. 13:18:09 ... Do you have suggestions for solutions? 13:18:18 Oliver: I'm not trying to get rid of OAuth. 13:18:29 ... Just pointing out facts. 13:19:11 Johannes: Wouldn't it be something where we specify a minimal set of properties for this object? 13:19:29 Oliver: Yes. I think there needs to be extension points. 13:21:02 ?1: If you have several resources, how do you propagate authorizations to the different endpoints that need to know about it. 13:21:38 s/?1/Daniel 13:22:24 Oliver: That's the next step. The client is not really constrained in the OAuth case. Assuming that it can speak HTTP, it can speak OAuth. If you have a very constrained device that only speaks CoAP, then you need to invent a helper component on the right-hand side of the diagram I have on the blackboard. 13:24:00 ... This is what the IETF ACE group is doing. 13:24:19 ... The original OAuth community does not really scale down to connected things. 13:24:46 ... ACE introduces a new component, initially called AM, now CAS (Client Authorization Server). 13:25:18 ... The IoT client itself needs to present the security token. The CAS component knows how to get it. 13:26:11 Oliver: Back to the interaction, when you get a 401 response, you don't necessarily understand what you need to do, where to go to get the authorization token. 13:26:41 ... The information as to what needs to be done is in human readable form in the body of the response. 13:27:10 ... However, there is a very strong binding between how the IoT client needs to react and the text instructions. 13:29:16 Johannes: What would be the final takeaway? First, description of the security token? Second, no standardized way to describe why an authorization failed? Third where would the validation of the authorization takes place in our architecture? 13:29:46 Oliver: OAuth does not have yet a concrete proposal on how the different components talk to each other. 13:29:52 ... The solution is not yet there. 13:30:42 ... You can of course do shortcuts. 13:31:01 ... e.g. I only care about my security protocols. 13:31:31 Claes: You mentioned the ACE group. What should be fixed in W3C when it comes to authorization? 13:32:51 Oliver: The ACE group, I believe, will come up with a proposal, but there are at version 0.1 for the time being, so it will take a bit of time. I'm not suggesting that we should step in. 13:33:06 ... We may want to provide feedback from a W3C perspective. 13:34:16 Oliver: From a protocol perspective, there are things that are not yet covered, the role for us is to express our expectations. 13:35:25 ... The next thing I'm suggesting to do is work on annotations to express when a light is private or public at the Resource Server level. 13:35:51 ... On the Client side, there needs to be security anchors for the APIs 13:36:28 Johannes: Wrapping up, some impact on the Server API regarding on how to protect access resources, on the Client API regarding on how to access tokens. 13:37:45 ... on the Protocol mapping regarding how to get the token, and on the granularity of protection. 13:38:49 Oliver: I have a list of requirements in my mind. I can draft an initial list. 13:40:10 Johannes: The important takeaway is to write the outcomes of the session on the Wiki. One track related to the Security and Privacy status overall, and the second track on more specific impacts on our architecture. 13:40:18 [End of breakout] 13:40:23 RRSAgent, draft minutes 13:40:23 I have made the request to generate http://www.w3.org/2016/01/27-wot-ap-minutes.html tidoust 13:41:22 Present+ Dominique_Hazael-Massieux(W3C) 13:41:29 Present+ Francois_Daoust(W3C) 13:41:51 Present+ Oliver_Pfaff(Siemens) 13:42:06 Present+ Joerg_Heuer(Siemens) 13:42:11 RRSAgent, draft minutes 13:42:11 I have made the request to generate http://www.w3.org/2016/01/27-wot-ap-minutes.html tidoust 13:42:36 Chair: Johannes 13:42:38 RRSAgent, draft minutes 13:42:38 I have made the request to generate http://www.w3.org/2016/01/27-wot-ap-minutes.html tidoust 13:43:06 i/johannes: shows TF-AP agenda/scribe: kaz/ 13:43:07 RRSAgent, draft minutes 13:43:07 I have made the request to generate http://www.w3.org/2016/01/27-wot-ap-minutes.html tidoust 13:44:34 taki has joined #wot-ap 13:45:27 Claes has joined #wot-ap 13:47:06 katsu has joined #wot-ap 13:52:31 dom has joined #wot-ap 13:52:39 Scribenick: dom 13:53:15 Louay has joined #wot-ap 13:53:30 XXX: 3 topics: plugfest feedback, relationship with API and thing description, resource vs thing level 13:53:43 ... I'll start with feedback from the plugfest related to think description 13:54:02 ... [showing slide "what is missing/unclear"] 13:55:58 s/XXX/Sebastian 13:56:49 Johannes: From an API point of view, I can first add what I've seen coming out of the discussions 13:57:26 ... when you have a relationship between things, e.g. a basic light used by a fancy light 13:57:48 ... there should be a way to link between things 13:57:55 ... anything came out of the "thing hierarchy" discussion? 13:58:39 akeranen has joined #wot-ap 13:58:43 Sebastian: in the transport layer, you need the metadata on how to access the information 13:58:55 ... it's an open question to understand how you express these metadata 13:59:16 ... that also has interactions, UI considerations 13:59:26 ... one approach is to build URIs by concatenating properties 13:59:39 ... another approach is to retrieve the properties from a URI 13:59:50 ... on an API level, this shouldn't matter though 14:00:21 Johannes: when I'm working with a temperature sensor, I would need to know that this temperature sensor is influencing the heating 14:00:31 ... I need the Thing Description to express this for me 14:00:41 ... for things to things interactions 14:00:54 ... they would not be part of the communication or interaction metadata 14:01:25 YYY: there is configuration data (a property you can infer from the outside) 14:01:32 s/YYY/Matthias 14:01:40 ... but there is also when you install a script in a thing that will implicitly configure other things 14:01:48 ... and then it's hard to express this declaratively 14:01:59 ... so it's probably independent of the thing description 14:03:20 ... you can either program things to work one with another, or the things can be made configurable to work with another one 14:03:41 ... there are different approaches to thing2thing; the configuration approach should probably be exposed via the API 14:04:03 ... but the programmatic approach would need to be exposed differently, e.g. via metadata of the program 14:04:25 Sebastian: that seems like an already advanced scenario, I'm not sure it should be part of the core of Thing Description 14:04:44 Johannes: there are some cases where this is necessary 14:04:51 ... that was one of the feedback from the plugfest 14:05:27 ... there was also as you mentioned the security aspects (which need to be protected by a token) 14:05:46 Daniel: another thing is when a description changes: how to get notifications about these? 14:05:56 ... right now, it looks like you need to poll and compare 14:06:17 Sebastian: that depends on the protocol: with COAP, you can set up an observer 14:06:22 ... but with HTTP, you need to poll 14:06:39 ... this also touches on the organization and management of thing descriptions 14:07:01 ... is it up to the client or the thing to ensure the descriptions are up to date? 14:08:34 Matthias: the question is linked to the workflow of seeking changes 14:08:57 ... is it that something broke? why would you care that an existing device suddently gained a new capability? 14:09:20 Daniel: imaging you walk into a room where a new device got plugged — you would want that new device to be controllable from your app 14:10:03 Matthias: but there are always specific times when you're interested in new devices; e.g. at the time you want to project your slides on a given device 14:10:32 ... you probably don't want to get notifications on all the changes on all devices, if only for power saving 14:10:54 Johannes: if you have a central directory, you can imagine that this registry would notify of newly registered devices 14:11:30 Sebastian: but I would only want to know of devices that are related to my use cases and that I can actually make use of 14:11:40 s/use cases/use case 14:11:57 ... I'm not sure if this is something that can be standardized though 14:12:11 Louay: I have a question about the binding protocol 14:12:22 ... right now we only have bindings for COAP, HTTP and WS 14:12:35 ... but sometimes you need more information for other protocols, e.g. Bluetooth LE 14:12:48 ... Imagine an accessory offering temperature readings over BLE 14:13:13 ... and that accessory also advertizes a URL via Bluetooth URI Beacon on its Thing Description 14:13:51 ... we don't have enough information to do the binding for the specific mapping between characteristics and properties 14:14:21 Carsten: there would be a URI to access that information 14:14:40 Louay: would there be enough information to do the mapping? 14:15:02 Carsten: you can put as much information in the URI as you want 14:15:09 ... you can define a specific URI scheme 14:15:28 ... if you want interop with BLE, you would probably need a BLE scheme 14:15:37 @@@: there is already one such URI scheme 14:16:32 Matthias: but I think in any case, this is something that would be addressed at the gateway level rather than at the device level 14:17:24 s/@@@/Ari/ 14:17:45 Sebastian: we should have more examples of that problem, this has come up several times 14:18:13 Johannes: this morning we discussed if the URI creation should be mandatory 14:18:46 Matthias: the idea was to rely on the URI model, without having a full-fledged ontology 14:19:17 Johannes: we had cases where a given property was followed or not by a /value which led to interop issues 14:20:11 Sebastian: [show examples of a JSON-LD thing description, and how to build a URI out of it] 14:20:26 -> https://github.com/w3c/wot/blob/master/TF-TD/TD%20Samples/temperatureSensor.jsonld temperature sensor example 14:21:06 Matthias: this example shows exactly why it's a bad idea for the client to construct the URI 14:21:37 ... do not take the name: use a link 14:21:58 Johannes: you said it's common practice the thing to provide its own description 14:22:06 ... would you get that from that URI? 14:22:15 Sebastian: yes, e.g. from the root URI 14:22:26 ... as a best practice 14:23:11 Kajimoto has joined #wot-ap 14:23:17 Matthias: the URI of the Thing Description is the one that should be used e.g. as part of the registration 14:24:03 Johannes: can I assume the root URI to be the URI of the thing description? 14:24:20 Carsten: [fixes the temperature example on the whiteboard] 14:24:34 "uri" => "_base" 14:24:55 ... the protocols piece give the base URL, and the various interactions define relative links 14:25:11 "coap://[fe80::206:98ff:fe00:202]/TemperatureSensor" => "coap://[fe80::206:98ff:fe00:202]/" 14:25:54 ... this decouples the minting of URLs from the client 14:26:59 Louay: but how do you deal with multiple protocols, e.g. coap, http 14:27:07 Carsten: you could provide multiple links? 14:28:08 ... or have more than one base URLs 14:29:04 ... the client could pick which protocol it prefers 14:29:40 Matthias: but even that is an optimization; if the thing was contacted over coap, it might just advertize coap links 14:30:20 ... if you multiple protocols for the base url, it forces you to re-use the same URL structure across protocols which I don't recommend 14:30:59 ZZZ: there was also the need to specify a preference or a priority, e.g. prefering BLE or coap 14:31:51 Carsten: if the thing provides the various protocols, it's up to the client to pick 14:32:41 ZZZ: what about events? 14:32:47 s/ZZZ/Victor/g 14:33:03 Carsten: I think it can be mapped to URIs as well in some protocols (e.g. COAP) 14:34:16 Sebastian: my impression is that Dave won't be happy with that approach because it mixes @@@ up 14:35:10 Matthias: note that these URIs don't have to be exposed to the developers (beyond debugging) 14:35:55 Johannes: we had an early discussion on architecture, and said we would base it on resources 14:36:14 Sebastian: but we also said we would not want to focus on REST-based approaches, but on streams etc 14:36:26 ... this is very much REST-y 14:36:58 Matthias: it would be good to see if this works with MQTT 14:37:09 ... MQTT needs additional protocol descriptions 14:37:46 Joerg: taking a step back, it would be good to look at what are the next steps to validate or invalidate this approach 14:38:02 ... has this been discussed in the TD task force? 14:38:48 ... e.g. formalizing it in a doc as input to a future plugest 14:39:10 Sebastian: Dave's vision separates the communication metadata from the thing metadata 14:39:16 ... and his implementation does this 14:39:50 Joerg: yes, but we need to progress on this as a group, and for that, we need a clear status of the current proposal, and define how to evaluate it 14:40:09 Matthias: my take away is that we should take it and try to implement it 14:40:20 ... but we haven't had the time to formalize this into action items 14:41:33 Johannes: it's good to be having this discussion; to get more visibility, we should keep iterating on what has been assumed, proposed and turn into a "current understanding" document 14:41:49 ... but this has to start from some basic assumptions and opinions 14:42:48 -> https://lists.w3.org/Archives/Public/public-wot-ig/2016Jan/att-0042/WoT_architecture_20160127_Panasonic-Fujitsu_.pdf Kajimoto-san's updated architecture diagram 14:42:49 ... what we we have just discussed I think forms a good basis for that 14:43:08 carsten: when you look at the layered architecture diagram, it looks fine 14:43:39 ... but the document you interchange for interop, these documents don't have to match that layering which is more for software design 14:44:07 ... it's important to separate the two aspects 14:45:16 s/we we/we/ 14:48:22 Johannes: the conclusion would be to bring all this in written form to share and get feedback on 14:48:36 ... who would want to bring a first incarnation of that? 14:49:09 Sebastian: I would like to take a stab at bringing Carsten's approach in the example 14:49:40 Carsten: I can also provide the CSS-like mechanism for separating concerns (although I don't think it's useful) 14:50:47 Johannes: so Carsten, are you OK with providing an example that we can use as a comparison point? 14:50:49 Carsten: sure 14:51:07 Johannes: we haven't touched on the other topics, they'll have to be taken up on a later call 14:51:29 ACTION: Johannes to organize follow up call on API <-> TD 14:51:30 Created ACTION-27 - Organize follow up call on api <-> td [on Johannes Hund - due 2016-02-03]. 14:51:49 [ afternoon break ] 14:55:14 tidoust has joined #wot-ap 15:11:27 yuki_ has joined #wot-ap 15:21:40 topic: TF-AP/TF-DI joint session 15:21:45 scribenick: kaz 15:23:01 yuki_ has joined #wot-ap 15:23:22 yingying has joined #wot-ap 15:24:09 taki has joined #wot-ap 15:27:14 Claes has joined #wot-ap 15:38:37 Hitoshi has joined #wot-AP 15:39:15 Hitoshi_ has left #wot-ap 15:40:16 Hitoshi has left #wot-ap 15:41:08 Hitoshi_ has joined #wot-AP 15:48:17 Claes has joined #wot-ap 15:59:47 Zakim has left #wot-ap 16:08:03 Hitoshi_ has left #wot-ap 16:12:47 yuki_ has joined #wot-ap 16:21:27 Kajimoto has left #wot-ap