W3C home > Mailing lists > Public > public-wot-wg@w3.org > December 2017

[plugfest] minutes - 20 December 2017

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 21 Dec 2017 01:08:04 +0900
Message-ID: <CAJ8iq9Uf1XzsmWPyWm_ERN88K=Q0A7mdJEJV3BSBnek9vVKZxg@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking these minutes, McCool!




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

                               - DRAFT -

                              WoT PlugFest

20 Dec 2017


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


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

          Koster, Matsukura



     * [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
   ... 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
   ... other ways of doing events will probably have to wait until
   ... 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
   ... 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
   ... 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

   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
   ... any way we do it, we probably need this kind of

   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

   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

   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

   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

   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


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


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

   koster: AOB?


   <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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:49 UTC