W3C

- DRAFT -

APIs and Protocols task force

26 Aug 2015

Agenda

See also: IRC log

Attendees

Present
Kaz, Dave, Hans, Claes, Daniel, Frank, Johannes, Arne, Michael, Kazuaki, Louay, Oliver, Sebastian, Taki, Yingying, Yoshi
Regrets
Chair
Johannes
Scribe
dsr

Contents


<scribe> scribenick: dsr

Johannes invites Frank Reusch to introduce himself as a newcomer to the WOT IG

Frank: I am from RWE, a German company. We’re happy to take part in this group.

Johannes reminds people about the next face to face meeting in Japan, and the plugfest to be held there.

He runs us through the rest of the proposed agenda.

<scribe> agenda: https://lists.w3.org/Archives/Public/public-wot-ig/2015Aug/0066.html

Technical details / interop guidelines for the TPAC plugfest, call for participation

Johannes: we first need to prepare the guidelines for the plugfest. We’re thinking about a home automation use case

We invite people to bring along implementations, preferably hardware and software. You should first publish a thing description for it covering the data model. We will assume a fixed thing semantics this time around.

We need to know what people are planning as soon as practical.

We expect to use either Github or the wiki to collect input.

<kaz> Github page

Anyone ready to volunteer that their plans right now?

Louay: we’re planning to bring a discovery demo from Fraunhofer FOKUS.

Johannes: it would also be good to include something people can access for demo purposes.

Kaz: I am wondering about the mechanism for the plugfest. Is it okay for participants to showcase other use cases, and not to require all demos to be integrated?

Johannes: I see two categories of demos, the plugfest focusing on interoperation, and separate demos showcasing concepts and mechanisms

Kaz: we need to specify the interfaces if we are to get interoperability

Johannes: this is what we need to define as soon as practical

The starting point is the thing description.

Something roughly equivalent to WSDL that tells you how to interact with a thing

Johannes: we also need to prothecols and message formats

Kaz: companies might want to provide demos for different application domains

We might want to think about how these demos could be integrated

Johannes: we’re trying to define the interfaces …

