Meeting minutes
Previous minutes
<kaz> Sep-8
seb: we review some PRs
… notice that today we'll review signatures
… we discussed also about action operations
… then we had a presentation about a new Action model from Cristiano. it is available on github
… we should evaluate it in a plug fest. Together with the current proposal
… then we discussed about initial connection in forms
… some doubts about the operation type.
… minutes look okay?
… ok then they are approved
TD signatures
<kaz> Enveloped JSON Signature draft
mccool takes the stage
mc: I set a new w3c repo called wot-ejs. Ejs stays for Enveloped JSON Signature
… the document skeleton is already in place
… some steps are really related to TD, I need to remove this dependency
… when computing the signature is safer to inline a referenced object
… I'm looking for solutions
dape: we used to have securityDefinition object called securityDefinitions
… is it the same? or a new one
<Zakim> dape, you wanted to discuss securityDefinitions and schemaDefinitions?
mc: it should be schemas probably
… and securityDefinitionS
ben: inline objects are interesting, +1 about doing this in 1.1
<benfrancis> https://
mc: we labeled the issue as deferred
… cause it breaks retro-compatibility
… we have breaking changes
… we probably can go with it but we need to least breaking changes
… and warn people
… this would help canonicalization
… a canolical TD will always be 1.1
… it improves verbosity
cris: do we need to stick with 1.1 label? can we go directly to 2.0?
mc: makes sense
… is another approach
seb: we also did some breaking changes with forms
… however we can mitigate it with text about how to be really backward compatibile
… we don't have strong constraints
… about backward compatibility
… 2.0 is next charter
… but maybe we can skip directly 1.1
cris: yeah that was my point
mc: beside this, should I go on with a PR for 300?
seb: we can decide this in TPAC
… and yes please go ahead with the PR
kaz: I want to stress the importance of backward compatibility
… we have to think about it in every version (even 2.0)
… we need to be consistent
mc: another option is to write down just the breaking changes as 2.0 spec
… and then publish a full spec 2.1
… I'll go ahead with a PR
seb: ok, it is an important topic to be discussed during PR
<benfrancis> https://
mk: do we have list of priorities for breaking changes?
seb: we was very careful about not-breaking backward compatibility
… i don't know about other breaking changes
… it is not easy to define backward compatibility with TD
… for example if it checks the context link it would already fail cause it is different from 1.0
jan: is the context enough to differentiate between two different versions of TD?
seb: yeah it should
jan: then yes the consumer should be able to handle multiple TD versions
seb: I'd like to postpone this discussion to TPac
PRs
<kaz> PR 1207 - WIP: Updates for TM Chapter
<kaz> PR 1208 - Add queryaction and cancelaction operations - closes #302
<kaz> PR 1226 - Add queryactioninstance and cancelactioninstance operations - closes #302
seb: I'm still working on 1207
… is 1208 ready?
… there is also an additional PR 1226
ben: the twos PR are identical except for the operation names
… pr is tackling representing action queues
<kaz> related Issue 302 - How do you cancel or query the state of an action request?
ben: I tried to use the changes to create a new TD but it creates a big TD
… futher more it is not clear how consumer would use variables to interrogate an action instance
… simple use case becomes more complex
… my final idea would be to use Profile mechanism to describe this use case
… separate the problem in twos
… query/cancel action
… and how to deal with queues
seb: I agree, the TD is super complex
… my feeling is that the community will not use it
… what about subprotocol?
… like a deafult
… maybe it could clearify how to link variables
… and remove a couple of forms
ben: I kind of agree
… but it works only for green field devices, which is what core profile is there for
… you need out of band information
mk: collection supports would be nice
… would solve also this problem, is it?
ben: there is a gap
… we encountered the same problem in discovery
… different proposal but none of them quite work
… we can continue down the road
… how open api solve this
seb: how this will look like in the core profile?
ben: very simple TD with a simple url enpoint for an action
… and apply all the defaults
cris: we may find a way in the end
ben: I also found out that the core profile there are missing piecies
… plus I agree go down with core profile
… and keep working on hypermedia approach
mk: collections might be really the key
seb: I still don't understand how a TD will look like with the core profile
… thinking also about plugfest in two weeks
… I would try to implement both
… understanding benefits of both
ben: +1
… I have two PRs open which one should be choose?
… I'd go with 1208
… for simple use cases this is all you need
… then we need more implementation expirience
… if we'll try to describe this we need a simple mechanism that can be easily implemented by consumers
seb: fine for margining
cris: +1 for merge!
<kaz> PR 1208 - Add queryaction and cancelaction operations - closes #302
mc: is webthings doing something like this?
ben: I'm working on it
… but first only invokeaction
mc: node wot will do it?
dape: yes
seb: we are getting closer
PR 1227
jan: small clean up of merge commit fragments
… content is preserved
seb: good
mc: approved
seb: merged
Issues
Issue 1217
<kaz> Issue 1217 - Payload pattern binding
seb: how to describe SenMl? it has its own payload pattern
… it is annoying to describe it in every interaction affordance
… we don't have a way to describe payload patterns
… should we add it?
… is it a protocol binding topic?
… ege proposed why don't use schemaDefinitions?
… it would be cool to have external schema definitions
mk: I already have some TD conformant to SenML, I don't know what we are trying to accomplish here
… what about using content format?
… we can re-use patterns that are already there (using senml+cbor)
philipp: base name is just the Id in the TD, unit are repeated
… I would like to use every opportunity where I can skip data
… not repeting
mk: ok got it if something don't change that can be in the schema
phillip: senMl can be skipped
sorry kaz but I am in the queue
:)
I still have to speak :D
mk: I don't favore subprotocol
<McCool> (McCool leaves)
<Zakim> dape, you wanted to what about json schema "default" term
<kaz> (some more discussion)
discussion about how to describe SenML in the TD
Sebastian picks up
seb: maybe it is a common pattern also in philips Hue
kaz: we should think about concrete use cases, ideally during TPAC
… during PF call we was wondering why we were just a small group
… I would suggest to bring this problem there
cris: +1 for having this in a plug fest
<citrullin> +1 from me as well
<citrullin> fair enough, good point :)
seb: can I ask to mjk to paste TDs in the issue body?
Issue 878
<kaz> Issue 878 - Describing initial connection
seb: forms should be optional?
… ben is not ok with open operation name
… the motivation was to differentiate to other forms entries
ben: for web socket does not really needed
… plus the operation name applied to a device is weird
seb: yeah I this should work without operation type
ben: I would start to putting some text saying that forms are optional
cris: I would mention validation problems
… i.e. a TD may have no forms at all
seb: PR in flight for next week
… closing the meeting, we are moving forward
<kaz> [adjourned]