[plugfest] minutes - 20 December 2017

available at:
  https://www.w3.org/2017/12/20-wot-pf-minutes.html

also as text below.

Thanks a lot for taking these minutes, McCool!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                              WoT PlugFest

20 Dec 2017

   [2]Agenda

      [2] https://lists.w3.org/Archives/Member/member-wot-wg/2017Dec/0028.html

Attendees

   Present
          Kaz_Ashimura, Kuniihko_Toumura, Michael_Lagally,
          Ryuichi_Matsukura, Tomoaki_Mizushima, Michael_McCool,
          Daniel_Peintner, Kazuo_Kajimoto, Toru_Kawaguchi,
          Michael_Koster, Matthias_Kovatsch

   Regrets
   Chair
          Koster, Matsukura

   Scribe
          McCool

Contents

     * [3]Topics
     * [4]Summary of Action Items
     * [5]Summary of Resolutions
     __________________________________________________________

   <kaz> scribe: McCool

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

   <kaz> [6]Michael Koster's slides

      [6] https://github.com/mjkoster/wot-protocol-binding/blob/master/plugfest-prague.pdf

   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>
   [7]http://www.w3.org/2002/mmi/kaz/images/201711080-plugfest.png

      [7] http://www.w3.org/2002/mmi/kaz/images/201711080-plugfest.png

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

      [8] http://www.w3.org/2002/mmi/kaz/images/201711080-plugfest.svg

   koster: AOB?

   (none)

   <kaz> next meeting: Jan. 10th

   <kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [9]scribe.perl version
    1.152 ([10]CVS log)
    $Date: 2017/12/20 16:04:32 $

      [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [10] http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 20 December 2017 16:09:15 UTC