Meeting minutes
minutes review
https://
Lagally: last week had discussion of terminology around TD fragment, partial TD, defined some actions
… cristiano and daniel to provide draft PRs
Lagally: any objections to publication?
… hearing none, will be published.
FPWD feeback - PR 62
Lagally: we did resolve many comment prior to FPWD, but have gotten more since
… we should review and resolve
… we do want to make sure the document makes progress and becomes useful in the next month or two
… it has many gaps and contentious items
… we ultimately want to get a document that helps the market
… and not just "one more IoT specification" but something that is easy to understand and adopt and solves real interop problems
McCool: I would like to propose that if there is a contentious but non-essential feature we should just take it out for now
… the main goal is interop and we should focus on that
Lagally: we we have two PRs and 37 issues
<mlagally> https://
Lagally: this PR just catches up the editors' version to changes needed for FPWD
… propose merging, not controversial
Lagally: (merges PR 62)
Lagally: next PR is canonical representation; will not look at that right now
McCool: however, it would be helpful to link the related issue, which I hope is also linked to issues in the TD repo
FPWD feedback
Lagally: they have been labelled in the repo
https://
<kaz> Issue 59
Ben: see there are two main goals which are a bit in conflict
… one is about readabilty, the other about interop
… and there is also the issue of protocols
… suggest perhaps a "core" profile that supports HTTP and JSON and a constrained one that supports CoAP (and CBOR?)
Lagally: currently looking at "data model" constraints, then constraints on particular protocol bindings
McCool: so want to +1 what ben and ml said
… and note that I think we all agree the data model is central
<mjk> what do we mean when we say "readability"?
McCool: and data+http maps onto what ben is calling "core", and data+coap maps onto "constrained"
… we can argue about names, but conceptually we are on the same page
… and as for goals, I agree with ben that human readable + interop can be in conflict
<mjk> so , descriptive variable names?
McCool: and I propose we get interop done first
… then go back and see what we can do to improve interop
<mjk> embedded documentation strings?
McCool: I also think documentation makes more sense to be mandatory in the Thing Model
… so maybe what we should do is make a link the *model* mandatory
… and make documentation mandatory in the thing model
Koster: so I'd like to understand this better
Lagally: can you comment on what you felt was controversial
Ben: so human-readable means strings, sent over the wire
… but constrained devices need a very compact, binary form
… and these are conflicting requirements
Koster: ok, I think it is what I thought
… so, titles, and descriptions, and also JSON vs. CBOR
… JSON is definitely easier to read
Ben: also complexity of data structures
… lots of nesting is a problem for constrained devices
… if we limit depth, it can make it harder to read
Koster: making TD lightweight and putting docs in TM makes sense
… but yes, for constrained devices, just using numerical IDs for variable names makes sense
McCool: I think a compromise might work, for nesting, eg. 4 to 16
Ben: there is the issue that that might not satisfy anyone
Koster: well, 1 is at the extreme end, flattens everything
… but the observation is that 2-3 is the natural limit
… what people want to do is have a variable name that refers to a single struct
<kaz> WoT Profile Editor's Draft - 5.1.2 Thing
McCool: there are several cases where we do want some nesting, eg for modularity, to make queries easy
… so 4 seems safe
Lagally: I'd like to propose 5 just to be safe.
McCool: I'd like to say recommended practice is 4, and validator starts giving warnings when you are at 5
Koster: constrained profile should be good enough for devices that are bluetooth/zigbee class
… but I would expect a gateway to have both
Koster: gateway may be acting as a proxy for constrained devices and so would be good to support
McCool: so is the constrained a strict subset of core, or separate? We need to decide
<mlagally> proposal: max depth of data schema is max 5, recommended practice is not to exceed 4.
Lagally: I think we should also focus on the data model, that definitely is common
<mlagally> proposal: common data model - max depth of data schema is 5, recommended practice is not to exceed 4.
Ben: do think we are on a bit of a tangent right now
… and want to get back to the original issue
… I do agree that if there are two profiles they should have a common data model
… but I think the TD already does that, and perhaps we should improve the TD spec
Lagally: not skipping over your comments, just capturing a consensus so we can make progress
McCool: think we should capture this consensus, then get back to ben's split profiles
Resolution: common data model - max depth of data schema is 5, recommended practice is not to exceed 4.
Lagally: ok, let's go back
McCool: some questions to ben: is core > constrained, or are they separate?
Ben: separate
McCool: and can a gateway support both?
Ben: yes
McCool: in which case the common elements need to be aligned
Ben: so doing the same thing, but with different protocols
Koster: so really these aspects should be completely handled by protocol bindings
Lagally: issue is that protocols are designed to support a lot of different options even within a single protocol
… so we need additional constraints even within a protocol
McCool: I think a profile is in fact prescriptive
Ben: agree; point of profile is to be prescriptive for greenfield devices
… so they are guaranteed to interop
Lagally: and if we do our job well, will still cover 80% of brownfield devices
Koster: there could be a slight middle ground when there are only a small number of options
Ben: would not suggest getting rid of the TD altogether, but the more we prescribe the smaller the TD can be
Lagally: so getting back to the issue, since we don't have a volunteer for CoAP, I propose we focus on HTTP
McCool: agree that we should focus on http for now, as long as we leave room for adding coap later.
Ben: sure, as long as any profile has at least one protocol
Koster: does that mean that if I wanted to build a constrained device that support the "core" profile, it would have to support http?
Koster: beyond the protocol binding there is also the issue of construction of payloads
Ben: my understanding is the protocol binding says what the payload format is
Ben: producer and consumer need to have a common understanding
<mjk> mm: the gateway use case can inform how the core + protocols work together
McCool: core does not mean everyone has to support it
… it's just the "http" profile
Ben: a mobile app is a good use case for both direct connect and app interaction
McCool: and I think we should focus on the gateway use case
sebastian: concerned with the name "constrained profile" as being too broad
Sebastian: I have a concern about the "constrained" name as well, since there might be other protocols for devices, eq mqtt
Sebastian: propose a structure where the core profile is a data model constraint
Sebastian: I would like another approach to structure this
… make core all the common constraints
… then the other constraints are handled in the binding documents
… make each binding document have a chapter defining constraints when used with the core profile
… I would avoid trying to integrate all the protocol stuff here, since we have the binding documents
Lagally: I like this idea of taking out the data model first, and keeping the protocol binding separate
… regardless of where we put it
… and there are lots of things that are relevant to interop that needs to be handled in protocols, such as error codes
… event handling, etc.
Ben: I think we all agree on the core concepts, we just disagree on names and where the concepts are documented
… it's just where those specs live that we are going backwards and forwards on
Lagally: let's first make the spec, then figure out where it goes...
Lagally: I also see a lot of issues coming up when trying to answer data model questions in protocol bindings
… so better to consolidate that
<mjk> ackm
Ben: right now protocol template is very general
McCool: so... profiles are prescriptive, so what we want are "descriptive" specs (TDs, protocols bindings) with "prescriptive" subsets that guarantee interop
Koster: want to understand if profiles are a template...
Lagally: have to be concrete and something that we can check conformance of an implementation againts
Koster: we need to write down the constraints somewhere... so that is the profile spec?
Lagally: yes, a profile is conceptually the set of all constraints that guarantee interop
Koster: and we also need actual data models for particular devices
Lagally: out of scope, necessary, but look at everything under specific classes of devices
… for example, we probably want to specify the units to be used for measurements
Lagally: although there would be issues in insisting on metric, so we might have to have options, precedence orders, etc.
Lagally: (types up summary of discussion in https://
McCool: suggest for MQTT/COAP we ask those working on protocol bindings for these to address
Sebastian: but agree that let's do HTTP first
Lagally: I think we agree that we should focus on HTTP first anyway
(sorry dropping)
issue #49
<kaz> Issue 49
Cristiano: suggest to restrict the core profile to one security schema
Lagally: can cris create a PR for next time?
issue #45
Sebastian: I think this is already discussed and addressed
Lagally: closing
issue #42 need ege in the next discussion
<kaz> Issue 42
Lagally: need Ege in the next discussion
… need to discuss supported subprotocols and event model in general
… schedule on the agenda for the next call
issue #43
<kaz> Issue 43
Lagally: made a PR to address the editorial comments
Cristiano: "type" is just one field, should allow an array
Koster: "@type" does not imply multiple inheritance and can be array
Lagally: initially was to simplify due to requiring both string and array, should constrain to always being array
Cristiano: the comment was about allowing both array and string
Ben: allowing string makes for nice visual readability
Koster: there are other reasons where the source has a single string and doesn't need to be expanded
Lagally: seems like a small decision but this could be consequential
Cristiano: we should be consistent, things are more complicated if there is special behavior
Lagally: can we remove the editor's note in sec. 5.1.1.2?
issue #60
<kaz> Issue 60
Ben: allow multiple forms in a TD to enable layering multiple protocols
Lagally: what is the required behavior to specify when there are multiple protocols?
… we could require a separate TD
Ben: it's OK to allow a single endpoint for each protocol
<kaz> [adjourned]