Reconsider the interaction between Thing::base, Form and how the protocol is signaled

[lu-zero]

Once a Thing is providing Forms with multiple protocols the Thing::base is less useful.

I'd suggest to consider

• Having a Thing::protocol defaulting to https. (profile overrides)
• Restricting the Thing::base to be //{host}[":" {port}]["/" {path}]
• Having a Form::protocol to deliver the information on the protocol used, and potentially drop subprotocol by using scheme+subscheme if we feel we have too many fields.
• Having an optional Link::protocol.
• Restricting Form::href and Link::href similarly to base + allowing relative paths and such.

[danielpeintner]

Is related to https://github.com/w3c/wot-thing-description/issues/803

[egekorkan]

So the linked issue is correct (which also links to https://github.com/w3c/wot-thing-description/issues/1248). In TD 2.0, we want to introduce a top level term to group such protocol related information. Regarding other points mentioned:

Having a Thing::protocol

This would help with identifying the protocol. I do not think that a default would be very needed here though.

potentially drop subprotocol by using scheme+subscheme

We need to look into possible issues with this. https://w3c.github.io/wot-binding-templates/bindings/protocols/coap/index.html#observing-resources would not translate well. Also, + is used for cases like modbus+tcp but one might argument that Modbus is a subprotocol of TCP. All in all, subprotocol is there to say that we are using that protocol in a more specific way. It is a bit of a bad design currently that the URI scheme and subprotocol combinations have different meanings. A consumer cannot use a form with sse and HTTP if it cannot use sse, so they are actually tightly linked.

[lu-zero]

This would help with identifying the protocol. I do not think that a default would be very needed here though. We need a place to hold a default.

We need to look into possible issues with this. https://w3c.github.io/wot-binding-templates/bindings/protocols/coap/index.html#observing-resources would not translate well. According to my proposal this would provide the same amount of information:

"properties": {
"status": {
"type": "string",
"readOnly": true,
"forms": [{
"cov:method": "GET",
"href": "//[2001:DB8::1]/status",
"contentType": "text/plain;charset=utf-8",
"protocol": "coap+observe",
"op": ["observeproperty"]
}]
}
}

With my additional proposal about Form::verb:

"properties": {
"status": {
"type": "string",
"readOnly": true,
"forms": [{
"verb": "cov:GET",
"href": "//[2001:DB8::1]/status",
"contentType": "text/plain;charset=utf-8",
"protocol": "coap+observe",
"op": "observeproperty"
}]
}
}

All in all, subprotocol is there to say that we are using that protocol in a more specific way. It is a bit of a bad design currently that the URI scheme and subprotocol combinations have different meanings. A consumer cannot use a form with sse and HTTP if it cannot use sse, so they are actually tightly linked.

Our (sub)protocol usage does not allow for any kind of degraded interoperability, e.g. either the consumer supports http+sse or it won't use the form, right now the parts of information needed to figure out are scattered inside the href and subprotocol and you have to parse href in order. I suggest to keep it in a single place and call it what it is.

[relu91]

I think the problem has many different faces (as suggested by the many issues linked in #1248). There is also some loose dependency on https://github.com/w3c/wot-thing-description/issues/968. My feeling is that if we would rethink the subscribe/observe operations as connections and have this concept of connection as a first-class entity then we could also have a global section where to describe those objects.

Anyhow, we should start from somewhere about the concrete proposal here:

Having a Thing::protocol defaulting to https. (profile overrides)

I still have to read the final status of the profile document but I would think that this rule applies only if the profile is active for a particular TD, so this is not something for the TD document. Unless we want to go ahead with the idea of profiles as "defaults" protocol bindings configurations.

Restricting the Thing::base to be //{host}[":" {port}]["/" {path}] Having a Form::protocol to deliver the information on the protocol used, and potentially drop subprotocol by using scheme+subscheme if we feel we have too many fields. Having an optional Link::protocol. Restricting Form::href and Link::href similarly to base + allowing relative paths and such.

These points are conservative, which is something that I like.

It is a bit of a bad design currently that the URI scheme and subprotocol combinations have different meanings. A consumer cannot use a form with sse and HTTP if it cannot use sse, so they are actually tightly linked.

I definitely agree with this, we need something that tight together the allowed subprotocols, but maybe this is something that can be only solved at the spec level? 🤔

[benfrancis]

I agree it's a bit awkward that there's a single base member but multiple forms, but let's be careful not to lose the enormous benefits that already standardised URIs bring to the Web of Things, specifically linkability which is one of the fundamental features of the web. URIs are ubiquitous and can serialise a lot of information about how to identify, locate and access a resource.

The idea of resolving a URI against a base URI is also well established and standardised and probably shouldn't be re-defined within WoT. Note that HTML also has the restriction of a single <base> element per document, so absolute URIs have to be used in some cases.

I would be cautious about splitting bits of information out of URIs into JSON, whilst also inventing a new way to serialise other information (protocol + subprotocol).

I agree the subprotocol member is currently a bit nebulous, but it is used to provide additional communication metadata which is not possible to serialise in a URI. In WebSockets "subprotocol" has a specific meaning, but elsewhere it is being used to describe particular patterns or sub-specifications being used (specifically different ways of doing eventing with HTTP).

@lu-zero I'm curious what use case led you to discover this problem? Were you writing a Thing Description which uses multiple protocols, and if so which protocols were they? Was it HTTP and CoAP, or some other protocol which doesn't have a formal URI scheme?

As @relu91 pointed out this is a multi-faceted issue which also touches on the issue of metadata redundancy, and describing persistent connections for stateful protocols (which I personally think is a separate problem to the one the base member is solving).

[lu-zero]

I agree it's a bit awkward that there's a single base member but multiple forms, but let's be careful not to lose the enormous benefits that already standardised URIs bring to the Web of Things, specifically linkability which is one of the fundamental features of the web. URIs are ubiquitous and can serialise a lot of information about how to identify, locate and access a resource.

My proposal is to still use the standardised urls, just restricting what you can put in them so we can use relative urls in more occasions.

The idea of resolving a URI against a base URI is also well established and standardised and probably shouldn't be re-defined within WoT. Note that HTML also has the restriction of a single <base> element per document, so absolute URIs have to be used in some cases.

All still applies, just the information provided by the scheme is deduplicated.

@lu-zero I'm curious what use case led you to discover this problem? Were you writing a Thing Description which uses multiple protocols, and if so which protocols were they? Was it HTTP and CoAP, or some other protocol which doesn't have a formal URI scheme?

Just the general mechanism felt less then straightforward since you basically have to get the information of Thing::base, Form::href and Form::subprotocol and go back and forth the uri parser.

having the protocol explicitly available let you select the Forms w/out having to build and parse the uri.

[egekorkan]

Also see https://github.com/w3c/wot-binding-templates/issues/176

We will hold a discussion about this in one of the upcoming TD calls.