Sender Capabilities

[N-Nagorny]

In some cases it's possible to know some of Source capabilities (e.g. Gateway Sender has its own restrictions which are narrower than HDMI Sources' ones). Utilizing caps of Source should be considered for it as well as a new HTTP response code for PUT /media-profiles operation.

[N-Nagorny]

The spec changed crucially but the idea of Sender Capabilities is still actual and should be considered in future. Renaming the issue: Source Capabilities -> Sender Capabilities.

[N-Nagorny]

Describing it seems more clear than before so we may want to consider adding Sender Capabilities in the closer prospective than versions after v1.0.

1. A Sender should have constraint_sets, filled in the same way as for Receivers, inside caps object.
2. When PUT /senders/{senderId}/constraints/active, the Sender checks that each Constraint Set of Active Constraints is a subset of any of Constraint Sets in the Sender Capabilities. If this check fails, the server responds with 422.
3. Constraint Set B is a subset of Constraint Set A if all of Parameter Constraints of Constraint Set B, except for meta, are present in Constraint Set A and each Parameter Constraint of Constraint Set B, except for meta, is a subconstraint of the according Parameter Constraint of Constraint Set A.
4. Constraint B is a subconstraint of a Constraint A if:
   1. Constraint B has enum keyword when Constraint A has it and enum of Constraint B is a subset of enum of Constraint A
   2. Constraint B has enum or minimum keyword when Constraint A has minimum keyword and allowed values for Constraint B are less than allowed values for Constraint A
   3. Constraint B has enum or maximum keyword when Constraint A has maximum keyword and allowed values for Constraint B are greater than allowed values for Constraint A

[garethsb]

Whose responsibility should it be to make a subset. If the Node has to evaluate whether something is a subset, how much more work is it to try to produce an intersection when it isn't? E.g. when parameter constraint in Sender caps has min 1, max 10, proposed one has min 5, max 15. But even evaluating everything involves a lot of combinations, probably every proposed constraint set has to be evaluated against each one from Sender caps, and there could be multiple possible intersections. Hmm.

[alabou]

Sender capabilities are for the Controller, similar to Receiver capabilities ... Receiver capabilities today are more important than Sender capabilities because of the lack of Source/Flow on the receiver side. On the Sender side, IF there is a valid signal the actual Flows and Sources associated to the various Senders of a device provide some information about what the device is capable of ... But having Sender capabilities would help a Controller know without any active signals what a Sender is capable of and then know before getting a 422 status that a Sender is not capable of supporting some constraint value.

I think we should see it as a way for a Controller to prevent getting a 422 status. I would not have normative language in IS-11 indicating that a Sender shall behave in any specific way regarding its declared capabilities and the active constraints ... relying only on returning a 422 status when it is not capable of supporting a given constraint value or combination of constraint values.

[N-Nagorny]

Regarding my previous message, I would say the Node is responsible for validating Active Constraints against Sender Capabilities. The work for producing an intersection looks as complex as now: the Controller never knows when it'll get 422, but Sender Capabilities at least give some hints. Though, I don't insist on validating, it may be just declaration as Alain described.

[garethsb]

I agree that we should think about describing Sender capabilities more than /supported endpoint does now. Without Sender capabilities (e.g. in IS-04 caps), the 422 (Unprocessable Entity) response to PUT /senders/{senderId}/constraints/active leaves the Controller with no information about what to change.

[alabou]

The /supported endpoint describes the constraints that a Sender supports, these are not Sender's capabilities, but I agree that on error 422 a Controller could verify if some Sender's capabilities matching the /supported constraints have values outside the Sender's capabilities. For example a Sender indicates capabilities urn:x-nmos:cap:format:frame_height maximum 1080 and receives a constraint urn:x-nmos:cap:format:frame_height equal 2160 and return error 422, the Controller could understand why. I think it should be allowed for a Sender to have /supported being a superset of what the sender describes as capabilities.

[garethsb]

What would be the point of supporting constraints that weren't used to express the Sender's capabilities?

[alabou]

For example a device X supports almost any resolution (w x h x rate) with some rare exceptions ... I think that describing ALL the possibilities in the Sender capabilities would not be a good idea and instead indicating generic minimum/maximum could cover most cases ... The Sender's could still in some rare cases return a 422 error. Maybe adding a debug string along with the 422 error to describe the reason of the error.

[garethsb]

OK, I see, you are saying it may make sense to not enumerate all possible width x height in separate constraint sets in IS-04 Sender caps but still to indicate in IS-11 /supported that you understand constraints on width and height?

[garethsb]

I agree that there may be cases where you want to return 422 even when the advertised IS-04 constraints are a superset of the proposed IS-11 PUT ones. This is like returning 400 Bad Request from IS-05 PATCH because /constraints cannot capture every reason to reject a request.