Moving the core binding document into the TD

[egekorkan]

In the call of 22.02, we have discussed that it might make more sense to move the core binding templates document to the TD specification so that the binding mechanism is explained in the TD specification. The individual bindings would still be separate documents.

The TF did not have a negative opinion about any technical issues. One problem would be the length of the document but it might be resolved by moving the TM section to a separate document.

Another direction would be to say that the mapping of a TM to a TD happens via binding templates.

[benfrancis]

Should the profiling mechanism be defined inside the TD specification as well?

[egekorkan]

Should the profiling mechanism be defined inside the TD specification as well?

@benfrancis We had an internal discussion about this. This would make sense from our point but we have to fix what the profiling mechanism really means. What is currently done in the profile by specifying a new protocol or behavior (async actions) should not happen. The profiling mechanism should be that a profile can only constrain the flexibility of the TDs and not add additional mechanisms that cannot be described in a TD. We are aware of the current lacking expressiveness of TDs and the 2.0 version should fix those.

@mlagally what do you think?

[benfrancis]

@egekorkan wrote:

we have to fix what the profiling mechanism really means. What is currently done in the profile by specifying a new protocol or behavior (async actions) should not happen. The profiling mechanism should be that a profile can only constrain the flexibility of the TDs and not add additional mechanisms that cannot be described in a TD.

I agree with this in principle, and this is essentially what I've proposed for the new charter, "Bindings 2.0" and "Profiles 2.0". Ideally all a profile would do is prescribe a particular choice or choices for each area of a TD where multiple implementation options are available, i.e:

• Protocol binding
• Payload binding
• Security mechanisms
• Discovery mechanisms
• Link relations
• Context extensions

The prescriptive details currently provided in the protocol binding sections of profiles could be merged into binding documents as defaults, which profiles would then reference and require to be observed.

We are aware of the current lacking expressiveness of TDs and the 2.0 version should fix those.

In practice I am skeptical that it will ever be possible to describe every detail of every operation in every protocol declaratively in a static Thing Description (dynamic resources in an action queue and mutual authentication of Webhooks are good examples), and if it was possible then Thing Descriptions would be so complicated that it would be effectively impossible to implement a general purpose Consumer which can understand them all. This is why in reality I believe that some default assumptions will always be needed in order to guarantee interoperability, whether they are defined in a binding document or a profile.

I would also be interested in @mlagally's feedback on w3c/wot-profile#285 (comment)

---

FWIW I don't mind whether the profiling mechanism is defined in the Thing Description specification or the Profile specification, but the binding and profiling mechanisms are kind of two sides of the same coin so if the former is defined in the Thing Description specification then the latter probably should as well.

[mlagally]

Triggered by a conversation in today's Profile call, a few comments:

There's a border between protocol and payload formats, where the term "subprotocol" is rather confusing the discussion:

• Is a thing that provides error responses in a specific JSON format implementing a "subprotocol"? Does that require a dedicated binding template?
• Is an asynchronous action response in a well defined structure a dedicated "subprotocol"
• Is a set of constraints on the response codes of HTTP requests a dedicated "subprotocol"?

Can these "subprotocols" be combined into a new subprotocol?
If we follow this approach, we are fragmenting the problem space and sacrifice interoperability.

[egekorkan]

TD Call of 01.03:

• TF has reached a consensus that the binding and profiling mechanisms will go into the TD spec. Thus, there will be no "Web of Things (WoT) Binding Templates" document and registry sections (if needed) will be in the TD spec. The management of the registry can be a separate note.
• Individual bindings and profiles will separate documents (notes) BUT both mechanisms should be clear for the reader (when to use which one). This will be discussed separately later on.
• Repositories can stay the same for the individual bindings and profiles.
• Regarding the length, please see TD and TM restructuring #33 (comment) .
• Prefixes should be managed as well. (we can look into how DID WG does this)

[egekorkan]

@mlagally just to give my own answer to your question.

We need some work to define what a subprotocol really is. We did some work on binding templates at above the example of https://w3c.github.io/wot-binding-templates/#example-subprotocol-usage-for-subscribing-events

My most atomic definition is that a subprotocol is a combination of messages that are not a single protocol message or message pair.

Leaving websockets aside, the subprotocols like longpoll, coap observe and sse imply further semantics than just sending a single request and getting a response, there is a "resource management" happening. In websockets, only the fact that "a message is sent from A to B" is defined in the protocol. Thus, anything that happens on top becomes a subprotocol by default. In the case of async actions in the HTTP baseline profile, given that the resource created as a result of the action invocation needs to be managed by the consumer, it creates a subprotocol. It is not about the message format or payload type.

Maybe we should say that each protocol in the level above (in OSI layers) is a subprotocol of the protocol below but that goes a little too philosophical.

Regarding your questions, my answer is no to all of them except "Does that require a dedicated binding template?" raises some questions on the fact that we have not put error responses in the current binding documents.