Specification of permitted values for IS-04 flow parameters

[rmsporter]

We have been seeing some issues with consistency of implementation related to the IS-04 flow parameters “colorspace” and “transfer_characteristic”. To improve clarity we thought it worth revisiting the approach to defining the permitted values for these parameters.

Currently, a subset of permitted values is enumerated in the IS-04 v1.3 specification (https://github.com/AMWA-TV/nmos-discovery-registration/blob/v1.3.x/APIs/schemas/flow_video.json).

Additionally, free text is permitted and it is noted that additional values should be defined in the NMOS Parameter Registers (https://specs.amwa.tv/nmos-parameter-registers/branches/main/flow-attributes/).

In the NMOS Parameter Registers, the schema-defined values are again listed, and it is mentioned that additional values from “any published revision of ST 2110-20” are also permitted.

Due to these two levels of indirection, many implementers are not currently supporting all values listed in ST 2110-20. In addition, as SMPTE specs are not openly available we have the issue that one cannot determine all permitted values within the available open specifications.

The current approach was created to avoid the requirement for new versions of IS-04 each time new values for these parameters are defined elsewhere. However, our experience is that this is at the cost of clarity and interoperability.

To address this, there are two possible courses of action to improve clarity:

1. Enumerate all the permissible values from ST 2110-20 in the IS-04 spec explicitly.
2. Enumerate all the permissible values in the Parameter Registers and remove them from IS-04, so IS-04 only points to the Parameter Registers.

Option 1 would be clearest to implementers. It would require a new IS-04 (minor) version each time ST 2110-20 introduces new values, but this does not occur very often.

Option 2 may be possible as an editorial change to IS-04 (new patch release only) as it doesn’t change which values are valid. It also has the advantage that it would allow additional values to be added via the NMOS Parameter Registers in future without any need to change IS-04, as per the spirit of the current approach.

[peterbrightwell]

Discussed on Incubator call 2021-08-04. Option 2 probably more desirable -- loosen schema and put the information in the param registers. Add text to Behaviour section(s). But further feedback from implementers please! And @rmsporter please comment.

[cristian-recoseanu]

There is a precedent for this in the BCP-004-01 whereby it links directly to the NMOS Parameter Registers https://specs.amwa.tv/bcp-004-01/releases/v1.0.0/docs/1.0._Receiver_Capabilities.html#defining-parameter-constraints

[prince-chrismc]

Option 2 probably more desirable

👍 Looking at the docs I noticed https://github.com/AMWA-TV/nmos-discovery-registration/pull/106 introduced

Any values not defined in the enum should be defined in the NMOS Parameter Registers

---

With the release of VSF's TR-08 this issue can be extended to the "media_type" for compressed video flows which permits "any IANA assigned value" which includes the new video/jxsv.

[garethsb]

Option 1 is a non starter. Option 2 seems unnecessary to me, and if there are non-conforming implementations, I would increase test suite coverage, but if that's not enough, Option 2 is better.

[peterbrightwell]

Needs more clarification, so: Architecture Review Group review: place on backlog

[TheSaneWonko]

The specifications already mention that additional enum values should be added to the parameter register. Additional interoperability issues should be addressed with specific test scenarios in the test suite.