<kaz> [fyi. IETF defines WebSocket protocol (for WebSocket connection) https://tools.ietf.org/html/rfc6455 ]

Dave: I want to suggest we also allow web sockets, and I volunteer to document the message formats on the plugfest wiki/github page these are currently documented at https://github.com/w3c/web-of-things-framework/blob/master/bindings.md

I am happy to help people who are interested in using my NodeJS implementation.

Kaz: we could include web sockets as a transport layer protocol and document them on the page Johannes suggested

Johannes: we should limit the number of IoT protocols for the plugfest, but leave it open for other demos

People who want to participate in the plugfest would then pick from the protocols we’ve selected.

Is that okay?

Kaz: yes

<kaz> MMI Interoperability Test Report

Kaz discusses work in interoperability in the Multi Modal Interactio WG some years ago

we could perhaps do something similar here

Johannes: what were the lessons learned from the MMI Interop exercise?

Kaz: interoperability was shown at a component level using the components provided by different companies

Johannes: we should aim to have protocol bindings described as a first cut by the end of this week

Kaz: we should think about the scenario (use cases) e.g. a narrative

Johannes: I think we should agree on the metadata format for data models and protocols, but we are unlikely to agree on a detail ontology for thing semantics by TPAC

Dave: I see the WoT plugfest page at https://github.com/w3c/wot/tree/master/plugfest but we need to agree today on where to add our input on data models and protocols?

Johannes: If no none disagrees, let’s use this github folder.

Dave: I am also concerned about practical details, e.g. the need for wired Ethernet and a block of addresses we can use for static IP addresses. We can then list those on the plugfest page for each demo.

Johannes: We’re thinking about using a single HTTP server to deliver thing descriptions and server protocol descriptions.

Dave: a CoAP client wouldn’t be able to access the HTTP server, so we may need work arounds

<scribe> ACTION: Johannes, to a headline in the readme.md on the logistics [recorded in http://www.w3.org/2015/08/26-wot-ap-minutes.html#action01]

<trackbot> Error finding 'Johannes,'. You can review and register nicknames at <http://www.w3.org/WoT/IG/track/users>.

Johannes summarises ideas for what the protocol definitions will involve

We also need to agree on a format for the definitions.

… i.e. how to structure the document to ensure consistency across protocols

Sebastian: we need to agree on the data format, e.g. raw JSON

Johannes: that would work for Linux based devices or their equivalent, but not for microcontrollers

Any disagreement? [no]

Kaz: some of the companies may want to demo XML and EXI

Dave: sure, they should feel welcome to bring such demos, but I am not sure we will have enough such demos as part of the plugfest itself

I plan to demo a compact byte encoding for microcontrollers

Johannes: if we have several companies wanting to use EXI in the plugfest, we can include it

Michael: are we expecting to use RDF for the protocol metadata?

e.g. using JSON-LD

Sebastian: the thing description can be expressed as JSON-LD and could include protocol bindings

We plan to discuss this further over the next few weeks

Michael: I’m thinking about the web today, and there definitions for how do things, e.g. how to submit an article to a website.

Johannes: I get your point …

Michael talks about state machines.

Dave: we need to cleanly separate the metadata for things and servers and come up with a simple approach sufficient for the plugfest

Johannes: it would be good to exchange some examples via email to clarify the issues, is that okay?

Michael: yes

use case for security and privacy discussions

The security and privacy task force is seeking help with requirements, see: https://www.w3.org/WoT/IG/wiki/Security%26Privacy_Requirements_Catalogue

<Sebastian> First idea of a protocol binding from TD to CoAP / HTTP can be found here: https://github.com/w3c/wot/blob/master/TF-TD/Tutorial.md#property-colortemperature (based on the LED TD)

Johannes explains the request for a use case for requirements analysis

He proposes to use the same example as for the plugfest, i.e. home automation

Dave: it would be helpful to understand what kind of aspects they are interested in as there are a huge range of possible use cases each of which illustrates different aspects of security and privacy

Johannes: any suggestions for use cases?

Oliver: different use cases touch on different aspects, e.g. industrial automation may have little impact on privacy, we therefore want to look at the use cases of interest to the different WoT Task Forces.

If it is okay for the TF-AP, I would like to attend your next call for preliminary discussions of say the home automation use case

Johannes: in the absence of objections, let’s go with the home automation, however, please feel free to comment on the mailing list

Johannes talks about actions at the REST level

Dave: we need to keep separate the treatment at the applications scripting level and the transport layer

Michael: exactly

Johannes: so that the scripts are independent of what protocols are being used

… out of time so end of meeting …

Summary of Action Items

[NEW] ACTION: Johannes, to a headline in the readme.md on the logistics [recorded in http://www.w3.org/2015/08/26-wot-ap-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/08/26 14:38:47 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/to/the/
Succeeded: s/the/that/
Succeeded: s/including/include/
Found ScribeNick: dsr
Inferring Scribes: dsr

WARNING: Replacing previous Present list. (Old list: kaz, dave, hans, claes, daniel, frank, johannes, kazuaki, louay, oiver, sebastian, taki, yingying, yoshi, Yingying_Chen, Claes_Nilsson, Sebastian_Kaebisch)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ kaz, dave, hans, claes, daniel, frank, johannes, arne, kazuaki, louay, oiver, sebastian, taki, yingying, yoshi


WARNING: Replacing previous Present list. (Old list: kaz, dave, hans, claes, daniel, frank, johannes, arne, kazuaki, louay, oiver, sebastian, taki, yingying, yoshi, Johannes_Hund)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ kaz, dave, hans, claes, daniel, frank, johannes, arne, michael, kazuaki, louay, oiver, sebastian, taki, yingying, yoshi


WARNING: Replacing previous Present list. (Old list: kaz, dave, hans, claes, daniel, frank, johannes, arne, michael, kazuaki, louay, oiver, sebastian, taki, yingying, yoshi)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Johannes, Arne, Michael, Dave, Kaz, Hans, Kazyaki, Sebastian, Oliver


WARNING: Replacing previous Present list. (Old list: Johannes, Arne, Michael, Dave, Kaz, Hans, Kazyaki, Sebastian, Oliver)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Kaz, Dave, Hans, Claes, Daniel, Frank, Johannes, Arne, Michael, Kazuaki, Louay, Oliver, Sebastian, Taki, Yingying, Yoshi

Present: Kaz Dave Hans Claes Daniel Frank Johannes Arne Michael Kazuaki Louay Oliver Sebastian Taki Yingying Yoshi
Agenda: https://lists.w3.org/Archives/Public/public-wot-ig/2015Aug/0066.html
Got date from IRC log name: 26 Aug 2015
Guessing minutes URL: http://www.w3.org/2015/08/26-wot-ap-minutes.html
People with action items: johannes

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]