Meeting minutes
Agenda
Sebastian: welcome
… we have a couple of PRs to review
… then a list of issues
… in particular we have an issue about initial connection that we need to tackle
… something else to add?
previous minutes
<kaz> July-14
<kaz> July-21
Ege: please add to the review also previous minutes, last time we couldn't review them
Sebastian: we'll review after this
Sebastian: so you talked about precesion
Ege: yes if you talk about resolution you should use multiple of
Sebastian: ok, then you discussed about how to handle security with links
McCool: yes the default for links would be no_sec but now you can add a security term to specify which securityDefinition should be applied
Sebastian: then we have the proxy-to
McCool: yes proxy-to is a reverse proxy statment
… so it is different from what we currently have
… we need an explanatory text
Sebastian: you added new badges
McCool: we need to debug badge randering problems
Sebastian: it seems that you closed some issues
… some were very old
… why was 1138 closed?
Ege: sometimes some notes are not easy to see, why ed notes are not included in the final version
Kaz: if needed we can include editor's note but we have to define a good policy when publishing
<benfrancis> Ege: FYI there are two types of notes in ReSpec. ednote (https://
Sebastian: minutes approved
… now 14 July minutes
… we discussed about the modbus binding
… the outcome was that we merged the PR
… then we merged subscribeallevents and unsubscribeall
… it seems there's a problem with title section
… is it intended ?
Kaz: double check the link for the title
… maybe there is mis-usage of topic vs subtopic for RRSAgent there. if you want I can fix the style based on your preference.
Sebastian: it's ok to keep as it is
… we discussed also about initial connection. we'll review it later
McCool: we should look carefully for URL template for MQTT
… I proposed one solution that it might not be "standard practice"
Sebastian: is it related to initial connection?
McCool: sort of
… we also discussed about different terms
Sebastian: ok, any objections to publish the minutes?
… ok approved
Pull Requests
PR 1155
McCool: it is realted to testing repo. it updates the implementation report
Sebastian: if we update the file we'll lose the link in the 1.0 spec
McCool: yeah we should have a dedicated link
McCool: pointing to github is problematic cause it is a moving target
… we can use a different name
… with the version appended
Kaz: yes, I would suggest creating a subdirectoy for v1.1 or something like that. We've been doing so to handle the static HTML for publication.
McCool: I'll leave the old report in place and use this new notation
1167
<kaz> PR 1167 - fix: fix RDF triples example from Thing description json-ld 1.1
Sebastian: status not clear, we need Victor's guidance
McCool: it also relates to canonicalization and preserving names
… for directories we decided to return raw RDF not TDs
… by relaxing that requirement we'll make our life easier
PR 1175
<kaz> PR 1175 - fix: replace "name" with "title" in TM example
Sebastian: a simple typo fix
… but the problem is that the author is not a w3c wot member
… we can decide to merge it anyway
McCool: is he a invited expert candidate?
Sebastian: he was a student but it also work under industry
McCool: if we merge the PR we need verbal commitment of IPR
Kaz: is it an editoral change?
Sebastian: yes
McCool: ah ok then we can accept this PR
McCool: by the way this issue remind me to create another one about metadata in id
… it might be a security problem
… so we need to add a note
Ege: ok be careful that we have an RFC describing how id should be
McCool: it would be better to encode opaque numbers
Sebastian: ok back to the PR, is it ok to merge?
PR 1197
<kaz> PR 1197 - fix example 37 and its canonical form
Sebastian: basic term was missing
… any comments?
… merged
Opaque ids
<McCool> https://
Pr 1198
<kaz> PR 1198 - Defaults fix
Sebastian: it addresses two issues
… we used to have only default values for read/write properties
… the pr tackles also observeproperty
Sebastian: then it resolves the issue with the content-type in additional responses
Ege: yes I added a sentence
… if content-type is missing its value it is the same of the form element
Sebastian: ok
… any other comments?
… merged
1201
<kaz> PR 1201 - Security reorder
Ege: the main problem was the secuirity example was miss ordered. Now the new order is from "easy" to "hard"
… I used small paragraph
Sebastian: are they visible inside the Table of Content
Ege: no
Sebastian: ok but they are nice
Ege: I also added a paragraph is it ok ?
McCool: yeah it is fine, but I'd like to review the whole paragraph
… maybe I can do fix ups later
… let's keep open and add me as a reviewer
… if you don't hear from me just merge it next week
issues
Issue 1200
Ben: in webthing gateway we have top level links (forms) for actions events and properties
… currently we can describe events and properties
… we are now just lacking operation types for actions
… they are not really used to much especially queryanyaction
… if we don't add this we'll removed top level endpoint
Sebastian: it makes sense to have queryallactions
… but what do you mean with invokeanyaction
Ben: in webthings gateway you can send a GET request to get a list of pending actions
… and POST to the same endpoint to invoke any of the action
Daniel: which the difference between invokeanyaction or invokeallactions?
Ben: in the gateway you don't invoke all the action with one request
Ege: it is similar to multiplewriteproperties
Ben: it is not that either cause you can just invoke one
Ege: we have also need to define a payload format
McCool: when you say queryallactions you are quering all the status of the action list?
Ben: yes
McCool: so it is just convience
… but it might be important to have queryallaction for resilience
<kaz> Ben's description on 3 possible use cases for querying an action
Ben: you can get induvial instance of an action
… but you can also get the status of all the pending request on a particular action endpoint
Sebastian: should be all of them mandatory?
Ben: just the first
Ege: they might be critical for applications coordination
<benfrancis> https://
Cristiano: this issue is really related to having also a definition for queryaction
Ben: see link above
Cristiano: yeah exactly I see that issue as a blocker
Ben: I agree
… so if we are going to add this new operations should we also add queryallaction operation?
Ege: yes
Cristiano: +1
Sebastian: is there any security concerns?
McCool: yeah it should be access control
McCool: we need to express this
Kaz: I'm OK with adding two new features if we really need. So I'd like to see some more description about the three proposed use cases, e.g., with concrete TDs and use case scenarios.
Sebastian: do we want this query all action operation type?
… still have doubts about invokeanyaction
McCool: any feel like a random action
Cristiano: it seems that it a construct to map a protocol level construct
Ben: correct
McCool: maybe we can model that with other td features
Koster: is it really just invoke action by name?
Sebastian: multiple actions?
Koster: no one of the time
Sebastian: what about the payload structure?
… does it solve the grouping problem in the echonet?
Kaz: regarding the group of actions, we are discussing about it with them. They can work on this feature for the tpac
<McCool> (ps I like the "invokemultipleactions" idea, covers one, as well. But it does seem a little specialized.)
Ben: I posted different examples as below
<benfrancis> invokeaction - POST /actions/fade {"level": 100, "duration": 10}
<benfrancis> invokeanyaction - POST /actions {"fade": {{"level": 100, "duration": 10}}
<benfrancis> invokemultipleactions - POST /actions {"fade": {{"level": 100, "duration": 10}, "reboot": {}}
Sebastian: ok better but still can't really get the anyaction case
… I am open to support those operation types
Ege: not super sure about invokeanyaction
McCool: how do I describe the payload?
Cristiano: the same problem with writemultiple
McCool: maybe it is a profile issue
Cristiano: it could be, but I support having this in the TD
McCool: we already put data schema in additionalResponses
… so maybe we can do the same in root level forms
Koster: having tags in the dataschemas could help
McCool: we need a wrapper schema that refers to each schemas
… it is tricky
Ege: didn't we agree to have it always as an object
McCool: it is convenient to describe alternative formats
Koster: agree
Sebastian: what happen with ordering in invokemultipleactions? which one should be executed first
… ?
Sebastian: it seems that we agree on the direction
… we still have a couple of issues to resolve.
Ben: I think we should first resolve queryaction first
Sebastian: introducing invokeanyaction is reduntant if we add invokemultipleactions
Cristiano: true
Kaz: As I already mentioned, I'm OK with adding these features, but still would like to have more detailed description on the use cases with concrete example codes, e.g., some LED(s) invoked and queried how.
Ege: going back to echonet problem, I don't think this would solve it
Kaz: right. we need to handle ECHONET's action grouping capability as a separate problem.
McCool: for now we can define the op and defer the payload description to protocol binding topic
Ben: do we have time for queryaction?
Sebastian: maybe can you provide a PR about it
… ?
<benfrancis> https://
Ben: I provided a TD describing an action queue, it would be better to have a feedback on that first
McCool: I agree
… I support in general having queryaction operation
<McCool> ... it's not whether we need it (we do, for recovery of crashed consumers, for example) but how we do it
Daniel: invokeanyaction is a shortcut to call a dedicated action, but invokemultiple open a totally different scenario
… how do we handle multiple results?
McCool: how the response will look like
Ben: yeah this again goes on the support the fact that we need tackle first how to query an action status
Sebastian: ok let's follow up in the issue
… daniel is correct in regards to multipleinvoke
issue 878
<kaz> Issue 878 - Describing initial connection
Sebastian: also here we discussed about a new operation type the open
… ben provided an example on top-level connection forms
Ben: yes I tried to described two scenarios, one of which it more verbose
… this problem is similar to mqtt, but I want to understand how much
Sebastian: in mqtt it is more important to have a base and then a specific topic in the different affordances
Ege: for me the main difference is operational
… with normal enpoints I just look after operations inside the forms array
… with this top-level endpoint it breaks a little bit the desing
Ben: so far we don't really specified how to use forms in interactions
Ege: I support top-level form
<McCool> (never mind, should defer to ben here)
<McCool> (but I do think we need a place to put the initial "connect" URL for websockets, MQTT brokers, etc)
<McCool> (and I also think this should be a form)
McCool: connect is an affordance
Ege: is not a capability of a device
McCool: links are more about relations
… so I support having connection as a form
Sebastian: how about define exception for forms when websocket is used
… ?
Ben: it seems a reasonable workaround for 1.1
Ege: how does it look like when used with other subprotocols?
Ben: the consumer has to support the subpotrocol
Sebastian: it is open to the user
Ben: there's going to have just a single ws enpoint too
McCool: we can define exceptions for every protocol with any websocket
… I'd like to have an url as subprotocol
Cristiano: can you clarify this new rule?
McCool: interactions will not have forms if websocket top-level form is present
<McCool> (btw: time check. Now at the end point)
Ege: readonly, writeonly and observable are just hints within the current spec.
… but now if we don't have forms they became operational relavant
Cristiano: btw the new rule is also about breaking backward compatibility just for web sockets
Ben: I think it is fine cause we don't really have implementations about it
Ege: true
Cristiano: agree
Koster: using the idea of wrapper schemas at the top-level would help maybe here
Ege: how to handle mixed information in forms and in the root level
Ben: you can treat them as another form
adjourned