The smallest number of schema changes required to support transports extensibility

APIs/schemas/constraints-schema.json

@@ -2,23 +2,14 @@
   "$schema": "http://json-schema.org/draft-04/schema#",
   "description": "Used to express the dynamic constraints on transport parameters. These constraints may be set and changed at run time. Parameters must also conform with constraints inferred from the specification. Every transport parameter must have an entry, even if it is only an empty object.",
   "title": "Constraints",
-  "anyOf": [{
-      "type": "array",
-      "items": {
-        "$ref": "constraints-schema-rtp.json"
-      }
-    },
-    {
-      "type": "array",
-      "items": {
-        "$ref": "constraints-schema-websocket.json"
-      }
-    },
-    {
-      "type": "array",
-      "items": {
-        "$ref": "constraints-schema-mqtt.json"
+  "type": "array",
+  "items": {
+    "description": "Constraints on transport parameters",
+    "type": "object",
+    "patternProperties": {
+      "^[a-zA-Z0-9_]+$": {
+        "$ref": "constraint-schema.json#/definitions/constraint"
       }
     }
-  ]
+  }
 }

APIs/schemas/receiver_transport_params.json

@@ -2,29 +2,19 @@
   "$schema": "http://json-schema.org/draft-04/schema#",
   "description": "Transport-specific parameters. If this parameter is included in a client request it must include the same number of array elements (or 'legs') as specified in the constraints. If no changes are required to a specific leg it must be included as an empty object ({}).",
   "title": "Receiver Transport Parameters",
-  "anyOf": [{
-      "type": "array",
-      "items": {
-        "$ref": "receiver_transport_params_rtp.json"
-      }
-    },
-    {
-      "type": "array",
-      "items": {
-        "$ref": "receiver_transport_params_dash.json"
-      }
-    },
-    {
-      "type": "array",
-      "items": {
-        "$ref": "receiver_transport_params_websocket.json"
-      }
-    },
-    {
-      "type": "array",
-      "items": {
-        "$ref": "receiver_transport_params_mqtt.json"
+  "type": "array",
+  "items": {
+    "description": "Transport-specific parameters for a transport",
+    "type": "object",
+    "patternProperties": {
+      "^[a-zA-Z0-9_]+$": {
+        "type": [
+          "string",
+          "boolean",
+          "null",
+          "number"
+        ]
       }
     }
-  ]
+  }
 }

APIs/schemas/sender_transport_params.json

@@ -2,29 +2,19 @@
   "$schema": "http://json-schema.org/draft-04/schema#",
   "description": "Transport-specific parameters. If this parameter is included in a client request it must include the same number of array elements (or 'legs') as specified in the constraints. If no changes are required to a specific leg it must be included as an empty object ({}).",
   "title": "Sender Transport Parameters",
-  "anyOf": [{
-      "type": "array",
-      "items": {
-        "$ref": "sender_transport_params_rtp.json"
-      }
-    },
-    {
-      "type": "array",
-      "items": {
-        "$ref": "sender_transport_params_dash.json"
-      }
-    },
-    {
-      "type": "array",
-      "items": {
-        "$ref": "sender_transport_params_websocket.json"
-      }
-    },
-    {
-      "type": "array",
-      "items": {
-        "$ref": "sender_transport_params_mqtt.json"
+  "type": "array",
+  "items": {
+    "description": "Transport-specific parameters for a transport",
+    "type": "object",
+    "patternProperties": {
+      "^[a-zA-Z0-9_]+$": {
+        "type": [
+          "string",
+          "boolean",
+          "null",
+          "number"
+        ]
       }
     }
-  ]
+  }
 }

APIs/schemas/transporttype-response-schema.json

@@ -3,14 +3,17 @@
   "title": "Transport Type",
   "description": "Transport type URN base used by the Sender or Receiver (i.e. with any subclassifications or versions removed)",
   "type": "string",
-  "oneOf": [
+  "anyOf": [
     {
-      "enum": [
-        "urn:x-nmos:transport:rtp",
-        "urn:x-nmos:transport:dash",
-        "urn:x-nmos:transport:websocket",
-        "urn:x-nmos:transport:mqtt"
-      ]
+      "description": "Any transport type URN base defined in IS-05 or by an AMWA specification in the Transports register of the NMOS Parameter Registers",
+      "type": "string",
+      "pattern": "^urn:x-nmos:transport:[^./]+$"
+    },
+    {
+      "description": "Any manufacturer-specific transport type URN base",
+      "not": {
+        "pattern": "^urn:x-nmos:"
+      }
     }
   ],
   "format": "uri"

docs/APIs - Client Side Implementation.md

@@ -6,6 +6,8 @@ _(c) AMWA 2017, CC Attribution-NoDerivatives 4.0 International (CC BY-ND 4.0)_
 
 The Connection API schemas define sets of parameters for each supported transport type; these are also described in pages in the [Behaviour](Behaviour.md) section of these documents. These pages define which parameters are always present (core), and which are feature-dependent; a client can determine what a Device supports by getting its `/constraints` resource, and SHOULD parse this resource in all cases as a Device might have a constrained range or enumeration of supported values, even for core parameters.
 
+Note: From v1.2 onwards, additional transport types and associated schemas are defined in the [Transports register](https://specs.amwa.tv/nmos-parameter-registers/branches/main/transports/) of the NMOS Parameter Registers.
+
 ## RTP Operating Point
 
 When establishing an RTP connection between two Devices that implement NMOS Connection Management, the expectation is that the primary means of connection will be to supply the SDP file from the Sender to the Receiver. This ensures Receivers have the media information in the SDP file. If desired the client can adjust individual transport parameters on the Receiver. For example it could use the `rtcp_enable` parameter to toggle RTCP operation.

docs/APIs - Server Side Implementation.md

@@ -46,6 +46,8 @@ In some cases the behaviour is more complex, and can be determined by the vendor
 
 It is strongly RECOMMENDED that API implementations validate requests received from clients against the JSON schema included in this specification. Where additional constraints are applied by the API using the `/constraints` resource, these restrictions SHOULD be merged with the provided JSON schema in order to provide consistent validation.
 
+Note: From v1.2 onwards, additional transport types and associated schemas are defined in the [Transports register](https://specs.amwa.tv/nmos-parameter-registers/branches/main/transports/) of the NMOS Parameter Registers.
+
 ### Constraining Interfaces
 
 The constraints are used to advertise the available network interfaces on the Device. This happens through use of an `enum` constraint, which contains an array of the available interface IP addresses. For interfaces capable of operating with IPv6 and IPv4 each interface SHOULD have two entries containing the interface's IPv4 and IPv6 addresses. Examples are provided in the API documentation.

docs/APIs.md

@@ -10,13 +10,16 @@ The Connection API is specified using:
 
 - The following sub-sections describing common API properties.
 - [RAML](http://raml.org/) documents and [JSON schemas](http://tools.ietf.org/html/draft-zyp-json-schema-04) in the [APIs](../APIs/) folder.
+- Transport types and associated schemas defined in the [Transports register](https://specs.amwa.tv/nmos-parameter-registers/branches/main/transports/) of the NMOS Parameter Registers (from v1.2 onwards)
 
 Examples of JSON format output are provided in the [examples](../examples/) folder.
 
 ## API Validation
 
 JSON schemas are included with the RAML API definitions. These include validation for values used within the APIs. It is RECOMMENDED that implementers of a Connection API use these JSON schemas as part of a validation stage when receiving requests from clients. Invalid requests SHOULD cause a `400` (Bad Request) HTTP error to be returned to the client.
 
+Note: From v1.2 onwards, additional transport types and associated schemas are defined in the [Transports register](https://specs.amwa.tv/nmos-parameter-registers/branches/main/transports/) of the NMOS Parameter Registers.
+
 ### Content Types
 
 All APIs MUST provide a JSON representation signalled via `Content-Type: application/json` headers. This SHOULD be the default content type in the absence of any requested alternative by clients. Other content types (such as HTML) are permitted if they are explicitly requested via `Accept` headers.

docs/Upgrade Path.md

@@ -12,6 +12,8 @@ Implementers of the Connection API MUST support at least one API version, and MA
 
 Where a transport type is added in a new version of the Connection API specification, earlier versioned APIs MUST NOT list any Senders or Receivers which make use of this new transport type. In these cases, requests to an inaccessible ID MUST return a `409` (Conflict) HTTP code.
 
+Note: From v1.2 onwards, additional transport types and associated schemas are defined in the [Transports register](https://specs.amwa.tv/nmos-parameter-registers/branches/main/transports/) of the NMOS Parameter Registers.
+
 Where new transport parameters are added to a pre-existing transport type in a new version of the Connection API, earlier versioned APIs MUST NOT list these parameters. New transport parameters SHOULD be defined such that a request which omits them can proceed without error. This ensures that servers implementing multiple versions of the Connection API can continue to process earlier versioned requests successfully.
 
 Connection APIs do not need to provide for forwards compatibility as it might be impossible to generate data for new attributes in schemas.