Meeting minutes
Minutes review
https://
<Sebastian goes through the minutes>
MMC: note that we should not forget about IANA registration for thing models
https://
SK: no objections to merge minutes -> approved
PRs Overview
Signature
https://
MMC: had long discussion ... what if IETF comes up with another solution
… suggest to have an external document
… spin off IETF RFC
… canonicalization normative in TD
… signature as external document
… we should not merge PR#1151
… plan to create new note and will let people know once this is done
… see discussions in https://
SK: Okay, lets close PR#1151
MMC: Need to create signature extension
SK: FYI, work from Oliver will be taken over by successor with IETF background
MMC: Yes, need proper security review
Add queryaction and cancelaction operations
https://
Ben: naming is still WIP
… distinction between query action queue and instance
… subscribe to event is somewhat similar
… might need "queryactioninstance" ... but seems clumsy
… would like to get feedback from group
SK: no strong opinion on naming
Ben: unfortunately no real word in English that differs between instance
… that's why I use "queryactioninstance"
… see recent proposal, https://
SK: the term "instance" makes clear we deal with an instance... on the other hand the name is rather long
DP: proposal "queryanaction" ?
Ben: even more confusing ;-)
SK: "queryactionS" with plular?
Ben: was part of the original proposal
SK: Suggest to make a decision
CA: Agree, matter of taste
… like the current proposal
MMC: to me instance means one created resource
… need clear definition
… ok with current terms
MK: No objections either
FS: fine
Kaz: +1
SK: Looks we have a resolution
… queryactioninstance, queryaction, queryallactions
Ben: cancelactioninstance ok too?
… separate issue with meta interactions, suggest to create separate PR
… update PR#1208 with the aforementioned terms
… separate PR for meta interactions (top level forms, Issue#1200)
… https://
CA: Plan looks good
… later I will make another proposal
SK: Okay, let's look at it later
fix: maxItems,minItems are xsd:nonNegativeInteger
https://
DP: added missing fixes and checked with Victor
… IPR issue because of original author
Kaz: marked as non substantial
SK: let's merge
Yet another action model
SK: Cristiano please go ahead
CA: It is a patchwork of the other proposals
<Cristiano goes through slides>
… actions may be more complex than other interactions
… query, cancel et cetera
… there can be an action queue
… or a single action
… we have different use cases
… * webthings.io
… * BRAIN-IOT
… * OPC UA
… at the moment we have 3 proposals (Victor, Ege, Ben)
… dynamic TDs by Victor
… issues: caching, security, no static description
… w.r.t. new ops and URI templates we had concerns about how consumers understand it
… *New* Proposal
… leverage on thing models and action TDs
… idea is to use ThingModel to describe further operations ... after invokeaction operation
… after invokeaction a virtual resource is created and a TD could describe the new thing
… action does not return TD by itself
… a variable "fills" the mapping
DP: how to find variable ?
CA: there is mapping field
MMC: Note about absolute pointers in mapping
CA: JSON pointer refers to output one gets
CA: about green field
… core profile could work without model
… model could still be a validation hint
CA: Pros
… no id tracking, embedded in ThingModel
… lightweight
… backward compatible
… flexible (green and brown field devices)
… compact
CA: Cons
… new op types needed? Yes, need some but not all
… queues might be a static resource
SK: I like the proposal a lot
… action to me means being kind of a produce.. with new functions
… anhow, would keep output and input for core profile
… but have a way to indicate or point to the TD
… in general I like the idea a lot
… additional features like cancel/monitor action is in a separate TD
CA: having "model" in action "output" tries to solve 2 issues, but we can put "model" a level up
Ben: Clever idea
… I would say action is not a thing
… maybe better to have ActionDescription than TD
… moreover, a TD would not be self-contained any longer
… biggest question: how to deal with multiple consumers?
CA: core profile could live without URL
… brown-field devices would not be supported
Ben: case: 2 consumers
… 1. consumer invokes action
… 2. consumer wants to monitor
… how does separate consumer get the TD for the action
CA: Need action queue
… and infer thing description
Ben: wonder about relation between BASE_ADDRESS in example
CA: action return value needs to have information about the variable
Ben: Ok, got general idea
DP: ActionTD being a real TD makes it possible to use any existing tool
Kaz: TD is a mechanism to describe thing capability
… model view and controller is not clear to me in this proposal
CA: we do not embed control
… it is a meta model
Kaz: Should clarify the entities and features
… and clarify our expectations
Ben: w.r.t. Charter... the charter should cover this proposal under the current charter
<kaz> s/model view and cotroller/the separation and assignment of Model-View-Control/
Ben: a new resource is created once an action is invoked
… in my proposal it is in TD
… in Cristiano's proposal it points to new TD
… both seem valid
SK: How can we proceed?
… suggest to get some experience with the new proposal
… maybe in PlugFest... will happen in some weeks
CA: Where to put the slides and the information?
… experiments are valuable
SK: Use Ben's proposal as working assumption
… or come back to the new proposal
MMC: in PlugFest we can add prototype
… I like the hypermedia approach
… node-wot prototype would be fine
… maybe both approaches are complementary
DP: Suggest to wait for Ege/Victor also since they provided a proposal also
… using Ben's proposal as working assumption is fine
… add slides to GitHub
SK: ask Cristiano to upload slides or create new issue
… have some more discussion also next week
… but maybe stick for the time being with Ben's proposal
<benfrancis> cris: Note there are some existing proposals in https://
CA: I like also the comment that we may need both in the end
<cris> benfrancis: I was thinking about that, I'll post them there :)
SK: Let's give anybody a chance to take a look the next days
CA: Makes sense
Issues
Describing initial connection
https://
SK: 1. aspect, define forms optional
… 2. forms on root providing endpoint information
… avoids cluttering the local forms with the same information over and over again
… if global forms contain enough information no local forms needed any longer
SK: objections/concerns w.r.t. this change ?
… might run into interop issues ... since local forms are mandatory at the moment
… however, we can define a process that creates an 1.0 interoperable TD
Ben: proposing local forms optional always or depending on protocol like websocket
SK: would not say that for a specific protocol..
MMC: ECHONET
CA: modbus is another
MMC: breaking compatibility might be an issue
… but there are not that many 1.0 devices
… so it seems okay to me
Kaz: Agree with McCool
… suggest to see what happens during PlugFest
SK: old implementation will not accept the new TD
… I suggest to put a note in the spec mentioning this fact
… are we still OK to make local forms optional?
Kaz: Suggest to see the impact in PlugFest
MMC: Can add it as "at-risk"
… suggest to go ahead
SK: new op value "open"
… meant to indicate that it is meant to open connection
… see https://
<kaz> [adjourned]