Recap by Johannes

[ Discussion topics of TF-AP ]

johannes: explains
... Abstract resource model
... Architecture model
... Technology landscape
... Use cases & requirements

[ Protocol-agnostic resource model for web things ]

johannes: Properties
... Actions
... Subscriptions/EventSources

vlad: property should always reflect the most updated state
... as the temp. changes the device (e.g., air conditioner) needs to updated the status
... action is more than just changing the value

johannes: what would be the necessary atomic approach?
... is everybody ok?
... any opinions?
... make sense to split these?
... property plus action

vlad: meta data associated to actions
... if you want to have something more than "just data"
... you need to have actions

johannes: don't have clear answer at the moment
... you might need something like subscription/eventsources

vlad: depending on use cases
... for some use case, just need property
... another use case is getting data from a sensor every 5 mins
... if you want something more than property
... you need actions

jay: polling would be painful to get data
... when the state changes, let me know

johannes: for some property, you can set subscription

vlad: what kind of data you want to subscribe
... detect sensor data like temperature
... to get value only when the value changes

johannes: anybody think we should NOT have events, actions?

(no objections)

johannes: so we could have these depending on the need

jay: anything dynamic?
... people would make mistakes
... preventing those mistakes would be useful

johannes: adds "indication to avoid subscriptions on static
... where to handle this?

vlad: some properties are static
... and some are dynamic

kaz: mentions the work by the automotive wg
... and suggests we identify the need for get vs. subscribe based on use cases

[ Peoperties ]

johannes: REad-only properties
... read-only data
... what kind of properties?
... how to handle streaming data?
... also time and data?
... opinions?

jay: security considerations?
... you don't want people to change the value
... things might be highly sensible
... you want to keep properties open if possible, though

vlad: some of the devices might be provided on the asis-based
... we can't change anything
... what if we define vocabulary

johannes: there is difference
... something might be not changeable
... you can't change the location for example
... security is of course important
... need to model what is needed

jay: we might want to revisit the first point
... permission for subscription
... permission to read

johannes: need some kind of mechanism to handle permission
... might make sense to restrict the interaction
... some properties are not writable or subscribable

vlad: every action has unique URL
... for what we did within EVRYTHNG
... HTTP offers the mechanism
... should be inside or outside?

jay: millions of URIs?

vlad: yeah
... the user would like to interact with his own devices

johannes: maybe this afternoon, we can talk with the security TF guys about that
... several possible ways
... did we have agreement on suggestion about properties?
... both ways have pros and cons
... could we have discussion now?
... thinking of resources?

(raise hands)

johannes: let's postpone a bit
... and have more discussions

[ Actions ]

johannes: want to involve actions
... running executable actions
... one-time action vs. long-term action

jay: you could start something
... and could choose stop at some point
... or let it continue

johannes: right
... and keep the status exposed

jay: how would you stop it?

johannes: can use some ID
... to control it

jay: would see the worst case
... sometimes things are unmanageable
... need to shutdown it

vlad: what do you mean?

johannes: would keep the states of devices

vlad: if you have a specific server to manage the status of devices

johannes: cache to keep the status
... you can find resources

jay: much smarter to have the status information at the end point

johannes: should have concrete scenario on the use case
... keep status info at the end point vs. on the server side

vlad: exactly same information

don: robustness and security
... don't want to limit one

jay: individual device can publish once and subscribers can tell

don: may want to subscribe more than one devices
... at least two (may be more) for robustness
... this model should consider that kind of scalability for robustness
... and security consideration
... might need restriction for permissions

jay: agree with you we should draw a big picture including scalability

johannes: we'll take use cases first, and then see scalability
... we can agree on the action point?

kaz: maybe we can add a note on scalability, robustness and security consideration here

osamu: those points have effect to all the parts

johannes: would apply to all the points

[ Events ]

[ Discussion ]

johannes: do we have the same understanding?
... history/timeline vs. spontaneous event?

jay: smartmeter raise data every min
... sometimes you may want to get data immediately

johannes: some kind of values like temperature fits subscription

jay: should have both poll and subscription

johannes: should have special resource type to manage that?
... sometimes allow polling and sometimes allow subscription

vlad: if you own the server, you have lots of devices

johannes: would put your points here (on the "Discussion" slide)
... resources should always be pollable
... next, relation to, e.g., CoRE interfaces
... put that part into "()"
... next, media types?
... close to what the TF-TD is doing
... any suggestions?
... data structures?

[ Subscription resource]

johannes: discussed during the IETF meeting

[ Problem: RESTful but ...]

