- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 12 Jul 2021 17:22:36 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/05/06-wot-arch-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
– DRAFT –
WoT Architecture
06 May 2021
[2]IRC log.
[2] https://www.w3.org/2021/05/06-wot-arch-irc
Attendees
Present
Ben_Francis, Daniel_Peintner, Ege_Korkan, Kaz_Ashimura,
Michael_Koster, Michael_Lagally, Michael_McCool,
Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Lagally
Scribe
kaz
Contents
1. [3]Minutes
2. [4]Agenda
3. [5]MR 77
4. [6]Summary of action items
5. [7]Summary of resolutions
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> [8]MR 77 - New Protocol Binding section
[8] https://github.com/w3c/wot-profile/pull/77
Lagally: would like to talk with Ben
McCool: note there are several MRs
Lagally: would like to start with MR 77
[9]diff version
[9] https://pr-preview.s3.amazonaws.com/w3c/wot-profile/77/594c374...benfrancis:f70ec75.html
McCool: last week, I created a branch
Lagally: ok
Ben: hope this is the least controversial
[10]5.2 Protocol Binding
[10] https://pr-preview.s3.amazonaws.com/w3c/wot-profile/77/594c374...benfrancis:f70ec75.html#protocol-binding
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
[11]around Example 1
[11] https://pr-preview.s3.amazonaws.com/benfrancis/wot-profile/pull/77.html#example-1
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
[12]referring to JSON Data Interchange Formant - RFC8259
[12] https://datatracker.ietf.org/doc/html/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> [13]https://tools.ietf.org/html/rfc7807
[13] https://tools.ietf.org/html/rfc7807
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": "[14]https://example.com/probs/out-of-credit",
[14] https://example.com/probs/out-of-credit
"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 [15]https://tools.ietf.org/html/rfc7807
[15] https://tools.ietf.org/html/rfc7807
<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
[16]https://tools.ietf.org/html/rfc7807
[16] https://tools.ietf.org/html/rfc7807
Ben: suspect the spec (RFC7807) doesn't allow empty value
<mlagally> Proposal: Error response bodies, if they are
provided, MUST have details conforming to [17]https://
tools.ietf.org/html/rfc7807
[17] https://tools.ietf.org/html/rfc7807
Lagally: agree?
Resolution: Error response bodies, if they are provided, MUST
have details conforming to [18]https://tools.ietf.org/html/
rfc7807
[18] https://tools.ietf.org/html/rfc7807
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 [19]https://
github.com/w3c/wot-discovery/issues/167
[19] https://github.com/w3c/wot-discovery/issues/167
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> [20]https://w3c.github.io/
wot-scripting-api/#error-handling
[20] https://w3c.github.io/wot-scripting-api/#error-handling
<McCool> [21]https://github.com/w3c/wot-scripting-api/issues/
200
[21] https://github.com/w3c/wot-scripting-api/issues/200
(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> [22]https://heycam.github.io/
webidl/#idl-DOMException-error-names
[22] https://heycam.github.io/webidl/#idl-DOMException-error-names
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
[23]https://github.com/w3c/wot-scripting-api/issues/
200#issuecomment-833607756
[23] https://github.com/w3c/wot-scripting-api/issues/200#issuecomment-833607756
Ben: there is a use case
Daniel: there was an open issue on the Scripting side
<dape> [24]wot-scripting Issue 193 - Should writeProperty()
return a value
[24] https://github.com/w3c/wot-scripting-api/issues/193
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
[25]RFC7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics
and Content
[25] https://tools.ietf.org/html/rfc7231
<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]
Summary of action items
1. [26]Mccool: check the pagination response codes in the
discovery spec
2. [27]Ben: double check the list of error codes in WebThings
3. [28]Lagally: check error codes of Oracle's digital twin
implementation
4. [29]Daniel: double check node-wot's error codes, are there
error response payloads?
Summary of resolutions
1. [30]Error response bodies, if they are provided, MUST have
details conforming to https://tools.ietf.org/html/rfc7807
2. [31]For writeproperty there's no response payload, the
return code on successful completion is 204 (No Content)
3. [32]Keep readallproperties, writemultipleproperties only,
eliminate the other two operations (remove 5.2.1.5 and
5.2.1.4) from the profile.
Minutes manually created (not a transcript), formatted by
[33]scribe.perl version 131 (Sat Apr 24 15:23:43 2021 UTC).
[33] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 12 July 2021 08:22:44 UTC