Meeting minutes
Agenda
Lagally: (goes through the agenda)
Minutes
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
PR 588 - Add Discovery refs, dfn, and section
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
8.4 Discovery within the diff
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
(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
PR 77 - New Protocol Binding section
<mlagally> https://
Lagally: checked the Oracle's error codes as well
McCool: there was error code definition within TD spec as well
<mlagally> Oracle Cloud's error code
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)
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
wot-thing-description Issue 1153 - max length payload metdata information
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)
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
Lagally: 426 is interesting
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)
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")
[[
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
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.
Lagally: (merges PR 77)
Profile issues
Lagally: (goes through the remaining issues)
Issue 76
Issue 76 - Markup of normative requirements (RFC 2119)
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>
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 ;)
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="http://
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
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]