Part 01 — Scope, Conformance Language and VersioningLink to the section Part 01 — Scope, Conformance Language and Versioning#

Maturity: Draft · Profiles: all

1.1 ScopeLink to the section 1.1 Scope#

This specification defines the Universal Vehicle Interoperability Protocol (UNIVIP): the interfaces through which a UNIVIP device (an uncrewed vehicle in the air, on or under water, or on the ground; its dock; its controller; or a gateway acting for any of these) exposes identity, capabilities, live video, time-synchronized telemetry, events, camera and payload control, and optional authorized vehicle control to a UNIVIP client (typically a Video Management System, command-and-control platform or recording service).

Domains. The data model and command vocabulary are domain-neutral. Every device declares its domain (AIR, UNDERWATER, SURFACE, GROUND, MULTI). In version 0.2, conformance test groups (Part 14) exist for the AIR domain only; members and commands specific to other domains (depth, seabed clearance, vehicle.dive_to, vehicle.surface, acoustic links, non-GNSS positioning) are specified and reserved so that no breaking change is needed when those domains gain implementers (ADR-0007).

In scope:

• discovery, onboarding, authentication and session establishment;
• a capability document describing exactly what a device supports;
• a telemetry data model with explicit units and reference frames;
• an event model and a standard event catalog;
• live video delivery and the association of telemetry with media time;
• camera and payload control commands;
• vehicle control commands, control leases and the safety rules around them;
• an optional geospatial extension;
• security requirements;
• conformance rules and the structure of a conformance test program.

Out of scope:

• airspace or waterway authorization, UTM/U-space, Remote ID broadcast (UNIVIP carries identifiers that allow correlation but does not implement these);
• manual stick-level piloting;
• vehicle-controller internals, autopilot behavior and certification;
• payload release, spraying or any non-sensing effector;
• video analytics algorithms (UNIVIP carries their results through events and the geospatial extension);
• storage formats inside the VMS (UNIVIP specifies what must be preserved, not how).

1.2 Conformance languageLink to the section 1.2 Conformance language#

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY and OPTIONAL in this specification are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals.

Sections marked Informative contain no requirements.

1.3 Conformance targetsLink to the section 1.3 Conformance targets#

A conformance claim names the target and the profile(s): "UNIVIP Device, Profile S and C" or "UNIVIP Client, Profile S". Profile N claims additionally name the supported vehicle.* command subset (Part 11).

1.4 Extensibility rulesLink to the section 1.4 Extensibility rules#

1. Implementations MUST ignore JSON members they do not recognize in any UNIVIP message, unless the member name begins with !, which marks a must-understand extension; a message containing an unrecognized must-understand member MUST be rejected with UNSUPPORTED_EXTENSION.
2. Vendor extensions MUST be placed under a member named x-<vendor> (for example x-acme) or use a reverse-DNS prefixed topic/command name (com.acme.payload.spotlight.set). Vendor members MUST NOT shadow standard members.
3. Enumerations are open unless the schema marks them closed with "x-univip-closed": true (in 0.2: command states and lease states). The schemas list the values defined by the version. A receiver MUST NOT reject or discard a message solely because an open enumeration carries a value it does not know; it MUST treat the value as UNKNOWN for that field (or as absent where the enumeration has no UNKNOWN). This does not oblige a device to act on an unknown value in a command or request: it rejects such a command, either as a body that fails the command schema (HTTP 400 malformed) or after its own checks (422, INVALID_PARAMETERS, or UNSUPPORTED_COMMAND for an unknown type).
4. New standard fields are added only as OPTIONAL members in MINOR versions.
5. In the capability document, an optional member whose value is null means the same as the member being absent. (Telemetry does not use null for numeric members; Part 07 §7.1.)

1.5 VersioningLink to the section 1.5 Versioning#

• The specification version is MAJOR.MINOR.PATCH.
• Every message carries a schema member of the form univip.<kind>.v<MAJOR>.<MINOR> (for example univip.telemetry.v0.2). Receivers MUST accept any MINOR equal to or lower than the highest they support within the same MAJOR, and SHOULD accept higher MINORs by ignoring unknown members. A receiver that validates against the schemas MUST NOT reject a message solely because its schema member names another MINOR of the same MAJOR; the schemas therefore match schema by pattern (univip.<kind>.v0.<n>) rather than by constant.
• While MAJOR is 0, a MINOR version MAY add requirements that a device conforming to the previous MINOR does not meet; the changelog lists them. Such requirements apply to messages that declare the new MINOR, so that older messages keep validating: in 0.2, a capability document declaring v0.2 without a REST listener must offer the session proxy (Part 05 §5.5.1), while a 0.1 document need not.
• The REST API path carries the MAJOR version: /univip/v1/.
• The capability document (Part 06) lists the exact schema versions a device emits so a client can decide before subscribing.

1.6 Normative referencesLink to the section 1.6 Normative references#

• RFC 2119, RFC 8174 — requirement keywords
• RFC 3339 — timestamps
• RFC 8259 — JSON
• RFC 6455 — WebSocket
• RFC 8446 — TLS 1.3
• RFC 6749, RFC 8628, RFC 7519, RFC 8705 — OAuth 2.0, device authorization grant, JWT, mTLS client authentication
• RFC 8825, RFC 8829, RFC 8831, RFC 8834 — WebRTC overview, JSEP, data channels, media transport
• RFC 6762, RFC 6763 — mDNS, DNS-SD
• RFC 7946 — GeoJSON
• JSON Schema 2020-12
• OpenAPI Specification 3.1
• OASIS MQTT Version 5.0
• ISO 14496-10 (H.264/AVC), ISO 23008-2 (H.265/HEVC)
• MISB ST 0601 — UAS Datalink Local Set
• ONVIF Core, Media2, PTZ, Imaging, Events, Uplink and WebRTC specifications (for mappings in Annex A)
• MAVLink common message set (for mappings in Annex A)