– DRAFT –
WoT-WG - TD-TF - Slot 1

Logistics

Ege: regrets from Cristiano
… can't make tomorrow's meeting
… but Koster will moderate the discussion on TD use cases
… McCool also will join

Minutes

Oct-17

Ege: already reviewed yesterday
… (goes through the minutes)
… don't see any issues

(approved)

Initial Connection

PR 2040

PR 2040 - Initial/Common Connection Container Proposal

Ege: need discussion on the terminology
… also some concerns from myself and Luca
… (shows the changes)
… (specifically, the "basichttp2" section within the example TD)

Luca: there is no additional logic
… computationally, my proposal would not add anything

Luca's comment on GitHub:
* op can be left unset as any other field, but a TD can have it set if
  most of its affordances have the same op.
* The problem with circular references has to be tackled already because
  of ComboSecurityScheme so there is no additional logic needed, just has
  to be applied to one more item.

Luca: if the field is missing, local default to be applied

Ege: but we need to be careful about possible special cases
… basically need to define those values
… if you have two bases, one for read and another for write...

Luca: you want to have a set of values
… you need an actual base for write or read
… I'm not seeing big problems with this direction

Ege: think the mistake is already existing
… so ok with this direction

Kaz: in that case, we need further clarification within the spec text?

Ege: we can go this direction and document what kind of combination to be avoided

Kaz: using some even clearer text?

Ege: right
… I just have one thing to mention
… talked with Matthias before this call
… about [[ "reusable": false ]]
… can be deduced from binding

Luca: one problem is
… all the protocols we support
… the usability can be confirmed by the server side
… if not enough resource, can be disconnected
… we'd like the consumer to play nicely
… could have some hint for that purpose
… none of the underlying transport has this problem
… none of the two sides, client and server
… if you use TCP, we can tell it's to be closed
… we'd like to have a situation the consumer can keep the connection open
… like WebSocket
… but it's up to the consumer
… if you want to support for persistent connection like that, it's protocol-specific
… it's not something we deal with the TD spec itself
… we can make room for that direction as hint
… can be completely ignored
… client can open as many connections as possible at once
… but the server needs to handle that

Ege: ok
… more than what the TD spec to handle

mjk: small question
… more than one "op"
… is that just an array?
… can I do that?

Luca: this is something to be handled orthogonally
… we discussed hat one year ago
… JSON doesn't work well with arrays for data preservation

Ege: arrays are already used for "@context", etc....

Luca: if that's the case, array might be a possible solution

Ege: (updates the GitHub comments)

<EgeKorkan> w3c/wot-thing-description#2040 (comment)

Ege: another point is

<luca_barbato> Looked up https://www.rfc-editor.org/rfc/rfc7159.html, arrays are sorted indeed

Ege: regarding form defaults

<EgeKorkan> https://spec.openapis.org/oas/v3.1.0.html#components-object

Ege: (refers to the OpenAPI spec v3.1.0)
… (specifically, "4.8.7 Components Object" section)
… would show some example

Daniel: could we do both?
… or just one like OpenAPI?

Ege: like the Components Object from OpenAPI
… pack everything so that we can reuse them

Luca: beautiful part of that is accepting the same term

Ege: (add some example to "usability-and-design.md")

usability-and-design.md

Luca: "security" appears at different places in the example
… should be "securityDefinitions" and "security"

Ege: (fixes the example)
… (also adds a subsection of "additionalResponse")

Kaz: a bit confused
… what we're doing now is (1) borrowing some ideas from OpenAPI or (2) better compatibility with OpenAPI?

Ege: the former now

Kaz: think we should think about the latter too

Daniel: it's clear now
… it's grouping of several "connectionDefinitions" entries

( basichttp1, basichttp2 and broker)

Ege: now would like to discuss the content

Kaz: we need to clarify the processing algorithm
… e.g., commonDefinitions will be overridden by each definition specified later

Ege: yeah
… (updates the GitHub comments)
… should "security" in the root lever be conserved
… but how do we handle "inline security" improvements that were collected by Jan?
… the names of the new terms should be also discussed, e.g., "commonDefinitions"

updated comments

Ege: would have a resolution about this next week

[adjourned]