<victor> (your voice sound very distant, it's hard to understand)

<victor> your voices*

scribe assignment

<inserted> am1=Koster, am2=Taki, pm1=Dave, pm2=Kaz

update on json-schema ontology

<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

<kaz> remote: Victor_Charpenay

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

mjkoster: +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

data types

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

mjkoster: 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

plugfest feedback

<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

hierarchies in TDs

UNKNOWN_SPEAKER: 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

dsr: idea of hierarchically organized properties and composite TDs

mjkoster: 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

scripting API

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

<kaz> remote+ Zoltan_Kis(Intel)

zkis: 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

mjkoster: 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

zkis: 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

zkis: should there be both observables for properties and events?
... should there also be observables from Actions?

<taki> -q

dsr: 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)

zkis: 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

dsr: 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

zkis: 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

<kaz> remote+ Elena_Reshetova(Intel)

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

dsr: 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

Security

ER: 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...

MM: 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.

ER: i tried not to make assumption wrt. lifecycle.

ER explaining several patterns of life cycles.

<kaz> security draft

MM: 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.

ER: Client need token to access functions at server.

MM: 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.

MK: We aligned with DITF.
... New standards coming up. authorization, de-couple, trust, negotiatiation. Get token, present token. Then you get access.

MM: 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?

MM: 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.

MM: 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.

ER: One more case. I want to show.
... Things are behind proxy.
... why we call it "forwarding"?

MK: We are using forward proxy. Fujitsu is using reverse proxy solution.

MM: 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.

MK: What information do we need?

MM: We first need to document what happened in PlugFest.
... And see how amazon do this.

MK: 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

ER: 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?

MM: This is more active proxy.
... First case was transpararent proxy.

ER descriing figure 4...

MM: Public service talking vending machine. Can we trust end-device, not gateway?

ER: Why you need gateway? What's the role of gateway?

MK: 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.

MM: We need to think about use case where we cannot trust.

MK: Payload may be signed.

ER: Let us know.

<mkovatsc> MK: Signed payload ("Object Security") can pass also proxy Things

ER describing Figure 5...

MM: Local link vs global link. we saw this in PlugFest.
... Can we trust thing directory?

MK: 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?

MM: Modify meta-data, this is a concern.

ER discussing section 5.3...

ER describing Figure 6...

ER describing WoT runtime enforced isolation...

MK: 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.

ZK: OCF does OCF provisioning.

MK: Protocol binding also contain security.
... Different providers, different account systems.
... Security store, how matching is done.

ZK: 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 ?

MK: 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.

ER: This is more complex.

ZK: It has to different identity.
... Otherwise cannot distinguish.

ER: WoT script provisioning, Wot security ... editor's notes. We need to discuss....

ZK: Do we have actual information as to how provision works in OneM2M and OCF?

MM: 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.

ZK: idenrify security meta-data.

MM: 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.

MK: With Alibaba, Oracle, we need to discuss.

MM: I need PDF for posters now.

MK: Binding Templates after lunch. (Michael Koster's turn...)

<barryleiba> Hm, I guess that incantation doesn't work.

<barryleiba> :-)

<kaz> [lunch]

Binding

<kaz> koster: [Protocol Binding Templates Abstract]

<kaz> ... [Architecture]

<kaz> ... application-facing part and device-facing part

<kaz> ... interaction modl descibes what to do

<kaz> ... binding template describes how to do

<kaz> ... [Example inputData Element]

<kaz> .. adapting payload part

<kaz> ... two fields here

<kaz> ... brightness ad ramptime

<kaz> ... semantic type here and here

<kaz> ... integer for brightness and ramptime

<kaz> ... gives same functionality

<kaz> ... payload structure and value constraints

<kaz> ... [Payload Structure]

<kaz> ... brightness: 127

<kaz> ... [Payload Variation by Protocol]

<kaz> ... OCF Batch Interface and LWM2M/IPSO Interface

<kaz> ... inputData for OCF Batch

<kaz> ... constant value

