Meeting minutes
Minutes
Lagally: there are not many people today, so minutes review next time
Agenda
Lagally: would review the MRs
… any other topics?
(none)
MR 77
<mlagally> MR 77 - New Protocol Binding section
Lagally: would like to talk with Ben
McCool: note there are several MRs
Lagally: would like to start with MR 77
McCool: last week, I created a branch
Lagally: ok
Ben: hope this is the least controversial
Ben: first one is Properties
… less controversial operation
… some comments from McCool
… (goes through the diff)
… 2 open issues there
… e.g., the body of GET request
… couple of suggestions there
McCool: a few comments here
… reasonable approach to me
… focus on HTTP
… regarding the body of GET request issue
… server must ignore and the client may do it but not recommended
Lagally: should we see the proposal at a higher level first?
… a couple of questions
[[
A Consumer or Web Thing conforming to the WoT Core Profile MUST implement this protocol binding.
]]
Lagally: so the protocol binding defined at section "5.2 Protocol Binding" must be implemented
McCool: a Consumer or Web Thing which conforms to the WoT Core Profile must implement it
McCool: we should also somewhere probably have a finite set of recommended protocols, etc.
Ben: also add a section on security
… may possibly mention it in that security section
Lagally: security section to be discussed separately
… (goes through the description around Example 1)
… any constraint on upper case vs lower case?
Ben: we have key-value pair
… based on the valid JSON specification
Sebastian: +1
… each JSON processor can handle that
Ben: there is a reference for JSON
referring to JSON Data Interchange Formant - RFC8259
Sebastian: 2 situations here
… specific sub protocol specified
… or not
McCool: you could have JSON Object
… including time information like time stamp
Ben: once we get how Actions work
McCool: if we have GET on property
… server can ignore things
Lagally: but currently we don't any specification about the data format
McCool: you don't have constraint in this section
… if done, elsewhere
Lagally: whether we allow all the possible subsets or not
… is my question
… let's look into the description
… (below Example 2)
… "E.g." right before the error codes
… are these the only possible errors?
Ben: they're just examples
McCool: probably we should describe all the possible errors here
Ben: "401 Unauthorized" actually means "Unauthenticated" here
McCool: we might want to cite the HTTP spec
Kaz: if we can simply refer to the HTTP spec for the errors, we should simply do so
<sebastian> +1
Kaz: but if our meanings are a bit different from the original meanings, we should define the diff here
Ben: in practice, most HTML implementations just have simpler error responses
… if we want to define some specific meanings, we should define them here
Lagally: we don't need a complete list here
… but could just add a table and reference to the HTTP spec
McCool: working on a PR
… noticed some string to be included in the response
… think ignore is a possible option
Ben: problem details for HTTP APIs describing the errors
<mlagally> https://
McCool: would +1
… this is a reasonable set
Lagally: need to have a title?
[[
For example, an HTTP response carrying JSON problem details:
HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en
{
"type": "https://
"title": "You do not have enough credit.",
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/12345/msgs/abc",
"balance": 30,
"accounts": ["/account/12345",
"/account/67890"]
}
]]
McCool: could make detail optional
Lagally: don't want to have many optional features
McCool: could keep it empty
Lagally: so must have problems details based on this "Problem Details for HTTP APIs"
<McCool> in summary, my suggestion is that IF there is a response, it MUST follow this RFC
<mlagally> Proposal: Error responses MUST have details conforming to https://
<McCool> ... and also, there should be a data schema for this error response in the TD (a pending feature...)
Kaz: btw, even we add a reference to "Problem Details for HTTP APIs", we should clarify why chose these 5 errors (=400, 401 403 404, 500)
Lagally: we should add some semantics for each error for WoT purposes
McCool: for example, "401 Unauthorized" is recoverable (e.g., ask the password again)
… but the others are kind of fatal
Proposal: Error responses MUST have details conforming to https://
Ben: suspect the spec (RFC7807) doesn't allow empty value
<mlagally> Proposal: Error response bodies, if they are provided, MUST have details conforming to https://
Lagally: agree?
Resolution: Error response bodies, if they are provided, MUST have details conforming to https://
McCool: the other resolution is listing those 5 errors as examples
<mlagally> Proposal: the list of error codes is a finite list, the current examples in 5.2.1.1. are a reasonable starting point.
McCool: maybe we should create an issue to see the error codes for directory services
Lagally: can you see that?
McCool: ok
… will create an issue on the wot-discovery repo
Action: Mccool: check the pagination response codes in the discovery spec
Action: Ben: double check the list of error codes in WebThings
<McCool> issue to check error codes for discovery https://
Kaz: what about Oracle's Digital Twin service's error codes?
Lagally: can also look into that
Action: Lagally: check error codes of Oracle's digital twin implementation
Lagally: wondering about node-wot's error codes
Sebastian: good question :)
… depends on the protocol you use
… there is no classification of errors at the moment
McCool: the question is error code included in the body or not
Sebastian: will double check with the node-wot team about error handling
Sebastian: Daniel is coming now
Lagally: next "5.2.1.2 writeproperty"
<McCool> https://
<McCool> https://
(Daniel joins)
Lagally: (explains the discussions so far)
Daniel: need to look into the detail
McCool: put some resources from the Scripting APIs above
… Scripting API is protocol-dependent
… error code in the body?
Daniel: in the text, each implementation to provide as much information as possible
Lagally: we're talking about HTTP here
… (explains RFC7807)
<dape> https://
Lagally: the primary point is if there is any additional error used by node-wot in addition to the current list (=400 401, 403, 404, 500)
Daniel: some resource above
… this is more generic
McCool: if we have an abstract class of errors, that's fine
… maybe could be documented here
… the intention is hiding the details from applications
Daniel: useful to have the information of "404" but should not put any private information
McCool: right
… even just checking device's availability could be a footprint
Lagally: let's see what we're doing based on HTTP
Daniel: the interface for node-wot itself should be abstract (=independent from protocols)
… if we get an error with HTTP, we can possibly suggest CoAP to be used
McCool: we could set it up so the Scripting API to handle the context
Lagally: good questions but we don't have to answer to them now...
McCool: can create an issue
Lagally: would like to create an action for Daniel to see the node-wot's error codes
… wot-scripting issue 200 already talks about that
Daniel: think we can reuse the errors within WebIDL as I put above
Lagally: any additional ones from your viewpoint?
Daniel: the list within WebIDL is rather complete, I think
… but I can take an action to look into node-wot's error codes
Action: Daniel: double check node-wot's error codes, are there error response payloads?
Ben: WebThing description API has fetch API
… which information to be considered?
Daniel: if you need to support the interface, we need to consider fetch error as well, though it could be different among protocols
… if you write a property and if the response is success, we'll get 200
McCool: (add comments to wot-scripting issue 200)
<McCool> my comments on error and a suggested implementation https://
Ben: there is a use case
Daniel: there was an open issue on the Scripting side
<dape> wot-scripting Issue 193 - Should writeProperty() return a value
Lagally: if we assume we always return the payload...
Daniel: Ege mentioned there was something reports back with the payload
… not sure they used HTTP and need to look into the detail
Ben: could be a problem
… because it assumes some specific protocol
McCool: we should be careful how to write it up
Ben: as long as it's reference to data schema
Lagally: let's make a proposed language here
(Ege joins)
Daniel: can see the point
… but it doubles messages on the network
RFC7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
<mlagally> Proposal:For writeproperty there's no response payload, the return code on successful completion is 204 (No Content)
Lagally: (shows the RFC7231 to refer to the error code 204 (no content))
Resolution: For writeproperty there's no response payload, the return code on successful completion is 204 (No Content)
Lagally: there are just 10mins
… so would ask you all to review the remaining sections (=readallproperties, writeallproperties, readmultipleproperties, writemultipleproperties)
… to be honest, have difficulty with readmultipleproperties and writemultipleproperties
Daniel: supported by the Scripting APIs
McCool: implemented by node-wot?
Daniel: right
Ben: some proxy might cache the body
McCool: so might break interoperability
Ben: right
Lagally: if we remove readmultiplproperties and writemultipleproperties would we loose anything?
Sebastian: depending on use cases...
McCool: readproperties and writeproperties are atomic
Koster: writeallproperties seems to be odd
<McCool> +1 with using readall and writemultiple only
<mlagally> Proposal: Keep readallproperties, writemultipleproperties only, eliminate the other two operations
Kaz: "the other two" means readmultiple and writeall. right?
Lagally: yes
Ben: don't mind if remove them
Resolution: Keep readallproperties, writemultipleproperties only, eliminate the other two operations (remove 5.2.1.5 and 5.2.1.4) from the profile.
all: good
[adjourned]