[ Solution Sketch ]

[ Dataflow ]

don: who gets the slots?

johannes: the police might have priority access to the traffic information

michael: subscription resource expose who is observing, etc.
... polling and subscription
... subscription resource links to endpoint
... protocol-agnostic
... endpoint is protocol-specific
... already exists within CoRE interface

johannes: info on who is subscribing?

michael: identifier on observer resource
... in CoRE interface, that is interesting question

don: who gets occupied by the slot?
... a concern was security
... is there limitation who could subscribe what?

michael: interestig to have those concepts

don: large number of sensors and small number of controllers
... you might want to have 3-4 controllers

johannes: adds notes
... who is subscribing? (DOS prevention, resource management)
... possibly LWM2M, Oauth bearer?

michael: secure paring
... with constraint devices, would think about subscription issues

[ Architecture Model ]

johannes: short recap
... shows the basic architecture picture on the GitHub wiki
... WoT servient interact with Web Server/Browser and Physical Devices
... virtual instances and real things
... can one physical device correspond with more than one virtual instances?

michael: a virtual entity could be a mash-up server corresponds to more than one virtual entities

kaz: Michael's comment implies that this model should allow nested structure like Russian dolls

johannes: right
... behavior of WoT servient
... how to interact with legacy devices?
... get device profile on discovery, invokes a virtual instance and installs a device driver
... and then exposes APIs of virtual instance
... opinions?

michael: those two (WoT servient and BT GW) are good examples

johannes: these examples are two natural ways
... shows another diagram on data transfer
... HTTP can be used
... how do we create events/actions?
... right side diagram exposes APIs
... declaratively vs. programmatically

michael: may be useful to have constraints
... using events/actions/properties
... changing properties using subscription
... script can't access internal resources directly

johannes: left side diagram consists of thin client

michael: the current constraint to restrict access to server-side resource

johannes: you would only see the server-side APIs or client-side APIs

michael: right
... we have a controller object
... also have a temperature object
... internally linked each other
... the sensor could internally expose the value

osamu: we had several use cases during the Munich meeting
... e.g., from Panasonic
... maybe difficult to manage their proposed business model by only one model
... we need both of the two models
... authentication, binding, resource discovery, etc., should be provided by the server

johannes: adds notes
... server-side: expose inputs and outputs as resources
... needs data binding of resources
... we need to include those points into our resource model
... any more comments?
... server-side scripts vs. client-side scripts

kaz: Kajimoto-san from Panasonic also thought we need some scripts/APIs on the server-side
... he will make his presentation in the afternoon

michael: URIs, hypermedia, etc., to represent resources

johannes: not much discussion on APIs so far

michael: client-side should also has similar model on resource management
... how to generate actions, etc.

johannes: would keep this model protocol-agnostic

osamu: one question
... IETF has core HTTP mapping document

michael: how proxy interacts
... we use whole different models as well

johannes: on the GitHub wiki, we're discussing existing models/protocols

osamu: architecture/modeling discussion is done by this TF. right?
... want to discuss the whole model for WoT here
... regarding some details on protocols, we could work with IETF

michael: we've established the collaboration with IETF based on that direction

johannes: we've started to have a model
... would put all the diagrams together on the wiki
... resources within "WoT Servient"

[ slide 20 with three WoT Servients ]

johannes: does this picture cover all our points?
... or anything missing?

michael: script only can consume visible resources
... through the common resource model

johannes: inside or outside?

michael: legacy devices expose resources as devices

s/as devices/as WoT devices/

johannes: legacy protocols like BT or sensor's proprietary one

michael: the Adapter is a device driver for legacy devices

johannes: Nimura-san, you have a similar image?

nimura: fine with this

kaz: there are two possible pathes
... direct data exposure from the middle WoT Servient
... or via the Web service server
... and people can choose which path to use based on their own need or business model

aizu: @@@

osamu: relationship between multiple servients

johannes: blue line is some legacy protocol
... orange lines are web protocols
... not necessarily HTTP

jonathan: constrained device?

johannes: WoT servient could be a constrained device

jonathan: this looks like heavy...

johannes: can we have a servient for only one protocol as a constrained device

jonathan: need to consider some light-weight model as well

johannes: what would be the difference?

jonathan: e.g., just supporting CoAP

johannes: that's possible
... a GW might support multiple protocols but a specific device may support only one protocol
... adds notes
... orange vs. blue
... constrained devices: one protocol

michael: what is the minimum WoT Servient?

johannes: web protocol can be used to talk each other
... adds some more edit to the notes
... orange vs. blue - when is a protocol considered as a web protocol

