W3C home > Mailing lists > Public > public-wot-wg@w3.org > July 2021

[wot-architecture] minutes - 6 May 2021

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 12 Jul 2021 17:22:36 +0900
Message-ID: <87eec42b77.wl-ashimura@w3.org>
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/


                             íV DRAFT íV
                            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
   íK 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
   íK less controversial operation
   íK some comments from McCool
   íK (goes through the diff)
   íK 2 open issues there
   íK e.g., the body of GET request
   íK couple of suggestions there

   McCool: a few comments here
   íK reasonable approach to me
   íK focus on HTTP
   íK regarding the body of GET request issue
   íK server must ignore and the client may do it but not
   recommended

   Lagally: should we see the proposal at a higher level first?
   íK 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
   íK may possibly mention it in that security section

   Lagally: security section to be discussed separately
   íK (goes through the description around Example 1)
   íK any constraint on upper case vs lower case?

   Ben: we have key-value pair
   íK based on the valid JSON specification

   Sebastian: +1
   íK 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
   íK specific sub protocol specified
   íK or not

   McCool: you could have JSON Object
   íK including time information like time stamp

   Ben: once we get how Actions work

   McCool: if we have GET on property
   íK 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
   íK if done, elsewhere

   Lagally: whether we allow all the possible subsets or not
   íK is my question
   íK let's look into the description
   íK (below Example 2)
   íK "E.g." right before the error codes
   íK 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
   íK if we want to define some specific meanings, we should define
   them here

   Lagally: we don't need a complete list here
   íK but could just add a table and reference to the HTTP spec

   McCool: working on a PR
   íK noticed some string to be included in the response
   íK 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
   íK 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)
   íK 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
   íK 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 :)
   íK depends on the protocol you use
   íK 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
   íK Scripting API is protocol-dependent
   íK 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
   íK (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
   íK this is more generic

   McCool: if we have an abstract class of errors, that's fine
   íK maybe could be documented here
   íK 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
   íK 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)
   íK 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
   íK 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
   íK 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
   íK 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
   íK 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
   íK not sure they used HTTP and need to look into the detail

   Ben: could be a problem
   íK 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
   íK 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
   íK so would ask you all to review the remaining sections
   (=readallproperties, writeallproperties,
   readmultipleproperties, writemultipleproperties)
   íK 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

This archive was generated by hypermail 2.4.0 : Monday, 12 July 2021 08:22:46 UTC