<kaz> scribe: McCool

koster: to present...
... goals and objectives for plugfest in prague

<kaz> Michael Koster's slides

mccool: need to add security to goals

koster: ok
... semantic integration
... may be other interactions beyond the ones we have considered
... but want to look at three levels
... capabilities, interactions, data items
... easier to say what a thing does rather than what it is
... and make them fairly "granular"
... want characterized interactions within a capability
... integration with iotschema.org

mccool: in summary going to look at iotschema.org proposal?

koster: mostly, but easy to create new ones as well as we try to do interop
... this is something the wishi group will look at
... (shows a TD example)

matthias: unit metadata
... should be part of @type in outputData

koster: yeah, units are not specified in the base schema, so we need to add that as data semantic annotations
... protocol bindings
... one function is to adapt to these devices
... january target
... thing that still needs to be cleaned up is events/actions/observables confusion
... we also need to look at handling websockets pattern for events/observables
... other ways of doing events will probably have to wait until later
... but websockets are a high priority
... proxies
... couple of things we use them for
... reachibility
... eg nat traversal
... second, protocol adaptation
... eg OCF to HTTP/REST
... latter could be WoT defaults/common practice
... for traversal, have local/remote proxies
... and typically these proxies can handle local/cloud protocol conversion
... there may also be a specialized third protocol for proxy/proxy communication
... specialized to NAT traversal
... thing directories
... focus in on the integration pattern
... can be co-located with proxy, but definitely a separate function
... so also touches on local vs remote aspects
... what we want to do is orchestrate the application to the proxy, the thing to to the proxy, etc.
... need to register a TD (publish) with the Thing Directory
... proxies can discover things to proxy by searching the Thing Directory

matthias: comment that TD needs to be transformed
... if it is to be used from the public domain
... another option is the proxies has some kind of forwarding capability
... any way we do it, we probably need this kind of functionality

koster: yes, at the very least we need some way to translate from local to remote

matthias: probably it's the proxy that has the knowledge for how to do this

koster: diagram does not really show the sequence or where things happen
... but I agree that the proxy is responsible for transforming the TD
... I can try to refine the diagram to add another level of detail

matthias: from the last plugfest
... got the impression that people wanted to do this
... so we should have some guideline for people to follow

koster: should we write this up on the wiki?

matthias: have found it is hard to do this on the wiki
... so maybe easier just to keep a presentation on github

<Zakim> kaz, you wanted to propose we think about (1) topics directly related to our deliverables and (2) other topics which would be needed for implementing plugfest (e.g., discovery,

kaz: two points
... thing directory
... if this a separate entity
... we should clarify the functionality

koster: yes

kaz: better to have two levels of topics and goals
... first level, directly related to deliverables
... second level, implementation necessities
... and example of the latter would be discovery, thing directory, etc.
... would be easier to understand if you separated

koster: so one is how to validate our work items
... the other is guidance on implementation
... but we do want to document these things, like TDs
... we may discover we do want to specify some of these in future recommendations
... but for now useful to provide guidance at least
... also maps on normative to informative

mccool: I think we should prototype with authorization
... we need to work up a set of requirements
... and then at least some of us should be trying to implement them

matthias: probably want to look at one of the most recent commits to node-wot
... bearer tokens, https support
... but not coaps yet
... but did add a mechanism to pass credentials

mccool: I also thing what we should do should work with node-wot

matthias: no coaps yet
... was hoping students could handle, but have been some issues

koster: some places...

mccool: obviously in the long run we do want coaps
... but it's a question of timing

koster: it would be good to have one authorization server as well

mccool: one other thing I want to look at
... although it is a much lower priority
... is using Interledger to pay for things

koster: there are other interesting ways to use ledgers

mccool: but... we have to crawl before we walk before we run
... let's make sure we get the basics working first
... ACTION: work on plugfest security goals first thing after the break

koster: issue from last week
... was a suggestion to sort it by client
... flatten out the graph and making it a little clearer
... this application was able to work with these things
... any other agenda points?

mccool: agenda for next mtg week of Jan 8...

kaz: btw, generated a simplefied version of the plugfest diagram using inkscape
... may be helpful for the flattened version of the graph

<kaz> http://www.w3.org/2002/mmi/kaz/images/201711080-plugfest.png

<kaz> http://www.w3.org/2002/mmi/kaz/images/201711080-plugfest.svg (member-only)

koster: AOB?

(none)

<kaz> next meeting: Jan. 10th

<kaz> [adjourned]