Protocol Bindings Option 1 - Default protocol bindings in binding documents

[benfrancis]

Note: This PR only changes the details document, please add the "Detailed Work Items" label.

This is one of two proposed solutions to the conflict between the binding and profiling mechanisms identified in #14.

In this proposal the binding and profiling mechanisms work together so that there is only one mechanism for defining protocol bindings in WoT. The current prescriptive protocol binding specifications in profiles would be turned into default protocol bindings in protocol and payload binding documents (as proposed in w3c/wot-binding-templates#248). Profiles would then reference and depend upon the default bindings in the binding documents, rather than specify a protocol binding in the profile itself. This is the "profiling mechanism 2.0" approach proposed in w3c/wot-profile#285 (comment).

This PR also adds deliverables for SSE and Webhook protocol bindings, which would be used by SSE and Webhook profiles respectively.

With this change, it would be OK to call the binding documents "protocol bindings" because they do actually define a default protocol binding, in addition to the vocabulary for describing custom protocol bindings in Thing Descriptions.

This would be a big change for WoT Consumers, because all Consumers which implement a given protocol binding would be required to support the default protocol binding defined in that document. But the benefits of that are:

1. More interoperability by default, since all Things can rely on Consumers supporting a wider set of defaults
2. Consumers which only care about Things conforming to a particular profile only have to implement the default protocol binding, which is far less complex than supporting any custom protocol binding using the protocol binding vocabulary

[egekorkan]

I think I prefer this over the option 2. We need to evaluate this but I do not see a big problem at the moment. One important note:

This would be a big change for WoT Consumers, because all Consumers which implement a given protocol binding would be required to support the default protocol binding defined in that document.

This is actually not true. This is already the case that the Consumers need to be capable of filling in the missing terms or values if they have a default value. This would just extend the current mechanism a bit to their behavior, i.e. if the input of an action is wrong, reply with error code X.

[egekorkan]

TD Call 22.03:

• Possibly long discussion, we have added the corresponding label.
• We need more discussion on what it means to specify the defaults.
• This discussion can be moved to another repository (possibly https://github.com/w3c/wot)

[benfrancis]

This discussion can be moved to another repository (possibly https://github.com/w3c/wot)

Thank you for the response, but this PR (or #93) is intended to fix problems with the text of the details document which is linked from the charter and currently resides in this repository. I'm not sure how to move these PRs to another repository without also moving that document.

I agree the relationship between the profile and binding mechanisms is a big (and important) discussion and I have already filed issues in the Profile (w3c/wot-profile#285) and Binding Templates (w3c/wot-binding-templates#248) repositories. Should I file an issue in the wot repository as well?

What is a good next step to move this discussion along? I would be willing to attend a one-off combined profile/binding meeting to discuss this topic when the time is right, if that's what's necessary?

In the meantime I would welcome more feedback on the above issues.

[sebastiankb]

from today's planning discussion:

• we will merge both options 1 & 2 and we will re-discuss this in the Binding TF since we need to make decision how to organize the Binding topic in the new charter
• @benfrancis can you resolve the conflicts?

[k-toumura]

Since the PRs for options 1 and 2 are themselves conflicted, it would be difficult to merge them both.

How about doing one of the following?

• Leave the PRs as open and continue the discussion in the (one of the PR's) comments section.
• Close the two PRs and create a new PR with these two options, merge them, and continue discussion in a newly created Issue.

If the difficulty in viewing the differences between PRs in HTML documents makes it difficult to discuss PRs comments section, writing documents in Markdown may be an option.

[sebastiankb]

propose to close this PR as the new working group has been published

[benfrancis]

If the content of the details document is now considered final then I agree that these two PRs no longer serve a purpose, but the issue described in #14 still remains.

Conflicting meanings of the term "protocol binding" are still in active use and it's important that the term is properly defined, as well as how profiles and protocol binding templates should work together. That discussion can probably continue in w3c/wot-profile#285 and w3c/wot-binding-templates#248.

FWIW as I understand it the tentative consensus seems to be that the current "protocol binding" sections from profiles could be merged into binding template documents as defaults, to create new "Protocol Binding" and "Payload Binding" documents. This could also then simplify profiles.

I would like to contribute to this work if possible.

[egekorkan]

@benfrancis wrote:

FWIW as I understand it the tentative consensus seems to be that the current "protocol binding" sections from profiles could be merged into binding template documents as defaults, to create new "Protocol Binding" and "Payload Binding" documents.

This is correct (tentative consensus though!). This is something to discuss in the TD/Binding calls but we are not there yet (soon though!). There are two important things:

• For some mechanism to be a default, it should be still describable in a TD. Or the lack of that mechanism should be describable at least (not sure about it entirely)
• The tendency is to go with a W3C registry table within the TD document that lists the different bindings. You cannot make normative references to a registry entry. This means that a REC document (like Profile X) cannot say that conformant Things and Consumers of this profile MUST implement the defaults written in Binding 1 in TD registry Z.

[benfrancis]

@egekorkan wrote:

For some mechanism to be a default, it should be still describable in a TD. Or the lack of that mechanism should be describable at least (not sure about it entirely)

I agree that ideally there shouldn't be a default defined in a protocol binding template unless there's also a mechanism to override that default. In practice that might mean that if we try to use this approach with the current set of profiles, they could not be published until TD 2.0 is published - assuming that TD 2.0 can fully describe every little detail specified by the current protocol bindings defined in profiles.

The tendency is to go with a W3C registry table within the TD document that lists the different bindings. You cannot make normative references to a registry entry. This means that a REC document (like Profile X) cannot say that conformant Things and Consumers of this profile MUST implement the defaults written in Binding 1 in TD registry Z.

Perhaps this means that Profiles should also take the registry approach after all, with each profile being a separate non-normative note which can then rely on the non-normative protocol binding notes.