<inserted> ... add constrained device: one protocol, fixed resources, no APIs

<inserted> ... what is the minimal servient?

nimura: structure model?

johannes: protocol between client and servient?
... we didn't cover that aspect yet
... one servient corresponds to multiple devices
... good to have a new picture to capture that as well
... we already have 4-5 pictures for each case
... but would have one more abstract picture to capture all the points
... adds another note: One servient hosting several virtual instances

michael: do they have permissions to talk with each other?
... talk thorough HTTP or another protocol?
... optimization and communication

johannes: implication on security
... origin policies?

michael: we could say servient is a security domain

johannes: we could discuss this model from the security viewpoint

michael: definition of virtual instances?

johannes: should we try to include these comments into this picture?
... or generate another picture?

jonathan: do you have any idea about controlling compound resource?

johannes: group of resources?
... two approaches
... one entity covers all the grouped resources
... another one is atomic approach

jonathan: another question is regarding cloud services

johannes: cloud service as a background proxy?
... adds yet another note: add services in the cloud

<inserted> johannes: summarizes the discussion during the morning session

[ Properties ]

[ Actions ]

[ Events ]

[ Dataflow ]

johannes: would talk about "Technology landscape"
... also we'll talk about security consideration, etc.

[ lunch break ]

Security & Privacy topics for joint meeting

johannes: common points to discuss between S&P and TF-AP?
... and Kajimoto-san's presentation

Kajimoto-san's presentation

[ Treatment of Implementation ]

kajimoto: Web-sentric, Smartphone-centric, Hub-centric and Cloud-centric
... implementation models and servient mapping

[ Implementation Model (1) ]

kajimoto: Web-centric model was shown by Mr. Komatsu from NTT
... also by Dave from W3C
... each device has a globally unique URI
... next is Smartphone-centric model
... smartphone itself has GW functionality
... the third is Hub-centric model
... the Hub has both the functionality of WoT server and GW
... there are many possible models
... however, we should/could discuss the same I/F regardless of those models

[ WoT Servient Lifecycle (State Diagram) ]

kajimoto: standalone: not connected status
... connected: just connected and IP reachable
... registered: URI-like address is registered and can work as a WoT servient
... activated: powered on the device and support full service of things as a WoT servient

[ WoT Servient API classification ]

kajimoto: Activate/Inactivate, Get, Put, and Notify

johannes: works with our APIs :)
... any ideas on the relationship with Event/Action/Property discussion as well?

kajimoto: we ourselves are thinking of the Cloud-centric model

alan: the Mobile-centric model is similar to what Bryan from AT&T yesterday
... a class of APIs defined

kaz: standalone, connected, registered, activated are states
... and activate/inactivate, get, put, notify could be defined as events which change the above states
... right?

johannes: good mapping

kajimoto: the scope of WoT servient API definition is registered and activated

alan: how to start discovery?

kajimoto: could be done by NFC, etc.

alan: who would maintain the registration?
... something like BT paring?
... visibility?

kaz: we should think about unregister in addition to register like activate/inactivate?

alan: like this model as a simple starting point
... similar to what we're doing

johannes: need some description for actions
... how could we proceed?

Security&Privacy

oliver: atomic use cases
... canonical ways to describe security consideration
... charter to be generated by TPAC
... security&privacy requirements catalogue on the wiki

-> https://www.w3.org/WoT/IG/wiki/Security%26Privacy_Requirements_Catalogue security&privacy requirements categories

s/categolies/catalog/

oliver: technical landscape

-> https://www.w3.org/WoT/IG/wiki/Design-Time_Security%26Privacy_Means Design-Time Security&Privacy Means

oliver: we should have discussion technology landscape during TPAC

johannes: what is the granularity for the discussion?

oliver: pick you interested atomic use cases
... should not go for binary (yes or no) method

johannes: so we'll see the atomic use cases

oliver: maybe the next step should be cleaning up the catalog description

johannes: given the discussion so far including Kajimoto-san's talk, you already have some use cases

kaz: the automotive wg is also working on security/privacy portion
... so we should collaborate with each other

oliver: TPAC in Sapporo would be a good timing

Possible collaboration with the Autmotive WG and the MMI WG

kaz: explains the security/privacy discussion by the Automotive WG

-> https://www.w3.org/auto/security/wiki/Use_Cases security wiki

kaz: also mentions the discovery/registration work and state transition discussion by the MMI WG

-> http://www.w3.org/TR/2012/NOTE-mmi-discovery-20120705/ MMI discovery&registration draft

