- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 12 Jul 2021 17:30:45 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/05/27-wot-arch-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
– DRAFT –
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
Attendees
Present
Kaz_Ashimura, Michael_Lagally, Michael_McCool,
Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Lagally
Scribe
kaz
Contents
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
Agenda
Lagally: (goes through the agenda)
[11]Agenda
[11] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#May_27th.2C_2021
Minutes
[12]May-20
[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
… if we have strong need, we can do it
… depending on fixed UR, etc.
… need clarification
… need to probably talk with the Eclipse Volto guys as well
… the problem is that we are now holding reorganizing
discussion
Lagally: we can extend the feature later
… Sebastian, would you assume Thing Directory to store Thing
Model?
Sebastian: it's possible
McCool: yeah, it's technically possible
… 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
… note that it's hard to change for embedded cases
… we should not broadcast the detail of the device information
Lagally: ok
… the language here looks fine to me
… just wondering about this reference to "SOLID"
… what does this link specifically help our spec?
McCool: it's part of the W3C activity (as a CG)
… related to managing access control
… where does the security key come from?
… how to manage the key?
… SOLID provide insight for that
… even the WoT security need another best practice
documentation
… also informative
… WoT security guideline itself is also informative
… make sense to include the links to those documents
… 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
… 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?
(none)
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/
wot-profile/pull/77.html#actions
[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
… e.g., 20X, 40X, ...
… 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
… additional code to be added
Lagally: would like to point out a couple of possible
additional ones
… (refers to RFC7231)
[19]RFC7231
[19] https://datatracker.ietf.org/doc/html/rfc7231
Lagally: e.g., 408 timeout errors
… 414 URI Too Long
McCool: we made payload maximum limit
… profile is about limitation for consumer
Lagally: there are a couple of server errors as well (on
RFC7231)
… e.g., 504 Gateway Timeout
… let's come back to "413 Payload Too Large"
… what kind of payload can be put?
McCool: several use cases about large payload
… depends on the sensors
… we have device A and B to be connected with each other
… can accept the payload though it might be unexpected from the
receiver's viewpoint
… directory has a pagination issue to chunk the payload
Lagally: we have maximum limitation for the payload
McCool: this is about uploading
… for downloads we could maximize the chunks
… TD should document what is allowed maybe using data schema
… 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
… uploading payload on the producer side would be a good use
case
… nice way to communicate with the HTTP payload not feasible
for the producer
… might be problematic
Lagally: how to tell it?
… 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?
… possible proposal
Sebastian: any existing specs?
McCool: Kaz mentioned an example
Lagally: let's ask the TD TF for opinions
… (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)
… server decides if the request is to be rejected
… the same issue with "413 Payload Too Large"
… the question is how the client can tell
… maybe the right answer here is specifying some specific
maximum
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
complicated...
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
… 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
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
WebSockets).
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?
… we have a named object
… one possible solution might replicating the data
… all the places
… but when to do signing?
… what if we require canonical TD on the wire?
Lagally: (shows "5.2.2.1 invokeaction")
[26]5.2.2.1 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
… let's have a quick look at the changes
[27]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
… and merge the PR itself
… any concerns?
(none)
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
… 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
… which version of the markup?
… need to add <span> tags
… <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
… maybe can do that by a script, though :)
… 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
class="rfc2119-table-assertion"
id="td-vocab-security--Form"><td><code>security</code></td><td>
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
href="[32]http://www.w3.org/TR/2012/
REC-xmlschema11-2-20120405/#string"><code>string</code></a> or
<[CUT]
[32] http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#string
Lagally: so my question now to Mizushima-san :)
… do you think you can help?
McCool: would suggest we start with the sentences
… and work on tables later
Lagally: can work together
Mizushima: ok
Kaz: will see if I can generate a simple script to help that :)
… 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
AOB?
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
… can join the Chairs call in 2 weeks though can't make it next
week
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!
[adjourned]
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