Re: WoT Profiles 2.0 - Strawman Proposal

Hi Ben,

Thanks for the strawman proposal. I have some overall comments below but is it possible that you join one of the next TD or Binding calls where you present this?

My comments:

  *   Since there is no good way to describe meta operations, it is not possible have a default as the non-default is not clear. This is not an issue of your proposal though.
  *   Invokeaction with ActionStatus object needs definitely more thinking since anything we have in this document should be describable in a TD anyways.

Best,
Ege

From: Ben Francis <ben@krellian.com>
Date: Thursday, 1. February 2024 at 15:46
To: Public Web of Things WG <public-wot-wg@w3.org>
Subject: WoT Profiles 2.0 - Strawman Proposal
Hi,

There have been lots of discussions in the past around how Profiles<https://w3c.github.io/wot-profile/> and Binding Templates<https://w3c.github.io/wot-binding-templates> should work together, since in their current form they essentially provide two different (and in some ways conflicting) mechanisms for defining protocol bindings.

Recently there seems to be a tentative agreement around the idea that the current protocol binding sections of Profiles could be merged into Protocol Binding Template documents, as defaults. Profiles could then simply reference protocol binding documents, but mandate that the defaults are used by conformant Web Things.

In order to explore this idea further I have created two strawman proposal documents:

  *   Web of Things (WoT) HTTP Protocol Binding 2.0<https://docs.google.com/document/d/1msgUZSrniTrgVieU2i_V2804gqvVsHrYByTv-OET1l8/edit?usp=sharing>
  *   Web of Things (WoT) HTTP Basic Profile 2.0<https://docs.google.com/document/d/1LjBWiqQZXi85gXP2NNckQni5os6dwxW6UDGrZDb3cns/edit?usp=sharing>
The HTTP Protocol Binding 2.0 document specifies both a vocabulary for describing a custom HTTP protocol binding in a Thing Description, and a default protocol binding which can be assumed by Consumers for a subset of operations if a custom protocol binding is not specified. (This results in better interoperability by default, since all Consumers would be required to implement the defaults).

The HTTP Basic Profile 2.0 document then takes a simpler approach to defining a profile, by just referencing the protocol binding document. A profile would essentially just constrain Web Things to a finite set of options for each extension point in the Thing Description specification (specifically: protocol bindings, payload bindings, security mechanisms, discovery mechanisms, link relation types and semantic contexts).

In order to guarantee out-of-the-box interoperability between conformant Web Things and Consumers, The HTTP Basic Profile 2.0 basically says that Web Things:

  *   Must use the HTTP Protocol Binding 2.0, and must stick to its defaults
  *   Must use the JSON payload binding
  *   Must implement at least one of a finite set of security mechanisms
  *   Must implement at least one of a finite set of discovery mechanisms
  *   Are recommended to limit themselves to a finite set of link relation types
  *   Are recommended to limit themselves to a finite set of semantic contexts
It then says that Consumers:

  *   Must support the HTTP Protocol Binding 2.0, at least where defaults are used
  *   Must support the JSON payload binding
  *   Must support a minimum set of security mechanisms
  *   Must support a minimum set of discovery mechanisms
  *   Should support a minimum set of link relation types
  *   Should support a minimum set of semantic contexts
Because normative specifications can not depend on non-normative specifications, if Protocol Binding documents are to be non-normative then it seems Profiles would have to become non-normative too.

One approach to this could be to have a registry of profiles (either in the Thing Description document as has been proposed for bindings, or in a separate WoT Profiles specification), with each individual profile being a non-normative W3C Note. The only normative part of Profiles would then be the definition of the profiling mechanism itself, which could also live in the Thing Description specification<https://github.com/w3c/wot-profile/issues/372>, or a separate WoT Profiles specification.

Note that the HTTP Basic Profile 2.0 strawman proposal does not currently include the HTTP SSE<https://w3c.github.io/wot-profile/#sec-http-sse-profile> and HTTP Webhook<https://w3c.github.io/wot-profile/#sec-http-webhook-profile> profiles for observing properties and subscribing to events. I would suggest those profiles could potentially live in separate documents and rely on separate SSE and Webhook protocol binding documents respectively.

I would be very interested to receive your feedback on these proposals, either on this mailing list, inline in the documents, or in the issues in the respective repositories:

  *   Profile Mechanism 2.0<https://github.com/w3c/wot-profile/issues/285>
  *   Consider merging Profile protocol bindings into Protocol Binding and Payload Binding documents<https://github.com/w3c/wot-binding-templates/issues/248>
Regards

Ben

P.S. I would very much like to put myself forward as a new Task Force Lead for the WoT Profiles Task Force in order to work on this, but I currently don't have a source of funding to support me in doing that. If you are interested in the profiles and/or protocol binding topics and your organisation may be interested in sponsoring that work, I would be delighted if you could get in touch with me.

--
Ben Francis
Founder
Krellian Ltd.<https://krellian.com/>

[https://ci3.googleusercontent.com/mail-sig/AIorK4wfiJ2np5TI1zG1_XIDs6GAVLZdmVRIZ5cvhbFWGfhDwAfeoMHB2oX2S6lVCq1LxGW45WPDdWg]