10 Jan 2018



Kaz_Ashimura, Michael_McCool, Taki_Kamiya, Daniel_Peintner, Graeme_Coleman, Toru_Kawaguchi, Darko_Anicic, Kunihiko_Toumura, Michael_Lagally, Sebastian_Kaebisch, Tomoaki_Mizushima, Michael_Koster, Ben_Francis
Yongjing, Kajimoto, Matthias
mjkoster, kaz


<kaz> scribenick: mjkoster

Quick updates

<kaz> Soumya's message on semantic interoperability workshop

mccool: there is a Semantic Interoperability workshop at the Global IoT summit conference

Next f2f

mccool: F2F planning, joint meeting with OCF on Friday of the OCF/IETF week before our F2F

<kaz> F2F wiki

mccool: IETF Hackathon in London the weekend before IETF (March 17-18)
... please start filling in the planning documents for the plugfest
... we still need to get a local host in Prague

TF reports

<kaz> Pull Request 363

mccool: TD report out
... simple JSON serialization discussion in progress since November

Sebastian: there was a new version proposed at the end of the year to address some of the Mozilla issues
... goal is to arrive at a common serialization
... we will invite Mozilla to participate in an upcoming meeting to review

mccool: we will keep this item on the agenda until next week

<kaz> JSON vs JSON-LD

<benfrancis> Open question: Whether to have separate JSON & JSON-LD serialisations or one single serialisation which can be parsed as either JSON or JSON-LD

Sebastian: this document is our counter proposal to address the Mozilla issues
... there is an advantage in having one serialization to simplify the overall deliverable

benfrancis: the JSON-LD compatible serialization is going to be more complex from the JSON perspective, especially using JSON-LD 1.0
... ongoing discussion in the github issue, also a question of how many http links should be in the thing description

sebastian: can benfrancis join one of the next TD meetings?

benfrancis: has a time conflict, difficult to schedule in

sebastian: maybe we can schedule a discussion for the main IG/WG meeting, follow up via email

<inserted> scribenick: kaz

kaz: let's have further discussion about this offline

<inserted> scribenick: mjkoster

mccool: scripting API report?

dape: had a discussion and considering freezing the spec for the plugfest
... discussing the issue of a dynamic TD and how elements can be created and deleted

<kaz> issue 82

dape: a related issue of new things appearing that need to be exposed

mccool: where do we address the issues of overall architecture like this, which cut across groups?

mjkoster: also plugfest planning questions like how thing directories work?
... maybe a discovery topic could be taken up

<inserted> scribenick: kaz

kaz: could be part of Matsukura-san's plugfest guideline and could be included in the main architecture document, but we need more discussion

mjkoster: we didn't have meeting yet
... the status is
... pull request for another update
... worked on before the new year break
... created items
... template part of TD
... next binding meeting, would like to walk through the document
... to get the publication candidate

mccool: publication schedule?
... each TF needs to review their schedule
... (adds "Schedule" to the topics for next week)

<scribe> scribenick: mjkoster

mjkoster: for binding templates, complete the review and get a first document published

mccool: security TF report
... looking at the operational mode of the device so far, starting to look at the life cycle including onboarding, commissioning, etc.
... referring to an IETF document that describes terminology (Garcia?)
... working on defining what security we want to deploy (and require) at the plugfest
... this needs to be driven from use cases
... we should use the use cases that we are already developing for the plugfest planning
... make a list of technologies (oauth...) and work back to use case scenarios that will test them
... published the first security note before the end of last year

<kaz> security note


mccool: topic: any more items to add to the agenda for the next web conference?
... Should we discuss any technical issues in the remaining time?

benfrancis: discuss JSON processing to JSON-LD
... JSON-LD 1.1 would make the processing easier and more natural representation in JSON

sebastian: have been in discussion with Greg Kellogg, the JSON-LD chair
... upcoming feature of key names mapping to property names

<kaz> JSON LD CG

kaz: we could see if there can be a W3C recommendation in the JSON-LD 1.1 roadmap
... theoretically we could make JSON-LD a W3C REC (by creating a new WG or brining it to some existing WG) if needed

benfrancis: worthwhile to follow up on this because it can help simplify the JSON
... otherwise we could use an algorithm to convert JSON using a default context

mccool: we could use JSON 1.1 as the base for the algorithm-driven approach but not refer to a specification

dape: can we at least mention the 1.1 document if we do this approach?

kaz: there may be a way to make an informative reference to a W3C community group report
... but probably not appropriate as a normative reference
... if we need a normative reference, we should drive to a W3C recommendation on JSON-LD
... I'd ask the JSON-LD CG guys about their plan as well

mccool: adjourn

<benfrancis> Happy New Year :)

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/10 16:38:54 $