<kaz> ... assumption of constant type specified by schema

<kaz> ... inputData for LWM2M/IPSO

<kaz> ... looks like we can do that

<kaz> ... [Link Metadata Example]

<kaz> ... link part

<kaz> ... what we do in the target

<kaz> ... what we're doing

<kaz> ... using transport specific language

<kaz> ... RDF vocabulary for HTTP

<kaz> ... can be made for CoAP, etc., as well

<kaz> ... essage layer like this

<kaz> ... message pattern here

<kaz> ... coap:messageHeader

<kaz> ... most of the Web-based protocols work lie this

<kaz> ... create instruction for particular protocol

<kaz> ... href starts with schema like this

<kaz> ... [Issues]

<kaz> ... broader issues

<kaz> ... we haven't addressed yet

<kaz> ... what is the use case?

<kaz> ... * observe and notification

<kaz> ... not just protocol binding issue but general issue

<kaz> ... is observe approriate for actions and events?

<kaz> ... other forms of notification, e.g., longpoll, web push

<kaz> ... * event pattern with created object

<kaz> ... created object to obtain events from, returns TD

<kaz> ... not sure if the behavior of created object is consistent

<kaz> ... obtain events from created object

<kaz> ... * action patter with created object

<kaz> ... some way to monitor

<kaz> ... created object returns TD

<kaz> ... response within expected time span?

<kaz> ... obtain action status from created object

<kaz> ... * security binding, per protocol binding, per link

<kaz> ... short list of issues

<kaz> ... maybe some more

<kaz> mm: do all the interactions have same security requirements?

<kaz> ... multiple requirements for TD?

<kaz> ... even so, different resources for same security requirements

<kaz> sk: protocol binding vocabulary?

<kaz> ... already some prefix there

<kaz> ... do we need to do this for all the possible protocols?

<kaz> ... need to include coap context

<kaz> ... so maybe need some context file?

<kaz> koster: we could require that explicitly

<kaz> ... all the context should go with TD

<kaz> sk: who is going to find the protocol?

<kaz> koster: there is a WD for CoAP

<kaz> ... one for CoAP and another for MQTT

<kaz> ... could be iotschema

<kaz> ... we have to do same things

<kaz> ... transfer layer

<kaz> mk: should it be a separate vocabulary?

<kaz> ... kind of reopening the issue

<kaz> ... people should make the decision not we

<kaz> ... you chose good prefix examples here

<kaz> ... is there automatic mechanism?

<kaz> ... for binding?

<kaz> kaz: wondering if it's possible not specify concrete protocol here

<kaz> ... but use some kind of variable "@protocol" or "$protocol" or something like that instead

<kaz> mk: here we have mediatype but could have some variable instead

<kaz> koster: good point

<kaz> ... next

<kaz> ... [Observe binding example - CoAP]

<kaz> ... href describes coap://0m2m.net:1883/plugfest/subscriptions/Motion

<kaz> ... first link is for getProperty. second link is for observable

<kaz> mm: posted an issue

<kaz> ... may have to have a field for observable

<kaz> mk: we should have a specific link

<kaz> ... specific operation we want to do

<kaz> ... two already for read/write

<kaz> ... and third one for observe

<kaz> ... could be something like form

<kaz> ... would see at T2T meeting as well

<kaz> ... link to the related thing

<kaz> koster: good

<kaz> ... another example

<kaz> ... [Observe binding example - MQTT]

<kaz> ... MQTT subscribe

<kaz> ... send an address

<kaz> mk: recently there was an email on pub/sub spec

<kaz> ... basically this pattern here

<kaz> koster: may be different authentication mechanism

<kaz> ... don't know how this could work for websocket...

<kaz> ... keep thinking

<kaz> mk: question on eventing

<kaz> ... Panasonic's websocket approach

<kaz> ... post somewhere and get something

<kaz> ... send handle and get event notification

<kaz> kawa: rather to share same websocket with different entities

<kaz> dsr: that's exactly what implemented by my implementation as well

