Group photo from PlugFest preparation on Nov. 4-5
Group photo from WoT WG/IG f2f meeting on Nov. 6-7
Group photo from WoT PlugFest Demo on Nov. 8
(Some more photos are available online.)
Matsukura-san's slide based on the results of the PlugFest preparation on Sunday
<kaz> scribenick: dsr
Kajimoto-san introduces the agenda
Matthias asks people who here for the first time to raise their hands
<Vagner_Br> https://github.com/w3c/wot-architecture/blob/master/terminology.md
Matthias points to the WoT terminology document as an aid to understanding the terms we are using
<kaz> WoT Terminology
<kaz> WoT Architecture document
Matthias decribes how we are using the term “servient” for a WoT end point
<kaz> [Matthias explains the architecture based on the Figure 12 in the document]
<zkis> "Endpoint" needs to be defined. For instance in OCF there could be multiple endpoints in a "servient" (device)
“Thing” is an entity that has a thing description.
Zoltan notes the need for defininging the term “end point” for WoT.
Michael: we should collect terms where we need further discussion.
Matthias asks for feedback from newcomers
Kathy: (Mozilla) “Servient” is a little new to me as a term
I would prefer words that better reflect what people are implementing
<benfrancis> Why not just use "server" and "client". Surely not every server needs to be a client?
<zkis> example for OCF endpoint list for a device (servient): "eps": [
<zkis> {"ep": "coap://[fe80::a4ca:5493:e96:3cea]:1111", "ttl": 86400,"pri": 2},
<zkis> {"ep": "coaps://[fe80::a4ca:5493:e96:3cea]:1112", "ttl": 86400,"pri": 1},
<zkis> {"ep": "coap+tcp://[2001:db8:a::123]:2222", "ttl": 86400,"pri": 3}
<zkis> ]
Michael: new terms do create a learning curve for newcomers
<benfrancis> (and not every client needs to be a server)
<scribe> ACTION: mkovatsc to review terminology in regards to reducing the learning curve
<trackbot> Created ACTION-122 - Review terminology in regards to reducing the learning curve [on Matthias Kovatsch - due 2017-11-13].
<kaz> [Matthias explains the structure using Figure 9]
Matthias continues his walk through the architectural landscape for WoT
This includes gateways, clouds, web browsers, direct access to devices
Enabling devices to function as first class web of things citizens avoids the need for gateway hell
Kathy: where do you see interoperability with IoT standards, e.g. OCF and oneM2M
Matthias: this is what we use binding templates for as a means to interface with different IoT standards
Michael (Intel): Intel is part of OCF and we’ve been working on OCF integration as part of our plugfest work
<mkovatsc> https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame
<zkis> Michael: OCF already presents metadata description of interfaces, we try to convert those to WoT Thing Descriptions
Matsukura-san presents an overview of the plugfest that took place over the weekend
<Mizushima> https://github.com/w3c/wot/blob/master/plugfest/2017-burlingame/preparation.md
Matsukura-san shows a diagram that shows the relationships between the components provided by different participants.
Matthias provides further background on the use of local proxies
Michael: one challenge is there can be multiple URIs and channels for the same device, so comparing them can be difficult.
<kajimoto> -
<scribe> ACTION: Sebastian to provide text on TD management and publication
<trackbot> 'Sebastian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., sha, skbisch).
<scribe> ACTION: skbisch to provide text on TD management and publication
<trackbot> Created ACTION-123 - to provide text on td management and publication [on Sebastian Käbisch - due 2017-11-13].
Michael: semantic search is important
Darko: we will talk about this later
Michael describes how he handles local and remote URIs for things
(Dave: this seems to be a confusion between URIs as identifiers for things, and URIs for accessing things)
Michael: we should table this for now and come back to it later.
Matsukura-san continues with his summary of the plugfest
Matthias: any other issues that came up in respect to synchronisation?
[no]
Michael presents some slides on semantic and his work on an OCF metadata translator
There are some semantic annotation issues, e.g. missing or inconsistent terminology
these reflect the lack of maturity in IoT ontology development
Michael: we want to describe things as hosting a set of capabilities
Darko: we’ve been looking at using the capability vocabulary from iot.schema.org
<kaz> -> iot.schema.org iot.schema.org
He shows how this has been integrated with the thing directory
The iot.schema.org vocabulary is based upon existing models
Richard: What is the mechanism for contributing to the iot.schema.org work?
Darko: Michael Koster and I are leading this as a community group
What provision is made for versioning of models?
Darko: we haven’t looked at that as yet apart from Github itself
We want to follow best practices from schema.org
Michael: the version could be included as part of the URI
Darko: for now this is really experimental and put in place for this plugfest
Matthias: the thing description defines how a given capability is expressed as the object interface.
<kaz> iotschema.org/Capability
Darko: as the schema’s mature, they can be moved over to schema.org
Michael_KostElena: we plan to use W3C Community groups to support this
We need to enable people to describe their own devices effectively
Dave: this relates to my new role as the W3C Data Activity lead, and the study I am doing with the Open Data Institute on tooling and practices for web data standardisation - the aim is to make W3C a better venue for web data standardisation
I will send a pointer to the study to the public list
Matthias introduces the scripting API
scribe: and the challenges for including metadata in the API
Darko: We already need to define some common prefixes for namespaces.
Daniel: this is like qualified names for XML, and we should discuss this further
<kaz> [[
<kaz> General Thing metadata:
<kaz> dictionary ThingInit {
<kaz> DOMSTring name; USVString url; Dictionary description;
<kaz> };
<kaz> Interaction annotations:
<kaz> dictionary ThingPropertyInit {
<kaz> sequence<SemanticType>semanticTypes; ThingDescription description;
<kaz> };
<kaz> Algorithm for contexts:
<kaz> dictionary SemanticType {
<kaz> DOMString name; USVString context;
<kaz> };
<kaz> ]]
<kaz> Nimura: what about normalization/categorization of the vocabulary?
<kaz> ... same terms from various industries
<kaz> Matthias: something to be discussed by the LD TF
Matthias: this sounds like something for the semantic processing task force
<zkis> The SemanticType dictionary is meant for defining solution-specific or standardized semantic type annotations with an ExposedThing. The other Things that take part of the solution will understand them. All other will understand the standardized one (atm none).
<benfrancis> Regarding plain JSON serialization, task force in Interest Group working on a proposal here https://benfrancis.github.io/wot/proposals/json-td/index.html
Matthias notes that challenge of scripting access to thing descriptions for introspection.
<benfrancis> (sent pull request to W3C repo for comment https://github.com/w3c/wot/pull/363)
Dave: you could use a simple JSON API or an RDF based tripple API
<kaz> [morning break]
<kaz> scribenick: kaz
Matthias: [Beaer Token]
... "security": {
... [Forward Proxy]
... security feature
... mode: proxy,
... href: http://plugfest.thingweb.io:8087,
... authorization: Basic
... }
... what kind of security is used
McCool: assume HTTPS
... issue on local HTTPS
Matthias: need certificate for
HTTPS
... any body working on security?
... maintaining the security part of the code?
... beaer token
McCool: will be
Matthias: authorization: Bearer ?
... root certificate you need
... we can have wot client
... how to get credential?
Kaz: Ajitomi-san from Toshiba
working on HTTPS local network
... breakout session on Wednesday
Matthias: the session time is not assigned yet?
Kaz: right
Matthias: any comments from Elena?
Elena: what the proxy should do?
Matthias: kind of how to solve the
security issues over the firewall
... local proxy connected to devices behind the firewall
... what kind of authorization mechanism for security?
... e.g., water pump plant in Munich
Elena: need to describe access control
McCool: every resource linked with
authorization mechanism
... can collect access control information
Elena: you want to specify the
number of the devices
... need to care about the structure of the system
Matthias: you can access everything
once you got access
... within the network, e.g., a factory
... a possibility is not allowing permission for accessing
devices
McCool: not showing devices people
don't have permission
... TD to specify who to get access permission?
... do we want to have another level for security?
Matthias: would recommend not too
engineering mechanism at the beginning
... big iot project presented in Dusseldorf
... snippets of different actions
... separated from the basic TD use cases
... we can see good practices already
... example was
... the web server shows links
... which you can interact with
... also enforcement later on
... possible administration view
... could be a good way
Elena: do we need to combine security here?
Matthias: could be done separately
<ohsumi> exit
Matthias: but could be combined and go
to some specific field
... how is it aligned with TD?
... proxy consumes and forwards information to devices
... e.g., remote devices in Munich
... proxy also there
... convert information to the public side
Elena: proxy verifies the connection?
Matthias: only the authorized fields go
to the device side
... should discuss more concrete industry use cases
Sebastian: have a comment
... should be more flexible
... e.g., multiple security entries
Matthias: reminds me of 2 things
... merging the areas
... identify to use which one, this or that
Sebastian: we can put 2 information
Matthias: [Bearer Token]
... hoping to have more examples
... e.g., OCF bridge
McCool: OCF bridges don't include OCF security yet
Matthias: spec published?
McCool: OCF 1.0 is public
Matthias: one part is testing and
another part is collecting good use cases
... multiplexing and merging different approaches
... what about Panasonic's security approach?
... already as an array?
McCool: we identify the roles of each
one
... from the array
Elena: each approach may have some issue
Matthias: we keep it open
... and would look into other organizations
... would suggest we don't try over-engineering at the
moment
Matthias: possibility of observable
property
... [Observable Properties]
... change-of-value notifications
... good match with CoAP observe
McCool: related to actions
... had discussion during the plugfest
... we have properties and get/set
... separately declared
... related issue on actions
... observable is kind of event
... implies events
... would be useful to have some simple mechanism
... handle the issues consistently
Matthias: [Interaction Model]
... discussio with Koster
... buffer on the semantic model
<Zakim> dsr, you wanted to mention observables and data validation
Matthias: [Observable Properties]
Dave: data validation
... you can define different handlers
Matthias: talking about the
implementation viewpoint?
... this idea itself is independent from JS or anything
... (going back to the slides)
... [Observable Properties]
Dave: properties are observable
Matthias: don't have to define
events
... what would be the best fit for use cases?
<dsr> observerables as per ECMAScript
Zoltan: talks about some
scenario
... expose some property
<dsr> observables provide a design pattern for value changes and for handing errors, e.g. when an assignment conflicts with a properties description
Zoltan: people need to specify which property is observable
McCool: we can specify a property is observable
<dsr> (Dave wants to know the use cases where properties are not observable)
McCool: but how can be observable?
Matthias: you've described what to do on the binding level
<dsr> ECMAScript observables: https://tc39.github.io/proposal-observable/
McCool: marking if a property is observable is simple extension
<dsr> Also: https://github.com/tc39/proposal-observable
Matthias: how much support for
this?
... we have to come up with some concrete text
... anyone remember who brought this idea?
Sebastian: started with CoAP observe?
Koster: explains
... suggestion not to have event handling for each
property
... goes back to multiple interaction protocols
... my theory is having events to handle more high-level
controls
... not just for set/get
Matthias: value notification
associated
... difference from change value notifications?
... in that sense, I can follow the discussion
... any other opinions?
Sebastian: what we have at the
moment
... question on interaction model
... need both property and event?
McCool: there are systems
already
... just read/write/observe
... no other things
... think about eventing model
... pub/sub etc.
Zoltan: event means notification
Koster: change of the state
McCool: should be observable property
Koster: need events of some kind
McCool: should have simple events
Matthias: the issue is that it's quite
complex
... CoAP has observable property functionality
... need consistent mechanism with that
Koster: CoAP observable is
unreliable by design in that way
... most of the protocols have good hand-shaking
mechanism
... which CoAP doesn't have
Zoltan: we can't guarantee event delivery
richard: what's the practical way?
<zkis> we can't guarantee event delivery
richard: who would get notification?
McCool: get/set/observe kind of methods could be used
<dsr> Dave thinks this is overblown. The synchronisation protocols need to transmit property value updates and regular events, so in principle, any property can be observable, and this is mostly about the API, e.g. the ECMA observable pattern
richard: talks about some
example
... button press could be observable
... you can get any status the system exposes as
observable
... any reason not to make any properties observable?
Dave: should decouple from the underlying protocols
McCool: an example of HTTP
endpoint
... can get/post values
Matthias: would summarize
<benfrancis> This is the problem with everything being so abstract. If a device implements a REST API then all properties can support GET and PUT. If a device implements a WebSocket API then all properties can probably be observable. But trying to define this in an abstract way for all possible bindings is... challenging.
Matthias: nice to get comments
... we can't guarantee events reach the user
... you might miss something if the connection is lost
... if you have a critical application, need some additional
mechanism
<benfrancis> I don't see how ECMAScript observables helps. That's just if the API is being consumed in JavaScript and doesn't explain how property changes and events are sent over the wire.
Matthias: there is a pro with having
observable property
... events to be used for important purposes
... would suggest we start implementation for events
... have to tackle the issue of events
Zoltan: action to return TD?
Matthias: not enforced
McCool: you could follow HATEOUS approach for example
<benfrancis> Again, getting concrete... With REST an action request can be POSTed and then GET the resulting action request URL to get status. With WebSocket API could use requestAction and actionStatus messages asynchronously.
Kajimoto: before lunch, some
announcement
... demo from 13:15
[lunch]
McCool: how to get location?
... registered?
Matthias: goes through the draft
specs
... terminology defined within a separate page
actual definition on the MD file
Matthias: goes through the use cases
Matthias: Security considerations
Matthias: and actual content on the architecture
scribe: Thing, Thing Description, Binding Templates
McCool: security contains many resources
Matthias: Scripting API
... explains the structure of the documents
... WoT Architecture itself as a document
... and documents on each building block
... next WoT deployment scenarios
WoT deployment scenarios and guidelines
Matthias: WoT client, Servient on
Device
... resource-constrained device as a Thing
... bigger picture on "servient on cloud server and gateway"
(Fig 19)
... servient on cloud server only (Fig 20)
... please add your scenarios as well
... need more work on discovery
... connectivity and security
... need guidance from the security group
... we should add clarifications based on what we've been
doing
... people prefer simple approach as a starting point
... so maybe can start with the Thing directory approach
soumya: working on discovery tf
Matthias: this is higher-level discussion here
McCool: Thing Directory could be a
SPARQL endpoint
... would be powerful
... and multiple endpoints could collaborate with each
other
Matthias: need to describe issues and
guidance
... what are the design patterns people need
soumya: looked into the SPARQL
option
... will be happy to do more detailed work
Matthias: question on "who have read the FPWD?"
(some raise their hands)
Hadley: accessibility issues?
Matthias: so far machine-to-machine
communication
... what kind of user interface needed
... could be levelaged by some kind of multimodal interface
kathy: separated UI from the system
McCool: e.g., audio audible
alarm
... accessibility requirements
Kaz: mentions there was a session on accessibility for WoT during the Web Conf last year
Hadley: would like a link to the report from the session on accessibility for WoT during the Web Conf last year
W3C Track sessions at WWW2016 in Montreal
Michael Cooper's slides on "WOT Ecosystems: Designing Human-Centric Sensory Modalities"
<mkovatsc> https://www.w3.org/TR/2017/WD-wot-thing-description-20170914/
Sebastian: [Basic Facts about TD's
FPWD]
... reflects the experiences of around 8 PlugFest meetings
... (summarizes the plugfest efforts)
... reflects WoT's Properties, Actions and Events
... domain independent
... open to integrate exisiting domain knowledge
... expectation is being index.html of Things/devices
... [TD Core Model]
... (explains the TD model diagram)
... what kind of interaction model you use?
... how does the payload look like?
... reflecting communication metadata
... [TD Serialization with JSON-LD]
... small example TD
... define context, e.g., w3c-wot-td-context
... W3C WoT TD vocabulary
... and domain-specific vocabulary
... JSON Schema-base types and semantics
... e.g., Celsius as unit
... possibly which kind of UI to be used
... [Let's go in!]
Matthias: asks who read the TD draft
(some, more than the architecture, raise their hands)
Sebastian: goes through the
document
... Introduction, Terminology
... Namespaces
... TD relies on
... can follow the link to get the namespace
Sebastian: open issue on listing all the
possible namespaces
... another issue on validation
... just the structure?
... or need interpretion?
... what is the expectation?
... and then core model
... next, serialization as JSON-LD
... discussion during the TD task force calls
... can reuse external context using "@context"
... multiple examples there
<McCool> McCool: noting in passing that TD doc describes "security" as containing "an array of objects"
Sebastian: example 3 on sensor
... link capability
... and security
... currently short section
McCool: array of objects
... in the table at 6.1
... is that correct?
Sebastian: complex type is
possible
... (goes through "6.5 Type System")
Matthias: related to binding
... abstract structural description for inter-conversion
... how to serialize that
kathy: Ben provided some idea on possible serialization
Sebastian: will talk about that
later
... we have to describe what the client expects
Darko: representation of complex
data type
... how to validate?
... JSON Schema?
... how to translate complicated data written in RDF?
Matthias: take the vocabulary from JSON Schema but represent the date in JSON-LD
Darko: can you still apply JSON Schema?
Sebastian: is your point "how to
validate TD"?
... that's still an open issue
McCool: no type associated with
property itself
... maybe good to have default mapping for property itself
Sebastian: question about payload
... what the device offers
... how you can get access to the data?
... we should be clear about the differentiation
McCool: is there any simple default coding?
Sebastian: we can use JSON Schema to
check the structure
... and then
... plenty of examples here
... and need to add content for security&privacy
considerations
... [Current Experiments and Next Plans]
... introduce observable flag in property for TPAC
plugfest
... JSON Schema as linked data representation
... metadata for some protocol bindings, e.g., method,
headerOptions, ...
... URI template, e.g., /blabla/{timestamp}
... TD management and publication
... alternative TD serializations (Mozilla proposal, EVRYTHNG
proposal)
... how the core TD model should look like?
... to integrate domain-specific knowledge, etc.
... Daniel looking into binary serialization, e.g., EXI and
CBOR
Matthias: given the time schedule,
maybe could talk about JSON serialization?
... need to clarify extension points
... JSON-LD work by the WG
... and JSON work by the BG so far
kathy: Ben made a proposal
<sebastian> https://benfrancis.github.io/wot/proposals/json-td/
<kgiori> https://benfrancis.github.io/wot/proposals/json-td/
Dave: (will talk about that for
Ben)
... [JSON Web Thing Description]
... (shows the example including "My Lamp")
[[
{
"name":"My Lamp",
"type": "thing",
"description": "A web connected lamp",
"properties": {
"on": {
"type": "boolean",
"description": "Whether the lamp is turned on",
"href": "/things/lamp/properties/on"
},
"brightness" : {
"type": "number",
"description": "The level of light from 0-100",
"min" : 0,
"max" : 100,
"href": "/things/lamp/properties/brightness"
}
},
"actions": {
"toggle": {
"description": "Toggle the lamp on and off"
}
},
"events": {
"overheating": {
"description": "The lamp has exceeded its safe operating temperature"
}
},
"links": {
"properties": "/thing/lamp/properties",
"actions": "/things/lamp/actions",
"events": "/things/lamp/events"
}
}
]]
Dave: some of them not necessary
McCool: we don't have
"description"
... we have properties associated with input/output
... so not just an alternative data format
Matthias: different model
... we could cover the details, though
... what is the parameter for interactions?
Dave: would look into the
proposals by Ben and EVRYTHNG
... each company involved in HTTP
Matthias: more complicated example
could be also covered
... there is no media type definition but could assume it's
application/json
... also could think about invisible properties like
description
Sebastian: 2 years ago when we started
TD work, the definition was similar to this
... but after 8 PlugFest efforts, TD has changed
... btw, not sure about links
McCool: probably more contentious
[[
"links": {
"properties": "/thing/lamp/properties",
"actions": "/things/lamp/actions",
"events": "/things/lamp/events"
}
]]
Matthias: there are several discussions
which have been done separately
... we remove type as property from TD
Dave: this work is still at its early stage
Matthias: how it would look like with some more complicated use cases?
Dave: would require further investigation
Matthias: we've been working as the
whole group during PlugFests
... but you've been working separately
... maybe you could bring your implementation to PlugFest
Sebastian: there is a GitHub repo to collect concrete TDs for the PlugFest in Burlingame
<yamada> https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame/TDs
Sebastian: you can put your TDs there
Matthias: one of the optional building blocks
Matthias: WoT object and APIs
Matthias: 3 methods: discover, consume and expose
<McCool> McCool: before I forget: noticed that in TD document all examples for properties show only "outputData" but there is no example for a writable Property which needs both inputData and outputData with the same type... which shows the weird issue that Properties don't have types, only their input and outputs do. Perhaps properties should have types... then we could infer default JSON encodings (for example) for inputData and outputData (depending on "writable")
Matthias: abstraction for Things
... wot.discover() to discover things
... consume means using device's capability
... scripting discussion one year old
... we're operating the spec defined by this document during
our PlugFest
... ThingFilter dictionary
... ConsumedThing interface
... requests to servers to retrieve/update properties, invoke
actions, etc.
... setProperty, getProperty
... observe, originally for events
... no implementation for observable property, maybe next
PlugFest
... next, ExposedThing interface
<sebastian> I uploaded the TD FPWD slides here: https://www.w3.org/WoT/IG/wiki/images/b/b5/TD_First_Public_Working_Draft.pdf
<sebastian> welcome
Matthias: TD builders: addProperty,
etc.
... need simplification
<zkis> see also https://github.com/w3c/wot-scripting-api/issues/78
Matthias: hooks using
RequestHandler
... personally think it's confusing to have both TD builders
and request handlers
... how to modify Things dynamically?
... need detailed algorithm definition
... nimura-san?
... browser implementations can cover HTTP/HTTPS
... WebSocket might be complicated since it has initiation
part
... good to see CoAP support by Web browsers
McCool: going to use polyfill
Matthias: JS approach quite inline with the Web Browser work
Dave: how many implementations for Scripting?
Matthias: 3?
... Fujitsu, Intel (Zoltan for node iotivity) and Siemens
(node-wot)
McCool: we're more focused on JavaScript version
Matthias: there is a chance to use another abstraction but so far we've been focused in JavaScript
Zoltan: there is an issue on scripting
<zkis> https://github.com/w3c/wot-scripting-api/issues/78
Matthias: what is the minimum set for a runtime?
<zkis> see comment https://github.com/w3c/wot-scripting-api/issues/78#issuecomment-340699513
[[
Promise<ThingDescription> fetchDescription(USVString url);
]]
Matthias: for the ConsumedThing interface
[[
Observable<any> observe(DOMString name); // event / property change notifications
]]
Matthias: for both observable events and properties
richard: observe for consumedThing?
Matthias: could be 2 entries, but do we really need 2?
richard: 2 different
concepts
... another point, should change the name for
"description"
... maybe text?
McCool: +1
Matthias: Thing builder...
... opening a can of worms...
... if you create an object for a Thing, you'll feed some
TD
... what would be a programmatic approach?
Zoltan: nice to have concrete use
case description and continue the discussion
... would like input for my comments
[afternoon break till 15:45]
Koster: [Protocol BInding
Templates]
... problem solved with protocol bindings...
... adapt common WoT client abstraction to diverse things
... which use different protocols
... architecture
... layer between application clientand device protocols
... [Use cases]
... mapping of the WoT abstract interactions: events, actions,
properties
... adapt to existingdevice ecosystems: OCF, LWM2M/IPSO,
Bluetooth, Zigbee, Echonet
... [Architecture]
... diagram here
... Thing Description includes interaction model and binding
template
... what to do and how to do, respectively
... [Protocol Adaptation]
... client of proxy uses information in the Thing Description
to adapt to protocol specifics
... payload structure
Matthias: difference between payload structure and JSON type?
Koster: payload structure could
be array, etc.
... specific way for OCF, etc.
... for example, using JSON
Matthias: maybe just an example and actually don't need?
Koster: [TD Extensions]
... inputData and outputData describe the payload
structure
... value constraints enable the client to adapt to the data
(e.g., 0-100 for brightness)
... [Example inputData Element]
... payload structure:
... fields: [
{
name: brightnesss,
value: {
type: integer,
@type: sch:levelvalue,
min: 0,
max: 255
}
}
McCool: could be array?
... and wondering about unit
Matthias: sch:unit?
McCool: based on JSON-LD
Koster: [Link Metadata
Example]
... and then link part
... href describes URI
... rel - methods for interaction
... "wot: invokeAction"
... and then "coap:methodName"
... related to "HTTP linked data vocabulary"
Matthias: maybe possible to reuse the
vocabulary?
... could work out to define coap request
McCool: need to add conditional elements
Koster: special things for OCF,
e.g., coap:fildName: 12
... and coap:fieldName: 2053
... [Payload Variation by Protocol]
... OCF Batch Interface
... and LWM2M/IPSO
... [inputData for OCF Batch]
... nested object here
... [inputData for LWM2M/IPSO]
... "@type" specifies the expected type, e.g.,
"sch:levelvalue"
... questions?
(no specific questions)
Koster: will continue to work and publish it at some point
McCool: still an Editor's draft
... define informative considerations for security
... who can attack you, etc.
... some work on the industry side
... threat model for IoT included
... privary stakeholders, supported physical roles
... assets, adversalies, attack surfaces
... framework on how to use WoT
... security objectives
... stakeholders, who does what
... a lot from usual IoT consideration
... with WoT consideration
... issue on maintaining scripting api
... also issues with OEM
... what part of the lifecycle to care about?
... so far mostly focused in the use part
... other part of the lifecycle later
... regarding the run time
WoT high-level architecture security view
McCool: wide variety of
implementations
... and then various kinds of threats here
... there are many green boxes (editors notes)
... more and more concrete things
... and then have security objectives
... home environment
... and also business/workplace environment
... critical environment
... existing security best practices: 4 references here
... Garcia17, IicSF 16, IETFACE, ISF17
... and then a number of references for privacy
... recommended security practices
... secure delivery/strage of TD
... secure transports, avod heavy functional processing without
authentication
... avoid exposing immutable identifiers
... examples of WoT security configurations
... various issues with gateway
... e.g., WoT gateway is not a trusted entity?
... WoT Servient Multi-Tenant
... what are the extra requirements?
... we need validation and testing as well
... this document still work in progress
Matthias: something similar by
IETF?
... maybe should get rid of overlapping content
McCool: making security mandatory is
a good idea but that's not possible in some cases
... subset of TD for non-secure devices?
... might be good to have discussion what is required field
Matthias: comments on web service penetration
McCool: would think about that
Darko's slides on ">TD extended with iotschema.org"
Darko: experience from
yesterday
... discovery problem, iotschema and what's next
... that's about recipe
... [Motivation: Thing Discovery
... we have a guy here
... needs to find an air conditioner
... how to do that?
... exact name of the thing?
... possibly
... query based on string
... request MyAirConditionerP1
... nad get TD
... but wouldn't it be nicer to use more abstract
concept?
... e.g., just using "AirConditioner"
... [iotschema.org]
... you can go online and browser the device (capability)
... can just take the url like:
iotschema.org/AirConditioner
... what to explore and get TD immediately
... not only discovering things using that abstract name
... but also target also can be defined
... interaction patterns of AirConditioner Capability
... IoT interoperability
... [Overview IoT Schema]
... [Narrow Waist in System Design]
... many apps - WoT (semantic interoperability) - IoT (IP
networks, LAN/WAN) - many devices from different ecosystems
(Fairhair, OCF, dotdot, Z-Wave)
... [What needs to be built]
... app level semantic interoperability
... well-known formats to describe common affordances of
connected things
Dave: what about the location?
Darko: still need dome
ontology
... not mentioning the details here
... [Layers in the Semantic Stack]
... common protocols a the bottom
... diverse devices from device ecosystems (OCF, Zigbee,
Z-Wave, Fairhair)
... Web of THings semantic narrow waist
... iotschema.org, ontologies
... W3C TD, hypermedia controls
... [Capability Abstraction]
... proposal is doing this
... notion of capabilities
... connected things expose simple "traits"
... [Exapmles of Capabilities]
... Thing/Capabilities/Properties/Type/Actions
... Motion Sensor/Motion Sensing/Motion/Boolean/(read)
... is there an appropriate way?
... data point by the device
... high-level abstraction of the characteristics of the
thing
... possibly 2 similar things from 2 different
manufacturers
... [Different Layers of iotschema.org]
... quite high-level abstaction
... Data Types -> Interaction Patterns ->
Capabilities
... [Available Resources for iotschema]
... resources here
... current schema location: http://iotschema.org
... working document and notes on google doc
... [TD RECIPES]
... what else could be done?
... even if we can query the AirConditioner...
... still some problem
... for users to be familiar with SPARQL and semantic
models
... [Recipe]
... application templates
... to easily create WoT apps
... interaction patterns (events, properties, actions)
... and interactions (event A - action B)
... corresnpond to discovery and script generation,
respectively
... [Recipe Example]
... motion detector light switch
... turn a light on when motion is detected in a room
... ingredients: MotionStatus Property, TurnOn Action, TurnOff
Action
... interactions: SUBSCRIBE Motion Status, UPDATE TurnOn (or
UPDATE TurnOff)
... graphical representation here
... TD interaction patterns and iotschema.org capability for
ingredients
... implemented with W3C WoT scripting api for
interacitons
... discovery and binding will be automtated
... [Example Recipe]
... JSON example
... @type: http://iotschema.org/MotionDetected
(as interaction pattern)
... [Tool: Recipe WOrkbench]
... there is a tool for that purpose
... would demonstrate on Wednesday
... can save the template and distribute it
Dave: an example with sensor and light in a same room
Darko: explained very simple
example
... you can add constraints to the recipe
... all the information will be taken into account
... the use is still included
<dsr> users could be asked to browse candidates and select between them based upon the contexr
Qing_An: 100 of iot related
companies
... ICA defines a data profile for various devices
... air conditioner, cleaning robot, etc.
... examples of air conditioner
... switch, wind speed, etc.
... [ICA Standardization - Connectivity]
... semantic vocabulary work
... would like collaboration with W3C
Matthias: semantic model based on
iotschema.org
... thinking about how to reuse that
... we should clarify how to align this work
McCool: how to line up things
... decompose the device's capability and get appropriate
granularity
Matthias: W3C WoT provides recommendations for essential points
Qing_An: main issue is which one is dominant
kathy: resource on that organization?
Matthias: you can send the slide and
the resource of the organization
... we can add link to the agenda
... wraps up
... some more discussion possibly during the dev meetup
later
... tomorrow we'll start with TD discussion
[end of Nov. 6]
<victor> (your voice sound very distant, it's hard to understand)
<victor> your voices*
<inserted> am1=Koster, am2=Taki, pm1=Dave, pm2=Kaz
<victor> https://github.com/w3c/wot-thing-description/tree/master/ontology/td-types
<kaz> scribenick: mjkoster
<dape> https://github.com/w3c/wot-thing-description/tree/master/ontology/td-types
<victor> http://json-schema.org/
victor: presenting concepts and examples from the json-schema ontology
victor: changes in the
syntax
... use @type
Matthias: does @type replace "type"?
victor: syntax of type and @type is too close
Matthias: expecting @type to be an array that can contain data type and semantic type
McCool: concern about combining
data type and semantic type that with complex data types may
get confused with semantic type
... do we really need "@type" if we remove "type"
victor: we could separate the 2 type definitions
McCool: like the separate semantic type
Koster: +1
Matthias: there might not be much
difference if there are RDF triples behind it
... the semantic annotation could be used for both, as it
follows the same pattern
McCool: mixing keywords with semantic tags
Matthias: this is now full RDF modeling, so number type should be RDF also
McCool: the @type could be ignored by a format processor
Matthias: they process the annotations separately, so it may be useful to keep them separate
Sebastian: does it make a difference for RDF processing?
victor: probably no big
deal
... one negative point is it could be difficult to use a
separate definition file (?)
... decided to use singular form for identifiers
dape: inconsistency noted with capitalization
<victor> https://github.com/w3c/wot-thing-description/issues/12#issuecomment-317489194
<Zakim> dape, you wanted to ask whether there is any reason why in the example we have "@type": "Object" compared to "@type": "object" (see diff in capital letter)
<McCool> McCool: my comment was wrt a previous point: "items" is also plural. PERSONALLY, I think that if an element *must* take an array as a value, then it should be plural. If it is sometime a scalar and sometimes an array, it should be singular. My two cents... I think we should reopen this discussion, being completely consistent about using singular everywhere gets into some weird things (like "item")
victor: example of converting simple json to json-ld using an implicit context
<kaz> issue 12
Sebastian: is min/max sufficient to describe integer bounds?
McCool: precision? suggested minimum step annotation
<McCool> McCool: would be good to add a "step" parameter to give the desired precision of numbers
Koster: integer step would be one, for example
Matthias: what is the use case for describing this? does the client use it?
dape: json schema also has the ability to define step size of a number
<dape> see "multipleOf"
Sebastian: observable flag
... stability flag
<victor> I'll have to leave. I had a small comment on extending the JSON Schema: serialization details can be solved by semantic tagging (e.g. {"type": "object", "cbor:format": "cbor:UINT8"})
<victor> and the TD model could include a small set of terms for formats like XML and CBOR
<victor> and EXI
Sebastian: stability sets client
expectation for how often value may change
... does having observable flag re-introduce or change the need
for a stability flag
McCool: can of worms because of
the range of "qos" style parameters
... maybe this could be an additional vocab
Matthias: this is not tied to
observable in any way
... this is communications metadata
<kaz> issue 29
Matthias: maybe should make a call for other use cases of extended metadata over time
<taki> +q
Matthias: we need to keep the spec simple and the core small
taki: do we have a mutable flag? would indicate no need to observe
Sebastian: stability=0 == not mutable
taki: this is important to indicate mutability
Matthias: truly static information should go into metadata
McCool: some metadata shows up as a property which is immutable on a device
McCool: e.g. gateway
servient with many local servients
... how to handle multiple servers providing similar data
... could there be name conflicts?
... should there be grouping?
... McCool: maybe prefer sets vs. hierarchies
Dave: idea of hierarchically organized properties and composite TDs
Koster: linking and collections
Sebastian: agenda bashing? (none)
<inserted> Kaz: do you want to file an issue for this point?
<inserted> Sebastian: will check the repo and file an issue if there is no related issue yet
Matthias: issue #78
Scripting API improvements
<dape> https://github.com/w3c/wot-scripting-api/issues/78
Matthias: zkis has collected use
cases of developers
... at the plugfest there were some questions and issues
... current proposal looks stable (showing discover, exxpose,
consume)
... make an exposed thing by consuming a TD and generating the
interactions
... some people rely on the ability to dynamically add and
remove interactions
Zoltan: there is a developer
scenario for making an instance of an interaction (object)
using a TD
... second use case is similar to the Mozilla simplified
... third is use of TD fragments instead of the addInteraction
pattern
... can we use TD fragmants or something simpler to provide
dymanic TD capability
Matthias: the feeling seems to be
that there is some need for add/delete interaction
... what are other opinions on what is needed?
... what about using TD augmented with the code part?
<taki> +q
Koster: low level construction used add/remove but can be driven from TD or TD fragments
Nimura: they have a thing builder that handles the incremental style construction
Matthias: we need to narrow down the implementation choices if possible
Zoltan: all 3 use cases may be valid for different things; which ones are more usable?
Nimura: builds both TD and
exposed thing from a reusable script
... thing builder script
Matthias: is the thing builder
integrated with the runtime?
... how does it generate dynamic TDs?
Nimura: chart showing exposed
thing and consumed thing as instances with event flow from
exposed to consumed thing
... client observes the consumed thing
Matthias: we want to get an
observable object for either event or property
... combiming subscribe and observe is a confusing
statement
s/combimimg/combining
Matthias: need to collect more
comments and create a draft for observables that simplifies
things for developers
... also agree on something stable for the next plugfest
Zoltan: should there be both
observables for properties and events?
... should there also be observables from Actions?
<taki> -q
Dave: where does the model for
changing properties and interactions come from?
... some programming environments may not be able to deal with
dynamic TDs (?)
<inserted> Kaz: one quick comment. in order to make the diagram easier to understand it would be better to add a larger box to each servient to show the blue boxes are part of one servient (on the expose side) and the green boxes are included in another servient (on the consume side)
Zoltan: there is only one observe
method for properties and events
... should there be different methods for events vs.
properties
McCool: need to track long
running actions using observations
... it makes sense to have a way to do this by default
Matthias: can't necessarily prescribe notifications for all devices
uday: need to observe the results of actions
Matthias: some things do not have the ability to allow monitoring of actions
McCool: don't use actions on OCF
devices at all
... actions should only be long running, and should always
create something
Dave: there should be semantic
tagging for actions
... what is the use case for observing actions from one
servient to another?
Matthias: we cant require all actions be observable
Zoltan: observability can be indicated or not
uday: applications do need to monitor actions
Matthias: only the invoker of the
action can monitor the action
... may be useful to combine the function for different
interaction classes
Matthias: want to make sure we clear up the confusion between observing and subscribing
dape: maybe we can just use observe of properties acted on by the action
<dsr> One point I meant to state is that in JavaScript properties and methods are in the same namespace, but events are not. This means that it makes sense to use a distinct API for observing properties and events
McCool: use an status property of an action to observe
Dave: may need to have different APIs for interaction classes due to name conflicts
Matthias: 20 min behind, need to take break
10: 50
reconvene
<elena> ok, I will be there at 10:50
<kaz> [morning break]
<elena> I will start sharing in meanwhile while we wait
<taki> scribe: TK
<taki> scribeNick: taki
Elena: section 5.
... examples of configurations.
... need to collect more cases.
... section 5.1 basic
... lacking details. not important from security point of
view
... client connects to wot thing.
ER Describing symmetric key credential.. Raw assymetric key credentials...
McCool: life cycle assumption. we
need to describe.
... seventeen papers we can refer to.
... Phases.
... OCF model in particular. We need to expand and
generalize.
... Need to investigate other standards.
... OneM2M etc.
... any other examples?
... Amazon. Reasonably good. Also OneM2M as starting pont.
Elena: i tried not to make assumption wrt. lifecycle.
ER explaining several patterns of life cycles.
<kaz> security draft
McCool: external network access. 3rd
party authentication, etc. We need to document those
assumptions.
... You need network connection during provision.
RB: Owner should authorize access. not devices.
Elena: Client need token to access functions at server.
McCool: We assume it is in operation
phase.
... De-install, de-provision is part of life cycle.
... Let's keep the scope narrow.
RB: Pairing is also part of it.
Matthias: We aligned with DITF.
... New standards coming up. authorization, de-couple, trust,
negotiatiation. Get token, present token. Then you get
access.
McCool: Will it work when network is
down? On-boarding needs external access.
... This is constant problem.
... There are specific approaches to avoid this.
... Expiration makes devices failing.
... First category is industry provisioning. Second is
home.
??: Have you guys taken a look at blockchain?
McCool: We plan to take a look in
February. We discussed in IETF, too.
... It is an option.
... We need to constantly update security document.
??: Blockchain is an idea.
McCool: We should at least
mention.
... Thing directory at this point does not support https.
... We should consider this aspect in PlugFest.
... Authorize to search, as well.
Elena: One more case. I want to
show.
... Things are behind proxy.
... why we call it "forwarding"?
Matthias: We are using forward proxy. Fujitsu is using reverse proxy solution.
McCool: We can use a wrapper
solution.
... we can manage separately.
... Different patterns of communication between proxy and
things. We need to document this.
... We have at least three different approaches.
... We need to look at this from security point of view.
Matthias: What information do we need?
McCool: We first need to document
what happened in PlugFest.
... And see how amazon do this.
Matthias: I am going to share document that is the basis of PlugFest in IRC.
<mkovatsc> https://github.com/w3c/wot/blob/master/plugfest/2017-burlingame/preparation.md
Elena: now on more complicated cases.
<npd> is the goal of the document primarily to catalog the security approaches that are being used by industry? Or are we trying to analyze those security models and provide recommendations?
McCool: This is more active
proxy.
... First case was transpararent proxy.
ER descriing figure 4...
McCool: Public service talking vending machine. Can we trust end-device, not gateway?
Elena: Why you need gateway? What's the role of gateway?
Matthias: You cannot distinguish. You
have to trust that.
... If we cannot trust proxy, we need to go down lower
layer.
... Protect payload and header.
... Bachnet and modbus, it has to go through a module on
laptop. You have to trust our gateway.
McCool: We need to think about use case where we cannot trust.
Matthias: Payload may be signed.
Elena: Let us know.
<mkovatsc> Matthias: Signed payload ("Object Security") can pass also proxy Things
ER describing Figure 5...
McCool: Local link vs global link. we
saw this in PlugFest.
... Can we trust thing directory?
Matthias: Who can sign thing description has impact.
<npd> it's not clear whether Thing Description is specific to an individual thing or just to the generic model of Thing
<npd> is the Thing Directory a public set of Descriptions of models of things? Or a user-specific repository of Descriptions that include personal information?
McCool: Modify meta-data, this is a concern.
ER discussing section 5.3...
ER describing Figure 6...
ER describing WoT runtime enforced isolation...
Matthias: Meta-data is passed
separately to script.
... security provider knows which software objects need which
data, in our implementation.
... We need to reprovision.
... when we iinstantiate we have both. Sandbox has secure
store. Runtimes knows this.
... TLS, OAuth, depending on which one, provision is
different.
Zoltan: OCF does OCF provisioning.
Matthias: Protocol binding also contain
security.
... Different providers, different account systems.
... Security store, how matching is done.
Zoltan: script can ask access to
things.
... Currently we don't have information. It is out of scope. We
don't deal with this mechanism.
... Special thing to manage script, permisision, different
protocol bindings. Do we need tihis kind of permission ?
Matthias: What ER is talking about is
out of scope for the first phase.
... Enforcement is second phase.
... It is not available out there. We can do after a few
months.
ER describing multi-tenant... Figure 7.
Elena: This is more complex.
Zoltan: It has to different
identity.
... Otherwise cannot distinguish.
Elena: WoT script provisioning, Wot security ... editor's notes. We need to discuss....
Zoltan: Do we have actual information as to how provision works in OneM2M and OCF?
McCool: OCF, e.g. manufacturer
provisions.
... We should focus on the phase after provision is done.
... We have 5 patterns, we should experiment in PlugFest.
... and extract requirements.
Zoltan: idenrify security meta-data.
McCool: We need to decide roadmap
wrt. security implementation for the next couple of
PlugFests.
... Everybody please take a look at security document.
... In Github under Wot security.
Matthias: With Alibaba, Oracle, we need to discuss.
McCool: I need PDF for posters now.
Matthias: Binding Templates after lunch. (Michael Koster's turn...)
<barryleiba> Hm, I guess that incantation doesn't work.
<barryleiba> :-)
<kaz> [lunch]
<kaz> scribenick: kaz
Koster: [Protocol Binding Templates Abstract]
... [Architecture]
... application-facing part and device-facing part
... interaction modl descibes what to do
... binding template describes how to do
... [Example inputData Element]
... adapting payload part
... two fields here
... brightness ad ramptime
... semantic type here and here
... integer for brightness and ramptime
... gives same functionality
... payload structure and value constraints
... [Payload Structure]
... brightness: 127
... [Payload Variation by Protocol]
... OCF Batch Interface and LWM2M/IPSO Interface
... inputData for OCF Batch
... constant value
... assumption of constant type specified by schema
... inputData for LWM2M/IPSO
... looks like we can do that
... [Link Metadata Example]
... link part
... what we do in the target
... what we're doing
... using transport specific language
... RDF vocabulary for HTTP
... can be made for CoAP, etc., as well
... essage layer like this
... message pattern here
... coap:messageHeader
... most of the Web-based protocols work lie this
... create instruction for particular protocol
... href starts with schema like this
... [Issues]
... broader issues
... we haven't addressed yet
... what is the use case?
... * observe and notification
... not just protocol binding issue but general issue
... is observe approriate for actions and events?
... other forms of notification, e.g., longpoll, web push
... * event pattern with created object
... created object to obtain events from, returns TD
... not sure if the behavior of created object is consistent
... obtain events from created object
... * action patter with created object
... some way to monitor
... created object returns TD
... response within expected time span?
... obtain action status from created object
... * security binding, per protocol binding, per link
... short list of issues
... maybe some more
McCool: do all the interactions have same security requirements?
... multiple requirements for TD?
... even so, different resources for same security requirements
Sebastian: protocol binding vocabulary?
... already some prefix there
... do we need to do this for all the possible protocols?
... need to include coap context
... so maybe need some context file?
Koster: we could require that explicitly
... all the context should go with TD
Sebastian: who is going to find the protocol?
Koster: there is a WD for CoAP
... one for CoAP and another for MQTT
... could be iotschema
... we have to do same things
... transfer layer
Matthias: should it be a separate vocabulary?
... kind of reopening the issue
... people should make the decision not we
... you chose good prefix examples here
... is there automatic mechanism?
... for binding?
Kaz: wondering if it's possible not specify concrete protocol here
... but use some kind of variable "@protocol" or "$protocol" or something like that instead
Matthias: here we have mediatype but could have some variable instead
Koster: good point
... next
... [Observe binding example - CoAP]
... href describes coap://0m2m.net:1883/plugfest/subscriptions/Motion
... first link is for getProperty. second link is for observable
McCool: posted an issue
... may have to have a field for observable
Matthias: we should have a specific link
... specific operation we want to do
... two already for read/write
... and third one for observe
... could be something like form
... would see at T2T meeting as well
... link to the related thing
Koster: good
... another example
... [Observe binding example - MQTT]
... MQTT subscribe
... send an address
Matthias: recently there was an email on pub/sub spec
... basically this pattern here
Koster: may be different authentication mechanism
... don't know how this could work for websocket...
... keep thinking
Matthias: question on eventing
... Panasonic's websocket approach
... post somewhere and get something
... send handle and get event notification
kawa: rather to share same websocket with different entities
Dave: that's exactly what implemented by my implementation as well
Matthias: you might have race condition
... would have offline discussion
Koster: agree
... not now but some more discussion on how to handle websocket connection
... next
... [Plugfest feedback]
... * early integration of protocol binding in TDs
... * manual processing to use the binding information
... able to use protocol binding to construct payload
... issues with namespaces
McCool: created 4-5 issues
... issues on properties
<McCool> https://github.com/w3c/wot-thing-description/issues/66
<McCool> https://github.com/w3c/wot-thing-description/issues/65
<McCool> https://github.com/w3c/wot-thing-description/issues/64
<McCool> Issues above have feedback on issues discovered with PB during plugfest
Matthias: in BACnet, you have objects
... indexed priority array
<dsr> To clarify, my implementation supports synchronisation for multiple things between servients regards of which servient acts as the client or host for the connection. I broadcast events without requiring a subscribe message. This avoids the need to track how many apps on a given servient are interested in any given event, and also the complication when a servient acts as both a client and a server for a given thing.
Matthias: maybe we need some additional interaction pattern
Koster: right
... maybe an interesting pattern
Matthias: something like web form
Koster: maybe good place to start
matsu: some example for transport like MQTT, CoAP
... we need examples of device-level protocols as well
... ECHONET, Lemonbeat, etc.
... device servients connected with devices
... information from the PlugFest participants
... functionality from the device-level protocols
Koster: part of what to do next
... [Way Forward]
... unified binding patterns to diverse protocols
... echonet, bacnet, zigbee/dotdot
Matthias: challenging cases for the next PlugFest
... protocol stack
... maybe a bit tricky
Koster: CoAP, Zigbee, etc.
... using right header information
... I added that here
Dave: what about the organization guys think about?
... e.g., Zigbee guys?
Koster: they're interested in what other organizations are working on
... how does that work?
... maybe some liaison needed
Dave: would like some quotable statements :)
Koster: some more
... FPWD document schedule
Matthias: at least by the next plugfest
... we need to publish updated drafts as well
br: we should be comfortable with what we have
Koster: any showstopper?
Matthias: let's do it!
Kaz: note that binding template is a WG Note :)
matsu: shouldn't the inter-servient interface definition be normative?
Sebastian: guideline on how to use this?
... one part on UI
Matthias: UI template like link element
... we have issue on contradictory information
... pumped up to a normative document
... e.g., Michael Koster's examples on possible protocols
Kaz: some of the examples, etc., could be imported into the normative documents, e.g., TD
matsu: ok
... during the plugfest, we connected with each other
... this information could be included in a normative document
Koster: what we want to do should be writing up this
... for interoperability
Kaz: agree
... we should document it first
... and then think about where to go
... informative or normative
Matthias: next
... open issue on abstract data model
... need to use mediatype handler?
Koster: json schema is flexible
... would hope there is enough capability there
... transformation language
... that might be a useful approach
... bacnet, echonet, zigbee, ...
Matthias: looking for the breaking point
... broadcast IP address
... and specific object
... that way we use URL
... we have to look into it
... binding to node.js
Koster: protocol binding to bridge
... just a router sometimes
... for backnet you have json
Matthias: internally
Koster: for modbus binary
Matthias: data types should be interpreted appropriately
Koster: right
... for the next plugfest, we should try it
... somebody implements binding for that
Matthias: current practice document for next addition as well
... need to add implementations for binding
... many implementations are not capable for that
Koster: maybe configure node-wot proxy
Matthias: one of the ideal goals
... we've already have servients from each side
... break and AC meeting in parallel after break
[break until 15:15]
As this face to face is in North America, we are looking at holding the next face to face in Asia
Michael: the security conference is in San Diego on 18-21 Feb.
Other opportunities for co-locating the F2F is the IETF in London in March, the OCF IoT Build event in March and oneM2M in May.
<kaz> https://openconnectivity.org/events
OCF is hosting a number of events in America, Europe and Asia
<McCool> Technology Face-to-Face January 15 - 18 Las Vegas, Nevada Plugfest #16 February 5 - 9 UL - Fremont, California Spring 2018 Members Meeting March 19 - 23 Sheraton Prague Charles Square - Prague, Czech Republic Plugfest #17 April 16 - 20 DEKRA - Malaga, Spain Technology Face-to-Face May 8 - 11 APAC: Ho Chi Minh, Sydney, or Japan - Location subject to change
Michael: January is a little
early for the next WoT F2F. April is better. The March OCF
event conflicts with the IETF.
... we could consider hosting a plugfest before or after the
London IETF
Kajimoto-san: we should avoid conflicts with oneM2M meetings
<mkovatsc> Note that we have an open inquiry to get a venue in Korea in March 2018
<mkovatsc> And we are aware of the IETF/OCF week
Kajimoto-san: given that we want to focus the next plugfest on protocol binding we should appoint Michael Koster for arranging the plugfest
oneM2M meets 12 March in USA
Barry: do we want to attract people from the OCF to our event?
Suggests that this would be more likely if we meet in Prague
We chat about meeting in Prague on 24-25 March immediately following the OCF meeting there
For the Summer 2018 F2F …
TPAC 2018 is 22-26 October in Lyon, France
<McCool> other OCF events in the fall (these are not very firm): Summer 2018 Members Meeting June 18 - 22 North America: Chicago or Philadelphia - Location subject to change. Plugfest #18 July 24 - 27 TTA - Seoul, South Korea Technology Face-to-Face Aug 7 - 10 DEKRA - Malaga, Spain Plugfest #19 September 17 - 21 ALLION - Taipei, Taiwan Fall 2018 Members Meeting November 12 - 16 APAC: China, Japan, or South Korea - Location subject to change Plugfest #20 December 3 - 7
For March, other possibilities include Seoul and Tokyo.
But Prague seems prefereable for the co-location with OCF
Kajimoto-san asks Michael Koster for when the protocol binding WG Note can be published
MichaelK: another month …
MichaelM: we probably want a spec and a how to
Sebastian: beginning of next year is realistic
Kajimoto-san: want about the security & privacy doc?
MichaelM: we won’t have a complete document until the end of January
I want to publish the initial Note soon and then push out updates, as that is a mechanical process according to Kaz
For scripting we need to check with Zoltan on his publication plan
The plugfest guideline should be ready at the end of January
By the March face to face, we should finish the external security review and issue updates for the public Working Drafts.
We should plan for release candidates for the CRs in October, and publish the CRs in December prior to the end of the WG charter
We will start the external review in TPAC 2017 in the break-out session in the plenary day
<kaz> session grid
We turn to testing. Michael notes that node-wot performs no error checking and as such isn’t worth testing for security
We can however work on how to test
Kaz: so we may need a testing task force, right?
Michael: yes
<kaz> (some more discussions on the publication schedule and testing)
Michael Koster talks about the challenges for using protocol bindings for binary payloads
we already know how to support CBOR
Dave: what about Apache Avro, see:http://avro.apache.org/docs/current/spec.html#schema_complex
Avro is popular for cloud based data
Kajimoto-san summarises the plans for the plenary day (tomorrow)
We should consider Asia in June, either Seoul or China
we prefer Seoul …
[Summary of the discussion on the f2f/publication planning]
See the WoT IG and WG Administration slides for the details.
<kaz> [WoT f2f meeting adjourned]
Kajimoto-san's slides for PlugFest demo
Kajimoto explains the orchestrated version of the PlugFest using his slides
Also all the participants explain their implemented components using the posters at their booths
<kaz> [session adjourned]