kaz: and suggests we collaboratively work with those groups
... for example, TPAC 2015 in Sapporo would be a good opportunity

johannes: Debbie Dahl, the Chair of the MMI WG joined one of the TF-AP calls and explained the MMI Architecture as the generic mechanism to handle state transition and application lifecycle

[ afternoon break ]

Technology Landscape

johannes: would talk about technology landscape
... the IG Charter mentions "Survey of Existing Practices and Standards Relevant to the Web of Things"

-> http://www.w3.org/2014/12/wot-ig-charter.html#deliverables WoT IG Charter

-> https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Technology_Landscape Technology Landscape wiki

johannes: protocols and resource models
... after TPAC, we'll have a readable version of this landscape description

alan: can I put information on GotAPI?
... more than just a protocol
... rather a design pattern
... could be applied to anything
... will send summary to Johannes

johannes: if people ask about protocol X, Y or Z, we can see the landscape document

[ States ]

johannes: put some information on possible states together based on Kajimoto-san's talk

[ Technology landscape of TF-AP ]

johannes: reviews what we discussed so far

Joint meeting with TF-TD

[ Protocol-agnostic resource model for web things ]

johannes: properties, actions, subscriptions/event sources

[ Properties ]

johannes: read-only/read-write properties
... configuration
... and dynamic properties

[ Actions ]

johannes: invokable actions on physical things

[ Events ]

[ Discussion ]

johannes: link to TF-TD on media types and data structures

dsr: think about services
... server provides APIs
... register a proxy
... need URI to identify the resource
... when you change the proxy, how the change would propagate?
... all the proxies need to notify

johannes: the difference is that we're expected to subscribe some specific property

dsr: question of granularity
... what if you have a million/billion of protocols

johannes: maybe we don't have to subscribe all the resources
... how to model APIs?
... for example, if I want to know the temperature of this room
... how can I do that?
... not necessarily controlling things

michael: properties and events need to be mapped with existing mechanism

johannes: negotiation of protocols
... add note: Things can be exposed through several end points

don: time information?

dsr: within home, there is some mechanism for time synchronization

johannes: would mention proxies?

don: large number of proxies

dsr: depends on the use case

don: proxy servers, embedded servers
... double security nightmare

johannes: we also talked about security today
... who should be in and out?
... how to identify who calls whom

dsr: security risk?
... what kind of security requirement?

[ Discussion topics of TF-AP ]

johannes: not contradictory with this kind of model?

(no objection)

johannes: will brush up this for tomorrow's discussion
... register callback and get data by calling get

vlad: if you just want to get data, don't have to use subscribe

dsr: if you want to use history, logging is needed
... e.g., multimodal interaction
... speech interface uses context, and it depends on applications

johannes: might want to know the timing the latest event occurred

vlad: if I'm interested in when the event happened
... what do I need to do?

dsr: platform dependent issue...

kaz: for automotive vehicle api, we have common data type of timestamp for all the properties

dsr: ideally correct, but would be difficult for small devices to handle timestamps

vlad: could show some standard way though don't have to use it
... if there is local timestamp available we can use it
... if not, the server can add timestamp

dsr: might be able to have timestamp information or frequency information

michael: some media type may provide time-related information
... don't know about the "right" solution, though

kaz: anyway we need timestamps to integrate all the related resources
... and if small devices can't provide time information, the smarter servers can provide it instead
... so we should think about how to integrate all the related time information

[ Sebastian joins ]

johannes: the point here is we need to handle time information regardless of how to get it
... the other point is spontaneous events
... could have a log
... get requires answer

dsr: message ID could be used to identify events

michael: could still ask for log
... timestamp with empty value?

johannes: time series by the server

michael: different URIs might be used

johannes: one possibility is empty object

michael: can ask for the timestamp when the last event occurred

jay: you have metadata
... could have two kinds of timestamps

dsr: had discussion on streams yesterday
... server itself might provide on what communication happened

vlad: would be more important to think about what kind of format would be used

johannes: how would we modify the situation

michael: how you interact using the events?

johannes: adds note
... streams: filtered read, timeline

michael: how you want it filtered?

johannes: we have same picture now?

(some more discussion on event subscription)

[ Protocol-agnostic resource model for web things ]

johannes: static properties should be in Thing Description?
... add changes:
... metadata should be in Thing Description with no own runtime rep
... will continue the discussion on properties, etc., tomorrow
... summarizes today's discussion
... on Actions, etc.
... how to make it scalable and robust
... timestamping of events
... discussion points on media types and data structure, etc.

[ Day2 ends ]