<kaz> scribenick: mjkoster
<kaz> Soumya's message on semantic interoperability workshop
mccool: there is a Semantic Interoperability workshop at the Global IoT summit conference
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
<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 :)