is-05
is-05 copied to clipboard
AMWA-TV
Consider whether new transport types can be supported without a version bump
As of v1.1-dev, new transport types have been added (websocket/mqtt), but a version bump is required in order to add any further new ones. This is the safest route, but it may be useful to be able to avoid version bumps for any future new transport types. There are of course a number of trade-offs, including:
- If we supported new transports without version changes, the transport constraints and other schemas would need to be documented elsewhere to avoid the spec itself changing. This may make testing harder, and it may be harder to keep them stable / avoid accidental breaking changes.
- With transport schemas held elsewhere, they would likely need to be versioned independently of the core spec. This helps with flexibility, but increases complexity for servers, clients and end users. Clients in particular may encounter several matching IS-05 versions but be unable to control all of them due to differing transport parameter schema versions.
This topic can be discussed at a later date if it is deemed important.
This has been discussed again in the Incubator, several activity groups and the @AMWA-TV/nmos-architecture-review team recently, due to renewed interest in supporting NDI, MPEG TS, SRT, etc.
The /transporttype response schema has a fixed list of supported types.
The sender "transport_params" schema and receiver "transport_params" schema are also restricted.
Similarly the constraints schema.
These schemas form a normative part of the specification. It would be quite invasive to loosen the specification schemas and pull the specific per-transport schemas out into an external register. ARG have tentatively concluded it should not be done without a minor version up.
While the exact mechanisms are still to be finalized, activity groups that are focused on specific new transports can assume that they can design new transport parameter schemas following the existing data model for individual transport parameters (no new data types or constraint keywords, same treatment of "auto", null, etc.) and will be able to publish these against a registered transport type in the Parameter Registers.
