W3C

- DRAFT -

WoT IG - APIs and Protocols TF

30 Apr 2015

See also: IRC log

Attendees

Present
kaz, kosuke, johannes, claes, daniel, david, joerg, kaji, kazuaki, matthias, robert, taki, victor, Claes_Nilsson, ryuichi
Regrets
Chair
Johannes
Scribe
dape

Contents


Joh: Agenda
... 1. Additions & Changes to the Agenda
... 2. Dom presentation (Input about data structures and interactions shifted)
... 3. Input from iotkit-comm
... 4 . Action items
... 5. Examples from Claes
... Any addition/changes to agenda?

Kaj: Update w,r,t. slides via mailing list

Joh: Please start Kajimoto

<kaz> [ https://lists.w3.org/Archives/Public/public-wot-ig/2015Apr/att-0074/W3C_TF-AP20150430v2_Panasonic_Kajimoto.pdf ]

Kaj: Please open slides
... Slide 2: Original input at F2F meeting in Munich
... Right side: HTTP protocol to WoT server. Wot Server can be adresses by URI
... WoT server provides REST API
... WoT Server uses TDL document (what/which device)
... status at the f2F

Kaj: Slide 3: Use case home automation (discovery)
... user uses smartphone ... dicovers available devices
... WoT server is manager. App requests devices. Server responds with list
... currently Panasonic uses propriatory binary format for data exchange

Kaj: Slide 4: After discovery App selects e.g. air conditionar
... next step: which kind of service air conditionar can provide
... Agent provides device type and additonal information (owner etc)
... information come from different databases... registration and/or manufacturer
... "Total Manager" communicates across multiple WoT Servers and agents
... Slide 5: Users can control device (with previous information)
... e.g., command cool down to WoT server and WoT Agent
... WoT server interprets "abstract" command and maps it to "real" command (ECHONETLITE)
... Slide 6: about setup up process
... WoT Server at first does not know devices
... home gateway posts "add new device" to WoT Server
... step3: about including device attributes
... Slide 6: About Notification

<kaz> [ https://lists.w3.org/Archives/Public/public-wot-ig/2015Apr/att-0074/W3C_TF-AP20150430v2_Panasonic_Kajimoto.pdf ]

<kaz> [p6 of the above slides says "Home Automation (Notification)"]

Kaj: GW pushes to WoT (agent/server) information to smart phone that for example air conditioner has been switched off or so..

Joh: Comments?
... Question: Home Gateway converts between Wot protocol and Echonet-Lite...where are those servers.. both "in" the home?

Kaj: WoT server implements GW function.

JoH: Wot server in cloud or in home device?

Kaj: combination

Kaz: suggest differiantate between HW layer and Protocol layer

Joh: Next on the agenda. Presentation from Dom
... iotkit-comm / Intel is next. anybody here?
... not
... Claes, would you prepared?

Claes: Not ready yet. Could provide input for next meeting
... tricky part authentication won't be part of it
... will provide input via mail

Joh: Meeting schedule: decided to have weekly meetings in the beginning... alternating timezones
... setup doodle... not many people participated

<jhund> http://doodle.com/cw5tdschat6i29w7duhctvzh

Joh: suggest Tuestday to Thursday due to alternating timezones
... according doodle Thursday looks good
... let's schedule next meeting on Thursday (US timezones)

Joerg: Proposal: shift it always by 8 hours.. will add information in wiki

Joh: Next on agenda: call for AI
... architectural figures for use case
... are there contributions?
... We have one.. can sart
... Server called serviant (acting as server and client)
... serviant can be connected with other serviants...
... can be connected by browsers etc
... serviant uses protocol mapping
... on top is API..... and Application
... will send figure on mailing list
... any comments

Kovatsch: looks similar to what we have in IETF (combination of server& client)

Joh: Any reference to link to at IETF

Kovatsch: CORE interface draft uses this approach
... will provide information on IRC

<kaz> MMI Architecture

Kaz: diagram similar to multi modal archcitecture

<mkovatsc> https://tools.ietf.org/html/draft-ietf-core-interfaces-02

<mkovatsc> Only use for the mixed client/server role on devices (for now)

Joh: Did you use a special word for the combined serviant (server: interaction manager and client: modality component)

<mkovatsc> also see https://tools.ietf.org/html/draft-ietf-core-resource-directory-02: devices register in client role and then serve resources as server

Joh: example about REST API
... mapping to protocol ...did not find abstract model.. used http
... identidied WebIDL for abstract definition of API
... need to define data structure for event
... details can retrieved by following link
... datastracutures across various format should be the same
... API should use WebIDL
... need to find common denominator accross the many APIs
... server reports errors if any..
... Comments?

Kovatsch: missing concept of hypermedia type...
... which content type.. how to send data

Joh: There is a task force that should deal with it....

Kovatsch: It is more about the style of the API (e.g, RMI)

Joh: will publish document... Mattias can you annotate what you mean

Kovatsch: sure

DP: should make it available.. so that other have a better change to comment.. (said already)

AOB

none

Joh: will send out arch figure and document via mail
... will also inform you about next meeting

[adjourned]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/05/01 08:10:10 $