<kaz> mk: you might have race condition

<kaz> ... would have offline discussion

<kaz> koster: agree

<kaz> ... not now but some more discussion on how to handle websocket connection

<kaz> ... next

<kaz> ... [Plugfest feedback]

<kaz> ... * early integration of protocol binding in TDs

<kaz> ... * manual processing to use the binding information

<kaz> ... able to use protocol binding to construct payload

<kaz> ... issues with namespaces

<kaz> mm: created 4-5 issues

<kaz> ... issues on properties

<kaz> @@@link tbd

<kaz> mk: in BACnet, you have objects

<kaz> ... 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.

<kaz> mk: maybe we need some additional interaction pattern

<kaz> koster: right

<kaz> ... maybe an interesting pattern

<McCool> https://github.com/w3c/wot-thing-description/issues/66

<kaz> mk: something like web form

<McCool> https://github.com/w3c/wot-thing-description/issues/65

<McCool> https://github.com/w3c/wot-thing-description/issues/64

<kaz> [@@@ links to 66, etc., for "@@@link tbd"]

<McCool> Issues above have feedback on issues discovered with PB during plugfest

<kaz> koster: maybe good place to start

<kaz> matsu: some example for transport like MQTT, CoAP

<kaz> ... we need examples of device-level protocols as well

<kaz> ... ECHONET, Lemonbeat, etc.

<kaz> ... device servients connected with devices

<kaz> ... information from the PlugFest participants

<kaz> ... functionality from the device-level protocols

<kaz> koster: part of what to do next

<kaz> ... [Way Forward]

<kaz> ... unified binding patterns to diverse protocols

<kaz> ... echonet, bacnet, zigbee/dotdot

<kaz> mk: challenging cases for the next PlugFest

<kaz> ... protocol stack

<kaz> ... maybe a bit tricky

<kaz> koster: CoAP, Zigbee, etc.

<kaz> ... using right header information

<kaz> ... I added that here

<kaz> dsr: what about the organization guys think about?

<kaz> ... e.g., Zigbee guys?

<kaz> koster: they're interested in what other organizations are working on

<kaz> ... how does that work?

<kaz> ... maybe some liaison needed

<kaz> dsr: would like some quotable statements :)

<kaz> koster: some more

<kaz> ... FPWD document schedule

<kaz> mk: at least by the next plugfest

<kaz> ... we need to publish updated drafts as well

<kaz> br: we should be comfortable with what we have

<kaz> koster: any showstopper?

<kaz> mk: let's do it!

<kaz> kaz: note that binding template is a WG Note :)

<kaz> matsu: shouldn't the inter-servient interface definition be normative?

<kaz> sk: guideline on how to use this?

<kaz> ... one part on UI

<kaz> mk: UI template like link element

<kaz> ... we have issue on contradictory information

<kaz> ... pumped up to a normative document

<kaz> ... e.g., Michael Koster's examples on possible protocols

<kaz> kaz: some of the examples, etc., could be imported into the normative documents, e.g., TD

<kaz> matsu: ok

<kaz> ... during the plugfest, we connected with each other

<kaz> ... this information could be included in a normative document

<kaz> koster: what we want to do should be writing up this

<kaz> ... for interoperability

<kaz> kaz: agree

<kaz> ... we should document it first

<kaz> ... and then think about where to go

<kaz> ... informative or normative

<kaz> mk: next

<kaz> ... open issue on abstract data model

<kaz> ... need to use mediatype handler?

<kaz> koster: json schema is flexible

<kaz> ... would hope there is enough capability there

<kaz> ... transformation language

<kaz> ... that might be a useful approach

<kaz> ... bacnet, echonet, zigbee, ...

<kaz> mk: looking for the breaking point

<kaz> ... broadcast IP address

<kaz> ... and specific object

<kaz> ... that way we use URL

<kaz> ... we have to look into it

<kaz> ... binding to node.js

<kaz> koster: protocol binding to bridge

<kaz> ... just a router sometimes

