What to do with WoT Profiles 1.0

I read the meeting minutes of the WoT Profile meeting on 2024-04-23
<https://www.w3.org/2024/04/23-wot-profile-minutes.html> and I see more
discussion about how to unblock WoT Profiles 1.0, but so far no formal
resolution. Much of the conversation is focused on protocol bindings for
asynchronous actions, but I think this is just one example of the
underlying question which needs to be answered (by the wider Working Group)
in order to proceed. Namely:

*Should profile specifications in WoT Profiles 1.0 be allowed to define
protocol bindings and payload bindings which go beyond what is currently
possible to define in a Thing Description using binding templates?*

What we have discovered through implementation experience is that there are
some operations defined in the Thing Description specification (queryaction
and cancelaction being obvious but not the only examples), for which common
approaches to implementation can not be unambiguously described using the
current binding template mechanism alone.

One significant underlying issue is the lack of a way to unambiguously
describe dynamic resources when using the HTTP protocol, but there
countless other details like:

   - How to describe the payload format for meta operations like
   writeallproperties, writemultipleproperties, observeallproperties,
   unubserveallproperties, subscribeallevents, unsubscribeallevents and
   queryallactions (see
   https://github.com/w3c/wot-thing-description/issues/1665)
   - How to describe which fields in a Server-Sent Event message correspond
   to the event name, event data (as described in the data schema) and event ID
   - Which content-type to use for Server-Sent Events (see
   https://github.com/w3c/wot-binding-templates/issues/347)
   - How to describe dynamic Webhook subscription endpoint URLs which are
   served by a Consumer rather than a Thing
   - How to describe an event payload format for a Webhook which wraps
   around the actual event data described by a data schema
   - Other ambiguities around the mapping of event data schemas (see
   https://github.com/w3c/wot-thing-description/issues/817) and
   subscription IDs (see
   https://github.com/w3c/wot-thing-description/issues/887)

In WoT Profiles 1.0 we currently work around a lot of these ambiguities by
simply describing the expected behaviour in assertions in the "protocol
binding" sections of profiles. Some people are uncomfortable with this
approach because they think that profiles should only constrain a "subset"
of what is possible to describe in a Thing Description using a binding
template, and not go beyond that. This is because if a Consumer which
doesn't implement a given profile comes across a Thing which depends upon
it, the Consumer may not be able to fully interoperate with that Thing (I
would argue that would be the case regardless, and is the reason profiles
are needed in the first place).

Essentially we have ended up with two separate mechanisms for describing
protocol bindings (profiles and binding templates) which work well for
different use cases (greenfield and brownfield implementations
respectively), but which don't always work well together and sometimes may
even conflict with each other. I have a detailed proposal (
https://lists.w3.org/Archives/Public/public-wot-wg/2024Feb/0000.html) for
how to fix this conflict in WoT 2.0, but in the meantime we need to decide
what to do about the WoT Profiles 1.0 specification, which depends on the
WoT Thing Description 1.1 specification that can no longer be changed.

It has been suggested that we could simply remove the problematic features
(e.g. asynchronous actions) from the Profiles specification, and then
proceed towards a Recommendation. However, my concern with that approach is
that the issues are more wide ranging than people realise (see the examples
above), and that if we pursue it through to its natural conclusion we will
end up with a shell of a specification which is probably not worth
publishing (since it will not add much to what's already specified as
defaults in the TD specification).

I therefore think there are two realistic options (see
https://github.com/w3c/wot-profile/issues/401):

*Option 1*

Agree as a Working Group that for Profiles 1.0 profile specifications are
allowed to define protocol bindings that go beyond what can currently be
described with binding templates, as a more prescriptive but unambiguous
option to guarantee interoperability between greenfield implementations.
Publish a Candidate Recommendation, publicise a request for
implementations, and if there are sufficient implementations then proceed
to Proposed Recommendation.

*Option 2*

Decide now that profiles must only constrain what is already possible with
binding templates in TD 1.1, discontinue the approach taken in WoT Profiles
1.0, publish the current text as a Working Group Note and start work on a
Profiles 2.0 specification which takes a different approach.

My personal preference would be option 1 because it's going to be a long
time until TD 2.0 is published and I think profiles are needed for
interoperability in the meantime (I am working on commercial products which
rely on them). However, if option 2 is what is needed to unblock work on
profiles then I would support that. I would also be open to other
suggestions, such as a detailed proposal for what features to remove from
the current specification to make it acceptable.

I would of course be interested to hear other opinions, but then suggest
moving quickly to a formal resolution so that the profile task force can
continue its work.

Kind regards

Ben

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