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

[wot-architecture] minutes - 27 May 2021

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 12 Jul 2021 17:30:45 +0900
Message-ID: <87bl782atm.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.




      [1] https://www.w3.org/

                             íV DRAFT íV
                            Wot Architecture

27 May 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#May_27th.2C_2021

      [3] https://www.w3.org/2021/05/27-wot-arch-irc


          Kaz_Ashimura, Michael_Lagally, Michael_McCool,
          Sebastian_Kaebisch, Tomoaki_Mizushima





    1. [4]Agenda
    2. [5]Minutes
    3. [6]PR 588
    4. [7]WoT Profile PR 77
    5. [8]Profile issues
         1. [9]Issue 76
    6. [10]AOB?

Meeting minutes


   Lagally: (goes through the agenda)


     [11] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#May_27th.2C_2021



     [12] https://www.w3.org/2021/05/20-wot-arch-minutes.html

   Lagally: (goes through the minutes)

   <McCool> kaz, you are breaking up

   (Kaz fixed the style of Lagally's mentioned three actions
   (McCool, Ben and Daniel))

   (minutes approved)

  PR 588

   [13]PR 588 - Add Discovery refs, dfn, and section

     [13] https://github.com/w3c/wot-architecture/pull/588

   McCool: need clear use cases
   íK if we have strong need, we can do it
   íK depending on fixed UR, etc.
   íK need clarification
   íK need to probably talk with the Eclipse Volto guys as well
   íK the problem is that we are now holding reorganizing

   Lagally: we can extend the feature later
   íK Sebastian, would you assume Thing Directory to store Thing

   Sebastian: it's possible

   McCool: yeah, it's technically possible
   íK Thing Model is also a JSON-based file

   [14]8.4 Discovery within the diff

     [14] https://pr-preview.s3.amazonaws.com/w3c/wot-architecture/588/cdb883d...mmccool:31bf57b.html#discovery

   Lagally: (goes through the diff)

   McCool: the 2-phase approach should be not part of the
   architecture but rather part of the concept
   íK note that it's hard to change for embedded cases
   íK we should not broadcast the detail of the device information

   Lagally: ok
   íK the language here looks fine to me
   íK just wondering about this reference to "SOLID"
   íK what does this link specifically help our spec?

   McCool: it's part of the W3C activity (as a CG)
   íK related to managing access control
   íK where does the security key come from?
   íK how to manage the key?
   íK SOLID provide insight for that
   íK even the WoT security need another best practice
   íK also informative
   íK WoT security guideline itself is also informative
   íK make sense to include the links to those documents
   íK should show what the best practices are

   Lagally: reference to the CG report by the Solid CG

   [15]Solid Technical Reports

     [15] https://solidproject.org/TR/

   (The "Solid Technical Reports" is a list of documents related
   to the Solid project.)

   Kaz: think we should consult with PLH and Ralph about how to
   deal with these resources

   Lagally: ok
   íK McCool, could you generate yet another PR to cite the actual
   Editor's Draft documents for Solid resources?

   McCool: will do

   Lagally: any other comments?


   Lagally: so would suggest we merge this PR itself, and McCool
   will create another PR for the detail

   Kaz: note that we should talk with PLH and Ralph about how to
   cite the information before our CR transition :)

  WoT Profile PR 77

   [16]PR 77 - New Protocol Binding section

     [16] https://github.com/w3c/wot-profile/pull/77

   <mlagally> [17]https://pr-preview.s3.amazonaws.com/benfrancis/


     [17] https://pr-preview.s3.amazonaws.com/benfrancis/wot-profile/pull/77.html#actions

   Lagally: checked the Oracle's error codes as well

   McCool: there was error code definition within TD spec as well

   <mlagally> [18]Oracle Cloud's error code

     [18] https://docs.oracle.com/en/cloud/paas/iot-cloud/iotrq/StatusCodes.html

   Lagally: need to check it

   McCool: we need a short summary of the error range as well
   íK e.g., 20X, 40X, ...
   íK list of the error codes

   <McCool> summary: 200-202, 204, 400-401, 403-406, 408-409, 415,
   500, 503

   McCool: range of the error codes above

   Lagally: ok

   McCool: we could allow 402 for a profile
   íK additional code to be added

   Lagally: would like to point out a couple of possible
   additional ones
   íK (refers to RFC7231)


     [19] https://datatracker.ietf.org/doc/html/rfc7231

   Lagally: e.g., 408 timeout errors
   íK 414 URI Too Long

   McCool: we made payload maximum limit
   íK profile is about limitation for consumer

   Lagally: there are a couple of server errors as well (on
   íK e.g., 504 Gateway Timeout
   íK let's come back to "413 Payload Too Large"
   íK what kind of payload can be put?

   McCool: several use cases about large payload
   íK depends on the sensors
   íK we have device A and B to be connected with each other
   íK can accept the payload though it might be unexpected from the
   receiver's viewpoint
   íK directory has a pagination issue to chunk the payload

   Lagally: we have maximum limitation for the payload

   McCool: this is about uploading
   íK for downloads we could maximize the chunks
   íK TD should document what is allowed maybe using data schema
   íK setting a limit for upload would not be appropriate

   Lagally: we should consider this kind of error "413 Payload Too
   Large" to make sure

   McCool: yeah

   Sebastian: have the power to tell what he can/can't expect
   íK uploading payload on the producer side would be a good use
   íK nice way to communicate with the HTTP payload not feasible
   for the producer
   íK might be problematic

   Lagally: how to tell it?
   íK where the attempt to be done?

   Sebastian: how to know the maximum size?

   McCool: how big is the data, e.g., an image?

   Kaz: if needed, maybe we could add an additional interface to
   tell the maximum size before sending the actual payload (like
   the W3C API)

   McCool: adding a field to specify the maximum size?
   íK possible proposal

   Sebastian: any existing specs?

   McCool: Kaz mentioned an example

   Lagally: let's ask the TD TF for opinions
   íK (creates a new issue for wot-thing-description)

   McCool: btw, any resource about the W3C API?

   Kaz: not a REC but there is a document

   [20]W3C API Overview

     [20] https://w3c.github.io/w3c-api/

   [21]wot-thing-description Issue 1153 - max length payload
   metdata information

     [21] https://github.com/w3c/wot-thing-description/issues/1153

   McCool: basically the spec should know about the spec
   (including the error codes)
   íK server decides if the request is to be rejected
   íK the same issue with "413 Payload Too Large"
   íK the question is how the client can tell
   íK maybe the right answer here is specifying some specific

   Lagally: (adds comments to Issue 1153)

   [22]updated issue 1153

     [22] https://github.com/w3c/wot-thing-description/issues/1153#issue-903889991

   McCool: for "413 Payload Too Large", maybe could send a
   lower-resolution image, etc.

   Lagally: for easier implementation, no retry and just return a
   fatal error

   (RFC7231 mentions "If the condition is temporary, the server
   SHOULD generate a Retry-After header field to indicate that it
   is temporary and after what time the client MAY try again.)

   McCool: some succeed and some don't

   Lagally: so the implementations potentially gets more

   McCool: the decision to be made by the implementers

   Lagally: the bottom line is permitting all of the error codes
   defined by RFC7231?

   McCool: "unauthorized" within 403

   Lagally: there is an overview of the status codes

   [23]6.1. Overview of Status Codes

     [23] https://datatracker.ietf.org/doc/html/rfc7231#section-6.1

   Lagally: 426 is interesting

   [24]6.5.15. 426 Upgrade Required

     [24] https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.15

   McCool: we can't force upgrade...

   Lagally: we should explain why we don't accept upgrades

   McCool: maybe we should avoid the other undefined error codes
   íK ah, "5xx" just means a category for 500, etc.

   Lagally: (shows the section "5.2.4 Error Responses" from the
   preview of PR 77 again)

   [25]5.2.4 Error Responses

     [25] https://pr-preview.s3.amazonaws.com/benfrancis/wot-profile/pull/77.html#error-responses

   Lagally: on "5.2.3 Events", we have an Editor's Note



   Other operations under consideration include subscribeevent,
   unsubscribeevent, subscribeallevents, unsubscribeallevents,
   readpastevents and readallpastevents.

   subscribeevent, unsubscribeevent, subscribeallevents and
   unsubscribeallevents would require consensus on a default event
   subscription mechanism for HTTP (e.g. Server Sent Events or

   subscribeallevents and unsubscribeallevents do not yet exist in
   the WoT Thing Description specification (see #1082 ).

   readpastevents and readallpastevents do not yet exist in the
   WoT Thing Description specification (see #892 ).


   McCool: when do you want to create a canonical TD?
   íK we have a named object
   íK one possible solution might replicating the data
   íK all the places
   íK but when to do signing?
   íK what if we require canonical TD on the wire?

   Lagally: (shows " invokeaction")

   [26] invokeaction

     [26] https://pr-preview.s3.amazonaws.com/benfrancis/wot-profile/pull/77.html#invokeaction


   The URL of an Action resource to be used when invoking an
   action MUST be obtained from a Canonical TD by locating a Form
   inside the corresponding ActionAffordance for which the value
   of its op member is invokeaction and the URI scheme [RFC3986]
   of the value of its href member is http or https.


   Lagally: still missing how to handle Actions
   íK let's have a quick look at the changes


     [27] https://github.com/w3c/wot-profile/pull/77/files

   McCool: still wondering about how to handle the canonical TD

   Lagally: let's create an issue then
   íK and merge the PR itself
   íK any concerns?


   Lagally: (adds some comments before merging it)

   <McCool> and to clarify my comments above, recent work on
   canonical TDs might end up making them quite verbose and
   inappropriate to force people to use "on the wire". So we
   should at least discuss this.

   [28]McCool's comments

     [28] https://github.com/w3c/wot-profile/pull/77#issuecomment-849734965

   Lagally: (merges PR 77)

  Profile issues

   Lagally: (goes through the remaining issues)

    Issue 76

   [29]Issue 76 - Markup of normative requirements (RFC 2119)

     [29] https://github.com/w3c/wot-profile/issues/76

   McCool: can go through the spec for this
   íK related to the tooling for the Testfest

   Lagally: wondering about if Mizushima-san also could help

   McCool: one the questions is what markup to be used
   íK which version of the markup?
   íK need to add <span> tags
   íK <span class="rfc2119-assertion">...</span>

   Lagally: (adds some comments to the issue)

   <McCool> example from the TD spec:<span
   class="rfc2119-assertion" id="td-security-activation"> The
   value assigned to <code>security</code> in an instance of
   <a>Class</a> <code>Thing</code> MUST be serialized as JSON
   string or as JSON array whose elements are JSON strings.</span>

   [30]Lagally's comment

     [30] https://github.com/w3c/wot-profile/issues/76#issuecomment-849741054

   Lagally: Mizushima-san, can you help?

   Kaz: what is expected here is adding "<span
   class="rfc2119-assertion"> tag to the sentences which include
   the RFC2119 keywords, MUST, SHOULD and MAY
   íK maybe can do that by a script, though :)
   íK the question is what kind of ID to be used for each sentence

   McCool: any kind of ID is OK (if it's unique)

   <McCool> (I wanted to comment but it seems my audio is messed
   up - it's my turn, I guess)

   Lagally: let's look at the WoT Profile Editor's Draft itself

   <McCool> (anyway, I think it is easiest to do this by hand. In
   theory you could use a script BUT the whole point of the markup
   is to make it easier for a script to extract these things ;)

   [31]WoT Profile ED

     [31] https://w3c.github.io/wot-profile/

   McCool: btw, regarding the tables, we can simply say "what is
   described by the following table MUST be done" or something
   like that

   <McCool> another example for tables:<tr
   Set of security definition names, chosen from those defined in
   <code>securityDefinitions</code>. These must all be satisfied
   for access to resources.</td><td>optional</td><td><a

   REC-xmlschema11-2-20120405/#string"><code>string</code></a> or

     [32] http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#string

   Lagally: so my question now to Mizushima-san :)
   íK do you think you can help?

   McCool: would suggest we start with the sentences
   íK and work on tables later

   Lagally: can work together

   Mizushima: ok

   Kaz: will see if I can generate a simple script to help that :)
   íK and let you know about the result by Monday

   Lagally: ok

   [33]Lagally's comments to Issue 76

     [33] https://github.com/w3c/wot-profile/issues/76#issuecomment-849741054


   Lagally: any other business for today?

   Sebastian: wondering about the time schedule

   McCool: the other issue is that our Testfest is coming shortly

   Lagally: why don't we have an Editor's call?

   McCool: can have discussion during the Chairs call next
   Wednesday on June 2

   Lagally: ok
   íK can join the Chairs call in 2 weeks though can't make it next

   McCool: should I chair the call next Thursday?

   Lagally: let's cancel the call next Thursday

   Sebastian: on the other hand, would be appreciated if you
   (McCool) could moderate the TD call next Wednesday, June 2

   McCool: can do

   Sebastian: tx!


    Minutes manually created (not a transcript), formatted by
    [34]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

     [34] https://w3c.github.io/scribe2/scribedoc.html

Received on Monday, 12 July 2021 08:30:51 UTC

This archive was generated by hypermail 2.4.0 : Monday, 12 July 2021 08:30:53 UTC