<kaz> ... for backnet you have json

<kaz> mk: internally

<kaz> koster: for modbus binary

<kaz> mk: data types should be interpreted appropriately

<kaz> koster: right

<kaz> ... for the next plugfest, we should try it

<kaz> ... somebody implements binding for that

<kaz> mk: current practice document for next addition as well

<kaz> ... need to add implementations for binding

<kaz> ... many implementations are not capable for that

<kaz> koster: maybe configure node-wot proxy

<kaz> mk: one of the ideal goals

<kaz> ... we've already have servients from each side

<kaz> mk: break and AC meeting in parallel after break

<kaz> [break until 15:15]

<dsr> scribenick: dsr

Administration

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

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)

<kaz> @@@link tbd

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 …

<kaz> session grid

<kaz> [meeting adjourned]

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: i/update on json-schema/topic: scribe assignment
Succeeded: i/update on json-schema/am1=Koster, am2=Taki, pm1=Dave, pm2=Kaz
Succeeded: s/nbd/no big deal/
Succeeded: s/for for/form for/
Succeeded: i/scripting/kaz: do you want to file an issue for this point?
Succeeded: i/scripting/sebastian: will check the repo and file an issue if there is no related issue yet
FAILED: s/combimimg/combining/
Succeeded: i/there is only/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)
Succeeded: s/??:/RB:/
Succeeded: s/??:/RB:/
Succeeded: s/MM/ER/
Succeeded: s/.. obtain/... obtain/
Succeeded: s/discribes/describes/
Succeeded: s/second/first link is for getProperty. second/
Succeeded: s/maybe/may be/
Succeeded: s/ned/need/
Succeeded: s/shouldn't it/shouldn't the inter-servient interface definition/
Succeeded: s/ o/ point/
Succeeded: s/now/know/
Present: DarkoAnicic hiroki_asakimori Michael_McCool Kaz_Ashimura(W3C) Dave_Raggett(W3C) Michael_McCool(Intel) Michael_Koster(SmartThings) Qing_An(Alibaba) Kazuaki_Nimura(Fujitsu) Tetsuhiko_Hirata(Hitachi) Kunihiko_Toumura(Hitachi) Tomoaki_Mizushima(IRI) Kazuo_Kajimoto(Panasonic) Matthias_Kovatsch(Siemens) Sebastian_Kaebisch(Siemens) Takeshi_Yamada(Panasonic) Keichi_Tokuyama(Panasonic) Toru_Kawaguchi(Panasonic) Masato_Ohura(Panasonic) Uday_Davuluru(Innogy_SE) Andrei_Ciortea(Siemens) Kimberly_Garcia(Siemens) Colin_Whorlow(NCSC) Qitao_Gan(Telenor) Braud_Arnaud(Orange) Youngsun_Ryu(Samsung) Barry_Leiba(Huawei) Yoshiaki_Ohsumi(Panasonic) Soichiro_Isobe(Access) Bingxuan_Wang(China_Mobile) Linda_van_den_Brink(Geonovum) Takeshi_Sano(Fujitsu) Daniel_Peintner(Siemens) Takuki_Kamiya(Fujitsu) Nickolas_Kavantzas(Oracle) Darko_Anicic(Siemens) Ryuichi_Matsukura(Fujitsu) Hiroki_Asakimori(Ricoh) Xia_Yefeng(China_Mobile) Vagner_Diniz(NIC.br) Sam_Goto(Google) Barbara_Hochgesang(Intel) Byounghyun_Yoo(KIST) Yoshiro_Yoneya(JPRS) Sumie_Miki(Keio_Univ) Nick_Doty(UC_Berkeley) Richard_Bair(Oracle) John_Hazen(Microsoft)
WARNING: No scribe lines found matching ScribeNick pattern: <TK> ...
Found ScribeNick: mjkoster
Found Scribe: TK
Found ScribeNick: taki
Found ScribeNick: dsr
ScribeNicks: mjkoster, taki, dsr

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)