Specify whether or not "auto" is allowed for IS-07 "ext_" transport parameters

[garethsb]

The IS-07 specification for the IS-05 "externally defined transport parameters", ext_is_07_rest_api_url and ext_is_07_source_id in Transport - Websocket - Connection management and Transport - MQTT - Connection management needs to indicate whether or not "auto" is permitted in a PATCH /staged request.

It would also be nice to have an example of the "enum" constraint that should be included in the /constraints endpoint for each of these, e.g. to show that the ext_is_07_source_id is a fixed value (or "auto" if that is to be permitted).

See also AMWA-TV/is-05#71.

[garethsb]

I realise that I was a bit confused because these transport parameters (and connection_uri, broker_topic) are exposed for both IS-05 Senders and IS-05 Receivers.

When I raised this issue, I was thinking about these parameters on Senders. I assumed that the value of ext_is_07_source_id is fixed, since logically speaking it is read-only? An implementation must accept a PATCH request for the parameter but only if it doesn't change the value. Therefore the /constraints must include the value. The spec could also allow "auto" as a shorthand, but really there's no need, right?

It is a similar situation for ext_is_07_rest_api_url on Senders. At first, it seems maybe it should allow several values, e.g. if the WebSocket server has more than one IP address, e.g. because it is bound to more than one interface. However, the IS-04 Sender indicates which interface it is bound to (see #37), so perhaps this parameter value is also basically fixed, logically read-only? In which case, as above, the /constraints must include the value. Again the spec could also allow "auto" as a shorthand, but probably better to wait on the resolution to AMWA-TV/is-05#70 before doing so?

Is the broker_topic for a Sender also always, or likely to be, fixed?

However, Receivers are a different matter. I now realise the Example IS-05 PATCH request in Transport - MQTT - Connection management (and the similar one in Transport - WebSocket - Connection management) is presumably entirely about patching a Receiver. I think this needs clarifying in case anyone is confused like me, and it would be better if there were also examples of patching a Sender.

For Receivers, the ext_is_07_source_id could reasonably be unconstrained (apart from the id regex pattern in the schema), so it may be that the /constraints entry would be an empty object. Presumably that's also true of ext_is_07_rest_api_url, connection_uri, broker_topic?

However, isn't it the case that e.g. ext_is_07_source_id, ext_is_07_rest_api_url, connection_uri must be consistent? How should a PATCH that only updates one of these parameters be processed by a Receiver?

[mjeras]

The idea behind the transport parameters was that they are read only on the sender side and but exposed so that the control system can pick them up from there and pass on to the receiver. So yes, the constraints should be set so that they accept only one value. (That applies to all three parameters).
I agree that patching a single parameter doesn't make sense on the receiver side, but the consistency of the parameters would be very difficult to check (would probably involve querying the node and/or the registry), so I would leave it to the control system to ensure it maintains that consistency. If that doesn't happen, IS-07 wouldn't work, or would work partially, but I don't think the receivers should do any extra processing.

[garethsb]

That makes perfect sense, thanks, Miroslav. I will attempt to make a PR that clarifies that.