An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model
Extracted elements (27)
The <clueInfo> root element was defined only for data-model testing purposes and deliberately resembles, but does not match, the body of a CLUE ADVERTISEMENT message; actual protocol messages are defined in RFC 8847.
The mediaType attribute of mediaCaptureType was intentionally defined as a generic xs:string rather than an enumeration to allow new media types without schema changes; interoperability for non-standard values requires application-level agreement between implementations.
The schema uses xs:any and xs:anyAttribute throughout to maximize extensibility while complying with the XML Schema Unique Particle Attribution (UPA) constraint, allowing custom namespaced extensions without losing schema validity.
The <personInfo> element uses the vcardType imported from the xCard XML schema (RFC 6351 / RFC 7852 Appendix A), requiring the <fn> element within <vcard> to be present as mandated by the xCard specification.
<captureArea> MUST be included in the spatial information of spatially definable video captures and MUST NOT be associated with audio captures. The four corner points (<bottomLeft>, <bottomRight>, <topLeft>, <topRight>) MUST be coplanar.
<captureOrigin> MUST be included in the spatial information of spatially definable audio captures; it is optional for spatially definable video captures. The lineOfCapturePoint coordinates MUST NOT be identical to the capturePoint coordinates.
Coordinates of all spatial points (capturePoint, lineOfCapturePoint, captureArea corners) MUST be expressed according to the coordinate space defined for the capture scene to which the media capture belongs.
Each media capture MUST be defined within one and only one capture scene, as indicated by the mandatory <captureSceneIDREF> element referencing the sceneID of the containing scene.
Elements or attributes from unknown namespaces MUST be ignored, supporting forward-compatible schema extensibility.
Non-spatially definable media captures MUST be marked with <nonSpatiallyDefinable> set to 'true', and no <spatialInformation> element MUST be provided. The two tags are mutually exclusive in the XML schema.
Text captures MUST be marked as non-spatially definable, i.e., they MUST present the <nonSpatiallyDefinable> element set to 'true' in their XML description.
The total number of media captures listed in the <configuredContent> element of a <captureEncoding> MUST be lower than or equal to the value carried within the <maxCaptures> attribute of the referenced MCC.
When a <simultaneousSet> lists only capture scene identifiers (<captureSceneIDREF>), the mediaType attribute MUST appear in the XML description to determine which media captures can be simultaneously sent.
When <allowSubsetChoice> is true and the MCC references other captures, the Consumer MAY specify a subset via CONFIGURE, and the Provider MUST then include only that subset. If <allowSubsetChoice> is false or absent, the Consumer MUST NOT select a subset.
When the exactNumber attribute of <maxCaptures> is not set to 'true', the number of simultaneously represented media captures MUST be considered less than or equal to the <maxCaptures> value.
The abstract mediaCaptureType defines mandatory fields captureID (xs:ID), mediaType (xs:string), captureSceneIDREF (xs:IDREF), and a mutually exclusive choice between <spatialInformation> and <nonSpatiallyDefinable>. A second mutual exclusion separates MCC-specific fields (synchronizationID, content, policy, maxCaptures, allowSubsetChoice) from the <individual> boolean fixed to true.
The <clueInfo> root element aggregates all CLUE data model components: <mediaCaptures>, <encodingGroups>, <captureScenes>, optional <simultaneousSets>, optional <globalViews>, and optional <people>. It is defined for testing and validation purposes and is not directly used in CLUE protocol ADVERTISEMENT messages.
IANA created four Expert Review registries for enumerated string values: 'CLUE Schema <view>' (initial: room, table, lectern, individual, audience), 'CLUE Schema <presentation>' (initial: slides, images), 'CLUE Schema <sensitivityPattern>' (initial: uni, shotgun, omni, figure8, cardioid, hyper-cardioid), and 'CLUE Schema <personType>' (initial: presenter, timekeeper, attendee, minute taker, translator, chairman, vice-chairman, observer).
IANA registered the XML namespace urn:ietf:params:xml:ns:clue-info and the XML schema urn:ietf:params:xml:schema:clue-info per RFC 3688, and registered the media type application/clue_info+xml (file extension .clue, intended usage LIMITED USE).
CLUE data model information SHOULD be accessed only by authenticated endpoints; vCard data in <personInfo> mandatorily contains a person's identity and optionally contact addresses, photos, and other personal data, making unauthenticated access a privacy risk. Authentication is not mandated because some sessions may legitimately require no protection.
Integrity attacks on CLUE data model information can mislead both the Media Consumer and Media Provider in interpreting offered and desired media streams, invalidating telepresence session setup; integrity and authentication assurance is delegated to the CLUE protocol (RFC 8847) and CLUE data channel (RFC 8850).
XML parsers MUST be robust against malformed documents; processing malformed CLUE XML from untrusted sources could allow an attacker to gain the privileges of the user running the parser, potentially compromising the entire host.
captureEncodingType encodes a Media Consumer's stream request: mandatory <captureID> (xs:string), mandatory <encodingID> (xs:string), optional <configuredContent> (contentType listing desired capture and scene-view IDs for MCCs), and a mandatory ID attribute (xs:ID).
mobilityType is an enumeration restricted to three string values: 'static' (SHOULD NOT change across ADVERTISEMENTs), 'dynamic' (MAY change per ADVERTISEMENT), and 'highly-dynamic' (MAY change between consecutive ADVERTISEMENTs).
pointType encodes a 3D spatial coordinate as three child elements <x>, <y>, <z> each of type xs:decimal. Used in captureOriginType (capturePoint, lineOfCapturePoint) and captureAreaType (bottomLeft, bottomRight, topLeft, topRight).
policyType is an xs:string restricted by the pattern ([a-zA-Z0-9])+[:]([0-9])+ representing a switching-policy token and a numeric instance index separated by ':' (e.g., SoundLevel:2, RoundRobin:0).
scaleType is an xs:string enumeration with values 'mm' (millimeters, for precisely measured rooms), 'unknown' (consistent relative scale without a defined unit), and 'noscale' (no common physical scale across captures in the scene).