Check supported protocols in the validation algorithm

[relu91]

As discussed in today's call, we are missing a validation step for TDs regarding the ability to implement a particular security scheme. Currently, this check is hidden behind the 7th step of the expose algorithm:

Set up the WoT Interactions based on introspecting |td| as explained in [WOT-TD] and [WOT-PROTOCOL-BINDINGS]. Make a request to the underlying platform to initialize the Protocol Bindings and then start serving external requests for WoT Interactions (read, write and observe Properties, invoke Actions and manage Event subscriptions), based on the Protocol Bindings.

I think we can make this more explicit and add a separate step where we fail to expose if the underlying platform does not support one or more protocol schemes defined in exposing TD. Another possibility is that we fail only if none of the provided protocol schemes are supported. Or, according to the latest changes in the TD spec (here), we have to compute a boolean expression to know the set of security schemes required by the TD and fail if one of them is not supported.

A final possibility, introduced by @danielpeintner (please correct me if I am wrong), is to treat the whole TD passed as an argument to the ExposedThing constructor as a suggestion and ignore fields and properties that cannot be satisfied. This is what node-wot is doing for forms. (See also my comment #238 (comment))

Related to: #238.

[zolkis]

to treat the whole TD passed as an argument to the ExposedThing constructor as a suggestion

Yes, this is the recommended behavior for Forms.

However, we should be strict about the security schemes, and also we can impose the requirement that at least one Form should be supported by the underlying platform, otherwise fail expose().

[zolkis]

The reason for being permissive with the TD input is that after expose(), the resulting TD can be checked and the Thing can be destroy()'ed.

[relu91]

I am also thinking about the consumer side.

If the exposed supported one particular scheme is not sure that also the consumer will be able to interact with that TD. This is also true for forms: if the exposer has only HTTP forms but the consumer knows only COAP is not able to interact with that TD.

Possibly in those scenarios (i.e. no form found, no security available) we should still let the creation of a ConsumedThing and fail later when the consumer tries to interact with the remote Web Thing.

[zolkis]

if the exposer has only HTTP forms but the consumer knows only COAP is not able to interact with that TD

And that's the consumer's problem :)

[egekorkan]

Regarding binding problem, there was a related issue in WADE that uses node-wot to consume and interact with the Things: tum-esi/wade#69

If there is a standard way to do it, it would be nice but error handling on the consumer side is still not very difficult.

[danielpeintner]

As discussed in the call today I think we should be cautious to fail too early, both on consume and expose side.

Consume

Why should a consumer fail if a TD uses also a protocol (or security schema) the consumer never uses --> it should just work until the protocol/security-scheme is used

Expose

The exposing side is more complicated I guess. Having said that, I think we should support runtimes exposing TDs/interactions that are for example not handled by this given runtime. The other runtime might provide bindings that this runtime is not even capable ... or can check whether the binding is up etc

[egekorkan]

Regarding Consume:

There are protocols like Websockets, MQTT or ROS that require an initial connection to be established. From my point of view, such an initial connection should happen during the consume step, i.e. for MQTT connecting to the broker during consume and then subscribing to the respective topic, for ws opening the socket during consume. It can be argued whether such connections should be done in the first request and not before that.

[danielpeintner]

It can be argued whether such connections should be done in the first request and not before that.

I tend to say that this is up to an implementation and we should not prescribe it.

[zolkis]

Looks like the policy to fail is somewhat protocol dependent.
An initial connection could be encapsulated by the implementation, so it can be kept as implementation detail.

Anyway, with the latest PRs, consume() can fail early and constructing ConsumedThing can fail late.