An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model (original) (raw)

RFC 8846 An XML Schema for the CLUE Data Model January 2021
Presta & Romano Standards Track [Page]

RFC 8846

Abstract

This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "Controlling Multiple Streams for Telepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc8846.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

This document provides an XML schema file for the definition of CLUE data model types. For the benefit of the reader, the term "CLUE" stands for "Controlling Multiple Streams for Telepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. A thorough definition of the CLUE framework can be found in [RFC8845].

The schema is based on information contained in [RFC8845]. It encodes information and constraints defined in the aforementioned document in order to provide a formal representation of the concepts therein presented.

The document specifies the definition of a coherent structure for information associated with the description of a telepresence scenario. Such information is used within the CLUE protocol messages [RFC8847], enabling the dialogue between a Media Provider and a Media Consumer. CLUE protocol messages, indeed, are XML messages allowing (i) a Media Provider to advertise its telepresence capabilities in terms of media captures, capture scenes, and other features envisioned in the CLUE framework, according to the format herein defined and (ii) a Media Consumer to request the desired telepresence options in the form of capture encodings, represented as described in this document.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Definitions

This document refers to the same definitions used in [RFC8845], except for the "CLUE Participant" definition. We briefly recall herein some of the main terms used in the document.

Audio Capture:

Media Capture for audio. Denoted as "ACn" in the examples in this document.

Capture:

Same as Media Capture.

Capture Device:

A device that converts physical input, such as audio, video, or text, into an electrical signal, in most cases to be fed into a media encoder.

Capture Encoding:

A specific encoding of a Media Capture, to be sent by a Media Provider to a Media Consumer via RTP.

Capture Scene:

A structure representing a spatial region captured by one or more Capture Devices, each capturing media representing a portion of the region. The spatial region represented by a Capture Scene may correspond to a real region in physical space, such as a room. A Capture Scene includes attributes and one or more Capture Scene Views, with each view including one or more Media Captures.

Capture Scene View (CSV):

A list of Media Captures of the same media type that together form one way to represent the entire Capture Scene.

CLUE Participant:

This term is imported from the CLUE protocol document[RFC8847].

Consumer:

Short for Media Consumer.

Encoding or Individual Encoding:

A set of parameters representing a way to encode a Media Capture to become a Capture Encoding.

Encoding Group:

A set of encoding parameters representing a total media encoding capability to be subdivided across potentially multiple Individual Encodings.

Endpoint:

A CLUE-capable device that is the logical point of final termination through receiving, decoding and rendering, and/or initiation through capturing, encoding, and sending of media streams. An endpoint consists of one or more physical devices that source and sink media streams, and exactly one participant [RFC4353] (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera rooms to handheld devices.

Media:

Any data that, after suitable encoding, can be conveyed over RTP, including audio, video, or timed text.

Media Capture:

A source of Media, such as from one or more Capture Devices or constructed from other media streams.

Media Consumer:

A CLUE-capable device that intends to receive Capture Encodings.

Media Provider:

A CLUE-capable device that intends to send Capture Encodings.

Multiple Content Capture (MCC):

A Capture that mixes and/or switches other Captures of a single type (for example, all audio or all video). Particular Media Captures may or may not be present in the resultant Capture Encoding depending on time or space. Denoted as "MCCn" in the example cases in this document.

Multipoint Control Unit (MCU):

A CLUE-capable device that connects two or more endpoints together into one single multimedia conference [RFC7667]. An MCU includes a Mixer, similar to those in [RFC4353], but without the requirement to send media to each participant.

Plane of Interest:

The spatial plane within a scene containing the most-relevant subject matter.

Provider:

Same as a Media Provider.

Render:

The process of generating a representation from Media, such as displayed motion video or sound emitted from loudspeakers.

Scene:

Same as a Capture Scene.

Simultaneous Transmission Set:

A set of Media Captures that can be transmitted simultaneously from a Media Provider.

Single Media Capture:

A capture that contains media from a single source capture device, e.g., an audio capture from a single microphone or a video capture from a single camera.

Spatial Relation:

The arrangement of two objects in space, in contrast to relation in time or other relationships.

Stream:

A Capture Encoding sent from a Media Provider to a Media Consumer via RTP [RFC3550].

Stream Characteristics:

The media stream attributes commonly used in non-CLUE SIP/SDP environments (such as media codec, bitrate, resolution, profile/level, etc.) as well as CLUE-specific attributes, such as the Capture ID or a spatial location.

Video Capture:

A Media Capture for video.

4. XML Schema

This section contains the XML schema for the CLUE data model definition.

The element and attribute definitions are formal representations of the concepts needed to describe the capabilities of a Media Provider and the streams that are requested by a Media Consumer given the Media Provider's ADVERTISEMENT [RFC8847].

The main groups of information are:

All of the above refer to concepts that have been introduced in [RFC8845] and further detailed in this document.

<xs:schema targetNamespace="urn:ietf:params:xml:ns:clue-info" xmlns:tns="urn:ietf:params:xml:ns:clue-info" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:clue-info" xmlns:xcard="urn:ietf:params:xml:ns:vcard-4.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">

<xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0" schemaLocation= "https://www.iana.org/assignments/xml-registry/schema/ vcard-4.0.xsd"/>

<xs:element name="mediaCaptures" type="mediaCapturesType"/> <xs:element name="encodingGroups" type="encodingGroupsType"/> <xs:element name="captureScenes" type="captureScenesType"/> <xs:element name="simultaneousSets" type="simultaneousSetsType"/> <xs:element name="globalViews" type="globalViewsType"/> <xs:element name="people" type="peopleType"/>

<xs:element name="captureEncodings" type="captureEncodingsType"/>

<xs:complexType name="mediaCapturesType"> xs:sequence <xs:element name="mediaCapture" type="mediaCaptureType" maxOccurs="unbounded"/>

<xs:element name="description"> xs:complexType xs:simpleContent <xs:extension base="xs:string"> <xs:attribute name="lang" type="xs:language"/>

<xs:complexType name="mediaCaptureType" abstract="true"> xs:sequence <xs:element name="captureSceneIDREF" type="xs:IDREF"/> xs:choice xs:sequence <xs:element name="spatialInformation" type="tns:spatialInformationType"/> <xs:element name="nonSpatiallyDefinable" type="xs:boolean" fixed="true"/> xs:choice xs:sequence <xs:element name="synchronizationID" type="xs:ID" minOccurs="0"/> <xs:element name="content" type="contentType" minOccurs="0"/> <xs:element name="policy" type="policyType" minOccurs="0"/> <xs:element name="maxCaptures" type="maxCapturesType" minOccurs="0"/> <xs:element name="allowSubsetChoice" type="xs:boolean" minOccurs="0"/> <xs:element name="individual" type="xs:boolean" fixed="true"/> <xs:element name="encGroupIDREF" type="xs:IDREF" minOccurs="0"/> <xs:element ref="description" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="priority" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="lang" type="xs:language" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="mobility" type="mobilityType" minOccurs="0" /> <xs:element ref="presentation" minOccurs="0" /> <xs:element ref="embeddedText" minOccurs="0" /> <xs:element ref="view" minOccurs="0" /> <xs:element name="capturedPeople" type="capturedPeopleType" minOccurs="0"/> <xs:element name="relatedTo" type="xs:IDREF" minOccurs="0"/> <xs:attribute name="captureID" type="xs:ID" use="required"/> <xs:attribute name="mediaType" type="xs:string" use="required"/>

<xs:simpleType name="policyType"> <xs:restriction base="xs:string"> <xs:pattern value="([a-zA-Z0-9])+:+"/>

<xs:complexType name="contentType"> xs:sequence <xs:element name="mediaCaptureIDREF" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="sceneViewIDREF" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

<xs:simpleType name="positiveShort"> <xs:restriction base="xs:unsignedShort"> <xs:minInclusive value="1">

<xs:complexType name="maxCapturesType"> xs:simpleContent <xs:extension base="positiveShort"> <xs:attribute name="exactNumber" type="xs:boolean"/>

<xs:complexType name="capturedPeopleType"> xs:sequence <xs:element name="personIDREF" type="xs:IDREF" maxOccurs="unbounded"/>

<xs:complexType name="peopleType"> xs:sequence <xs:element name="person" type="personType" maxOccurs="unbounded"/>

<xs:complexType name="personType"> xs:sequence <xs:element name="personInfo" type="xcard:vcardType" maxOccurs="1" minOccurs="0"/> <xs:element ref="personType" minOccurs="0" maxOccurs="unbounded" /> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="personID" type="xs:ID" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

<xs:element name="personType" type="xs:string"> xs:annotation xs:documentation Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <personType>" registry, accessible at https://www.iana.org/assignments/clue.

<xs:element name="view" type="xs:string"> xs:annotation xs:documentation Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <view>" registry, accessible at https://www.iana.org/assignments/clue.

<xs:element name="presentation" type="xs:string"> xs:annotation xs:documentation Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <presentation>" registry, accessible at https://www.iana.org/assignments/clue.

<xs:complexType name="spatialInformationType"> xs:sequence <xs:element name="captureOrigin" type="captureOriginType" minOccurs="0"/> <xs:element name="captureArea" type="captureAreaType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

<xs:complexType name="pointType"> xs:sequence <xs:element name="x" type="xs:decimal"/> <xs:element name="y" type="xs:decimal"/> <xs:element name="z" type="xs:decimal"/>

<xs:complexType name="captureOriginType"> xs:sequence <xs:element name="capturePoint" type="pointType"> <xs:element name="lineOfCapturePoint" type="pointType" minOccurs="0"> <xs:anyAttribute namespace="##any" processContents="lax"/>

<xs:complexType name="captureAreaType"> xs:sequence <xs:element name="bottomLeft" type="pointType"/> <xs:element name="bottomRight" type="pointType"/> <xs:element name="topLeft" type="pointType"/> <xs:element name="topRight" type="pointType"/>

<xs:simpleType name="mobilityType"> <xs:restriction base="xs:string"> <xs:enumeration value="static" /> <xs:enumeration value="dynamic" /> <xs:enumeration value="highly-dynamic" />

<xs:complexType name="textCaptureType"> xs:complexContent <xs:extension base="tns:mediaCaptureType"> xs:sequence <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

<xs:complexType name="otherCaptureType"> xs:complexContent <xs:extension base="tns:mediaCaptureType"> xs:sequence <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

<xs:complexType name="audioCaptureType"> xs:complexContent <xs:extension base="tns:mediaCaptureType"> xs:sequence <xs:element ref="sensitivityPattern" minOccurs="0" /> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

<xs:element name="sensitivityPattern" type="xs:string"> xs:annotation xs:documentation Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <sensitivityPattern>" registry, accessible at https://www.iana.org/assignments/clue.

<xs:complexType name="videoCaptureType"> xs:complexContent <xs:extension base="tns:mediaCaptureType"> xs:sequence <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

<xs:element name="embeddedText"> xs:complexType xs:simpleContent <xs:extension base="xs:boolean"> <xs:attribute name="lang" type="xs:language"/>

<xs:complexType name="captureScenesType"> xs:sequence <xs:element name="captureScene" type="captureSceneType" maxOccurs="unbounded"/>

<xs:complexType name="captureSceneType"> xs:sequence <xs:element ref="description" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="sceneInformation" type="xcard:vcardType" minOccurs="0"/> <xs:element name="sceneViews" type="sceneViewsType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="sceneID" type="xs:ID" use="required"/> <xs:attribute name="scale" type="scaleType" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

<xs:simpleType name="scaleType"> <xs:restriction base="xs:string"> <xs:enumeration value="mm"/> <xs:enumeration value="unknown"/> <xs:enumeration value="noscale"/>

<xs:complexType name="sceneViewsType"> xs:sequence <xs:element name="sceneView" type="sceneViewType" maxOccurs="unbounded"/>

<xs:complexType name="sceneViewType"> xs:sequence <xs:element ref="description" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="mediaCaptureIDs" type="captureIDListType"/> <xs:attribute name="sceneViewID" type="xs:ID" use="required"/>

<xs:complexType name="captureIDListType"> xs:sequence <xs:element name="mediaCaptureIDREF" type="xs:IDREF" maxOccurs="unbounded"/>

<xs:complexType name="encodingGroupsType"> xs:sequence <xs:element name="encodingGroup" type="tns:encodingGroupType" maxOccurs="unbounded"/>

<xs:complexType name="encodingGroupType"> xs:sequence <xs:element name="maxGroupBandwidth" type="xs:unsignedLong"/> <xs:element name="encodingIDList" type="encodingIDListType"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="encodingGroupID" type="xs:ID" use="required"/> <xs:anyAttribute namespace="##any" processContents="lax"/>

<xs:complexType name="encodingIDListType"> xs:sequence <xs:element name="encodingID" type="xs:string" maxOccurs="unbounded"/>

<xs:complexType name="simultaneousSetsType"> xs:sequence <xs:element name="simultaneousSet" type="simultaneousSetType" maxOccurs="unbounded"/>

<xs:complexType name="simultaneousSetType"> xs:sequence <xs:element name="mediaCaptureIDREF" type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="sceneViewIDREF" type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="captureSceneIDREF" type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="setID" type="xs:ID" use="required"/> <xs:attribute name="mediaType" type="xs:string"/> <xs:anyAttribute namespace="##any" processContents="lax"/>

<xs:complexType name="globalViewsType"> xs:sequence <xs:element name="globalView" type="globalViewType" maxOccurs="unbounded"/>

<xs:complexType name="globalViewType"> xs:sequence <xs:element name="sceneViewIDREF" type="xs:IDREF" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="globalViewID" type="xs:ID"/> <xs:anyAttribute namespace="##any" processContents="lax"/>

<xs:complexType name="captureEncodingsType"> xs:sequence <xs:element name="captureEncoding" type="captureEncodingType" maxOccurs="unbounded"/>

<xs:complexType name="captureEncodingType"> xs:sequence <xs:element name="captureID" type="xs:string"/> <xs:element name="encodingID" type="xs:string"/> <xs:element name="configuredContent" type="contentType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="ID" type="xs:ID" use="required"/> <xs:anyAttribute namespace="##any" processContents="lax"/>

<xs:element name="clueInfo" type="clueInfoType"/>

<xs:complexType name="clueInfoType"> xs:sequence <xs:element ref="mediaCaptures"/> <xs:element ref="encodingGroups"/> <xs:element ref="captureScenes"/> <xs:element ref="simultaneousSets" minOccurs="0"/> <xs:element ref="globalViews" minOccurs="0"/> <xs:element ref="people" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="clueInfoID" type="xs:ID" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

The following sections describe the XML schema in more detail. As a general remark, please notice that optional elements that don't define what their absence means are intended to be associated with undefined properties.

6.

represents the list of the encoding groups organized on the Media Provider's side. Each encoding group is represented by an element (Section 18).

7.

represents the list of the capture scenes organized on the Media Provider's side. Each capture scene is represented by a element (Section 16).

8.

contains the simultaneous sets indicated by the Media Provider. Each simultaneous set is represented by a element (Section 19).

9.

contains a set of alternative representations of all the scenes that are offered by a Media Provider to a Media Consumer. Each alternative is named "global view", and it is represented by a element (Section 20).

10.

is a list of capture encodings. It can represent the list of the desired capture encodings indicated by the Media Consumer or the list of instantiated captures on the provider's side. Each capture encoding is represented by a element (Section 22).

12. Audio Captures

Audio captures inherit all the features of a generic media capture and present further audio-specific characteristics. The XML schema definition of the audio capture type is reported below:

<xs:complexType name="audioCaptureType"> xs:complexContent <xs:extension base="tns:mediaCaptureType"> xs:sequence <xs:element ref="sensitivityPattern" minOccurs="0" /> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

An example of audio-specific information that can be included is represented by the element (Section 12.1).

12.1.

The element is an optional field describing the characteristics of the nominal sensitivity pattern of the microphone capturing the audio signal. It has been specified as a simple string with an annotation pointing to an IANA registry that is defined ad hoc:

<xs:element name="sensitivityPattern" type="xs:string"> xs:annotation xs:documentation Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <sensitivityPattern>" registry, accessible at https://www.iana.org/assignments/clue.

The current possible values, as per the CLUE framework document[RFC8845], are "uni", "shotgun", "omni", "figure8", "cardioid", and "hyper-cardioid".

13. Video Captures

Video captures, similarly to audio captures, extend the information of a generic media capture with video-specific features.

The XML schema representation of the video capture type is provided in the following:

<xs:complexType name="videoCaptureType"> xs:complexContent <xs:extension base="tns:mediaCaptureType"> xs:sequence <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

14. Text Captures

Similar to audio captures and video captures, text captures can be described by extending the generic media capture information.

There are no known properties of a text-based media that aren't already covered by the generic mediaCaptureType. Text captures are hence defined as follows:

<xs:complexType name="textCaptureType"> xs:complexContent <xs:extension base="tns:mediaCaptureType"> xs:sequence <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

Text captures MUST be marked as non spatially definable (i.e., theyMUST present in their XML description the (Section 11.6) element set to "true").

15. Other Capture Types

Other media capture types can be described by using the CLUE data model. They can be represented by exploiting the "otherCaptureType" type. This media capture type is conceived to be filled in with elements defined within extensions of the current schema, i.e., with elements defined in other XML schemas (see Section 24 for an example). The otherCaptureType inherits all the features envisioned for the abstract mediaCaptureType.

The XML schema representation of the otherCaptureType is the following:

<xs:complexType name="otherCaptureType"> xs:complexContent <xs:extension base="tns:mediaCaptureType"> xs:sequence <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

When defining new media capture types that are going to be described by means of the element, spatial properties of such new media capture types SHOULD be defined (e.g., whether or not they are spatially definable and whether or not they should be associated with an area of capture or other properties that may be defined).

16.

A Media Provider organizes the available captures in capture scenes in order to help the receiver in both the rendering and the selection of the group of captures. Capture scenes are made of media captures and capture scene views, which are sets of media captures of the same media type. Each capture scene view is an alternative to completely represent a capture scene for a fixed media type.

The XML schema representation of a element is the following:

<xs:complexType name="captureSceneType"> xs:sequence <xs:element ref="description" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="sceneInformation" type="xcard:vcardType" minOccurs="0"/> <xs:element name="sceneViews" type="sceneViewsType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="sceneID" type="xs:ID" use="required"/> <xs:attribute name="scale" type="scaleType" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

Each capture scene is identified by a "sceneID" attribute. The element can contain zero or more textual elements, as defined in Section 11.13. Besides , there is the optional element (Section 16.1), which contains structured information about the scene in the vCard format, and the optional element (Section 16.2), which is the list of the capture scene views. When no is provided, the capture scene is assumed to be made of all the media captures that contain the value of its sceneID attribute in their mandatory captureSceneIDREF attribute.

16.1.

The element contains optional information about the capture scene according to the vCard format, as specified in the xCard specification [RFC6351].

16.2.

The element is a mandatory field of a capture scene containing the list of scene views. Each scene view is represented by a element (Section 17).

<xs:complexType name="sceneViewsType"> xs:sequence <xs:element name="sceneView" type="sceneViewType" maxOccurs="unbounded"/>

16.3. sceneID Attribute

The sceneID attribute is a mandatory attribute containing the identifier of the capture scene.

16.4. scale Attribute

The scale attribute is a mandatory attribute that specifies the scale of the coordinates provided in the spatial information of the media capture belonging to the considered capture scene. The scale attribute can assume three different values:

<xs:simpleType name="scaleType"> <xs:restriction base="xs:string"> <xs:enumeration value="mm"/> <xs:enumeration value="unknown"/> <xs:enumeration value="noscale"/>

17.

A element represents a capture scene view, which contains a set of media captures of the same media type describing a capture scene.

A element is characterized as follows.

<xs:complexType name="sceneViewType"> xs:sequence <xs:element ref="description" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="mediaCaptureIDs" type="captureIDListType"/> <xs:attribute name="sceneViewID" type="xs:ID" use="required"/>

One or more optional elements provide human-readable information about what the scene view contains. is defined in Section 11.13.

The remaining child elements are described in the following subsections.

17.1.

is the list of the identifiers of the media captures included in the scene view. It is an element of the captureIDListType type, which is defined as a sequence of , each containing the identifier of a media capture listed within the element:

<xs:complexType name="captureIDListType"> xs:sequence <xs:element name="mediaCaptureIDREF" type="xs:IDREF" maxOccurs="unbounded"/>

17.2. sceneViewID Attribute

The sceneViewID attribute is a mandatory attribute containing the identifier of the capture scene view represented by the element.

18.

The element represents an encoding group, which is made by a set of one or more individual encodings and some parameters that apply to the group as a whole. Encoding groups contain references to individual encodings that can be applied to media captures. The definition of the element is the following:

<xs:complexType name="encodingGroupType"> xs:sequence <xs:element name="maxGroupBandwidth" type="xs:unsignedLong"/> <xs:element name="encodingIDList" type="encodingIDListType"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="encodingGroupID" type="xs:ID" use="required"/> <xs:anyAttribute namespace="##any" processContents="lax"/>

In the following subsections, the contained elements are further described.

18.1.

is an optional field containing the maximum bitrate expressed in bits per second that can be shared by the individual encodings included in the encoding group.

18.2.

is the list of the individual encodings grouped together in the encoding group. Each individual encoding is represented through its identifier contained within an element.

<xs:complexType name="encodingIDListType"> xs:sequence <xs:element name="encodingID" type="xs:string" maxOccurs="unbounded"/>

18.3. encodingGroupID Attribute

The encodingGroupID attribute contains the identifier of the encoding group.

19.

represents a simultaneous transmission set, i.e., a list of captures of the same media type that can be transmitted at the same time by a Media Provider. There are different simultaneous transmission sets for each media type.

<xs:complexType name="simultaneousSetType"> xs:sequence <xs:element name="mediaCaptureIDREF" type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="sceneViewIDREF" type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="captureSceneIDREF" type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="setID" type="xs:ID" use="required"/> <xs:attribute name="mediaType" type="xs:string"/> <xs:anyAttribute namespace="##any" processContents="lax"/>

Besides the identifiers of the captures ( elements), the identifiers of capture scene views and capture scenes can also be exploited as shortcuts ( and elements). As an example, let's consider the situation where there are two capture scene views (S1 and S7). S1 contains captures AC11, AC12, and AC13. S7 contains captures AC71 and AC72. Provided that AC11, AC12, AC13, AC71, and AC72 can be simultaneously sent to the Media Consumer, instead of having 5 elements listed in the simultaneous set (i.e., one for AC11, one for AC12, and so on), there can be just two elements (one for S1 and one for S7).

19.1. setID Attribute

The "setID" attribute is a mandatory field containing the identifier of the simultaneous set.

19.2. mediaType Attribute

The "mediaType" attribute is an optional attribute containing the media type of the captures referenced by the simultaneous set.

When only capture scene identifiers are listed within a simultaneous set, the media type attribute MUST appear in the XML description in order to determine which media captures can be simultaneously sent together.

19.3.

contains the identifier of the media capture that belongs to the simultaneous set.

19.4.

contains the identifier of the scene view containing a group of captures that are able to be sent simultaneously with the other captures of the simultaneous set.

19.5.

contains the identifier of the capture scene where all the included captures of a certain media type are able to be sent together with the other captures of the simultaneous set.

20.

is a set of captures of the same media type representing a summary of the complete Media Provider's offer. The content of a global view is expressed by leveraging only scene view identifiers, put within elements. Each global view is identified by a unique identifier within the "globalViewID" attribute.

<xs:complexType name="globalViewType"> xs:sequence <xs:element name="sceneViewIDREF" type="xs:IDREF" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="globalViewID" type="xs:ID"/> <xs:anyAttribute namespace="##any" processContents="lax"/>

21.

Information about the participants that are represented in the media captures is conveyed via the element. As it can be seen from the XML schema depicted below, for each participant, a element is provided.

<xs:complexType name="peopleType"> xs:sequence <xs:element name="person" type="personType" maxOccurs="unbounded"/>

21.1.

includes all the metadata related to a person represented within one or more media captures. Such element provides the vCard of the subject (via the element; see Section 21.1.2) and its conference role(s) (via one or more elements; see Section 21.1.3). Furthermore, it has a mandatory "personID" attribute (Section 21.1.1).

<xs:complexType name="personType"> xs:sequence <xs:element name="personInfo" type="xcard:vcardType" maxOccurs="1" minOccurs="0"/> <xs:element ref="personType" minOccurs="0" maxOccurs="unbounded" /> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="personID" type="xs:ID" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

21.1.1. personID Attribute

The "personID" attribute carries the identifier of a represented person. Such an identifier can be used to refer to the participant, as in the element in the media captures representation (Section 11.21).

21.1.2.

The element is the XML representation of all the fields composing a vCard as specified in the xCard document [RFC6351]. The vcardType is imported by the xCard XML schema provided in Appendix A of [RFC7852]. As such schema specifies, the element within is mandatory.

21.1.3.

The value of the element determines the role of the represented participant within the telepresence session organization. It has been specified as a simple string with an annotation pointing to an IANA registry that is defined ad hoc:

<xs:element name="personType" type="xs:string"> xs:annotation xs:documentation Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <personType>" registry, accessible at https://www.iana.org/assignments/clue.

The current possible values, as per the CLUE framework document[RFC8845], are: "presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice-chairman", and "observer".

A participant can play more than one conference role. In that case, more than one element will appear in its description.

22.

A capture encoding is given from the association of a media capture with an individual encoding, to form a capture stream as defined in[RFC8845]. Capture encodings are used within CONFIGURE messages from a Media Consumer to a Media Provider for representing the streams desired by the Media Consumer. For each desired stream, the Media Consumer needs to be allowed to specify: (i) the capture identifier of the desired capture that has been advertised by the Media Provider; (ii) the encoding identifier of the encoding to use, among those advertised by the Media Provider; and (iii) optionally, in case of multicontent captures, the list of the capture identifiers of the desired captures. All the mentioned identifiers are intended to be included in the ADVERTISEMENT message that the CONFIGURE message refers to. The XML model of is provided in the following.

<xs:complexType name="captureEncodingType"> xs:sequence <xs:element name="captureID" type="xs:string"/> <xs:element name="encodingID" type="xs:string"/> <xs:element name="configuredContent" type="contentType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="ID" type="xs:ID" use="required"/> <xs:anyAttribute namespace="##any" processContents="lax"/>

22.1.

is the mandatory element containing the identifier of the media capture that has been encoded to form the capture encoding.

22.2.

is the mandatory element containing the identifier of the applied individual encoding.

22.3.

is an optional element to be used in case of the configuration of MCC. It contains the list of capture identifiers and capture scene view identifiers the Media Consumer wants within the MCC. That element is structured as the element used to describe the content of an MCC. The total number of media captures listed in the MUST be lower than or equal to the value carried within the attribute of the MCC.

23.

The element includes all the information needed to represent the Media Provider's description of its telepresence capabilities according to the CLUE framework. Indeed, it is made by:

It has been conceived only for data model testing purposes, and though it resembles the body of an ADVERTISEMENT message, it is not actually used in the CLUE protocol message definitions. The telepresence capabilities descriptions compliant to this data model specification that can be found in Sections27 and 28are provided by using the element.

<xs:complexType name="clueInfoType"> xs:sequence <xs:element ref="mediaCaptures"/> <xs:element ref="encodingGroups"/> <xs:element ref="captureScenes"/> <xs:element ref="simultaneousSets" minOccurs="0"/> <xs:element ref="globalViews" minOccurs="0"/> <xs:element ref="people" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="clueInfoID" type="xs:ID" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

24. XML Schema Extensibility

The telepresence data model defined in this document is meant to be extensible. Extensions are accomplished by defining elements or attributes qualified by namespaces other than "urn:ietf:params:xml:ns:clue-info" and "urn:ietf:params:xml:ns:vcard-4.0" for use wherever the schema allows such extensions (i.e., where the XML schema definition specifies "anyAttribute" or "anyElement"). Elements or attributes from unknown namespaces MUST be ignored. Extensibility was purposefully favored as much as possible based on expectations about custom implementations. Hence, the schema offers people enough flexibility as to define custom extensions, without losing compliance with the standard. This is achieved by leveraging xs:any elements and xs:anyAttribute attributes, which is a common approach with schemas, while still matching the Unique Particle Attribution (UPA) constraint.

24.1. Example of Extension

When extending the CLUE data model, a new schema with a new namespace associated with it needs to be specified.

In the following, an example of extension is provided. The extension defines a new audio capture attribute ("newAudioFeature") and an attribute for characterizing the captures belonging to an "otherCaptureType" defined by the user. An XML document compliant with the extension is also included. The XML file results are validated against the current XML schema for the CLUE data model.

<xs:schema targetNamespace="urn:ietf:params:xml:ns:clue-info-ext" xmlns:tns="urn:ietf:params:xml:ns:clue-info-ext" xmlns:clue-ext="urn:ietf:params:xml:ns:clue-info-ext" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:clue-info-ext" xmlns:xcard="urn:ietf:params:xml:ns:vcard-4.0" xmlns:info="urn:ietf:params:xml:ns:clue-info" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0" schemaLocation= "https://www.iana.org/assignments/xml-registry/schema/ vcard-4.0.xsd"/>

<xs:import namespace="urn:ietf:params:xml:ns:clue-info" schemaLocation="clue-data-model-schema.xsd"/>

<xs:element name="newAudioFeature" type="xs:string"/> <xs:element name="otherMediaCaptureTypeFeature" type="xs:string"/>

CS1 true true EG1 ns3:newAudioFeaturenewAudioFeatureValue CS1 true EG1 ns3:otherMediaCaptureTypeFeatureOtherValue 300000 ENC4 ENC5

25. Security Considerations

This document defines, through an XML schema, a data model for telepresence scenarios. The modeled information is identified in the CLUE framework as necessary in order to enable a full-fledged media stream negotiation and rendering. Indeed, the XML elements herein defined are used within CLUE protocol messages to describe both the media streams representing the Media Provider's telepresence offer and the desired selection requested by the Media Consumer. Security concerns described in [RFC8845], Section 15 apply to this document.

Data model information carried within CLUE messages SHOULDbe accessed only by authenticated endpoints. Indeed, authenticated access is strongly advisable, especially if you convey information about individuals () and/or scenes (). There might be more exceptions, depending on the level of criticality that is associated with the setup and configuration of a specific session. In principle, one might even decide that no protection at all is needed for a particular session; here is why authentication has not been identified as a mandatory requirement.

Going deeper into details, some information published by the Media Provider might reveal sensitive data about who and what is represented in the transmitted streams. The vCard included in the elements (Section 21.1) mandatorily contains the identity of the represented person. Optionally, vCards can also carry the person's contact addresses, together with their photo and other personal data. Similar privacy-critical information can be conveyed by means of elements (Section 16.1) describing the capture scenes. The elements (Section 11.13) also can specify details about the content of media captures, capture scenes, and scene views that should be protected.

Integrity attacks to the data model information encapsulated in CLUE messages can invalidate the success of the telepresence session's setup by misleading the Media Consumer's and Media Provider's interpretation of the offered and desired media streams.

The assurance of the authenticated access and of the integrity of the data model information is up to the involved transport mechanisms, namely the CLUE protocol[RFC8847]and the CLUE data channel [RFC8850].

XML parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining privileges of the user running the XML parser. In an extreme situation, the entire machine could be compromised.

26. IANA Considerations

This document registers a new XML namespace, a new XML schema, the media type for the schema, and four new registries associated, respectively, with acceptable , , , and values.

26.1. XML Namespace Registration

URI:

urn:ietf:params:xml:ns:clue-info

Registrant Contact:

IETF CLUE Working Group clue@ietf.org, Roberta Presta roberta.presta@unina.it

XML:

CLUE Data Model Namespace

Namespace for CLUE Data Model

urn:ietf:params:xml:ns:clue-info

See RFC 8846.

26.2. XML Schema Registration

This section registers an XML schema per the guidelines in [RFC3688].

URI:

urn:ietf:params:xml:schema:clue-info

Registrant Contact:

CLUE Working Group (clue@ietf.org), Roberta Presta (roberta.presta@unina.it).

Schema:

The XML for this schema can be found in its entirety inSection 4 of this document.

26.3. Media Type Registration for "application/clue_info+xml"

This section registers the "application/clue_info+xml" media type.

To:

ietf-types@iana.org

Subject:

Registration of media type application/clue_info+xml

Type name:

application

Subtype name:

clue_info+xml

Required parameters:

(none)

Optional parameters:

charset Same as the charset parameter of "application/xml" as specified in[RFC7303], Section 3.2.

Encoding considerations:

Same as the encoding considerations of "application/xml" as specified in [RFC7303], Section 3.2.

Security considerations:

This content type is designed to carry data related to telepresence information. Some of the data could be considered private. This media type does not provide any protection and thus other mechanisms such as those described in Section 25are required to protect the data. This media type does not contain executable content.

Interoperability considerations:

None.

Published specification:

RFC 8846

Applications that use this media type:

CLUE-capable telepresence systems.

Additional Information:

Magic Number(s):

none

File extension(s):

.clue

Macintosh File Type Code(s):

TEXT

Person & email address to contact for further information:

Roberta Presta (roberta.presta@unina.it).

Intended usage:

LIMITED USE

Author/Change controller:

The IETF

Other information:

This media type is a specialization of "application/xml" [RFC7303], and many of the considerations described there also apply to "application/clue_info+xml".

26.4. Registry for Acceptable Values

IANA has created a registry of acceptable values for the tag as defined in Section 11.18. The initial values for this registry are "room", "table", "lectern", "individual", and "audience".

New values are assigned by Expert Review per [RFC8126]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting.

26.5. Registry for Acceptable Values

IANA has created a registry of acceptable values for the tag as defined in Section 11.19. The initial values for this registry are "slides" and "images".

New values are assigned by Expert Review per [RFC8126]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting.

26.6. Registry for Acceptable Values

IANA has created a registry of acceptable values for the tag as defined in Section 12.1. The initial values for this registry are "uni", "shotgun", "omni", "figure8", "cardioid", and "hyper-cardioid".

New values are assigned by Expert Review per [RFC8126]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting.

26.7. Registry for Acceptable Values

IANA has created a registry of acceptable values for the tag as defined in Section 21.1.3. The initial values for this registry are "presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice-chairman", and "observer".

New values are assigned by Expert Review per [RFC8126]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting.

27. Sample XML File

The following XML document represents a schema-compliant example of a CLUE telepresence scenario. Taking inspiration from the examples described in the framework specification [RFC8845], the XML representation of an endpoint-style Media Provider's ADVERTISEMENT is provided.

There are three cameras, where the central one is also capable of capturing a zoomed-out view of the overall telepresence room. Besides the three video captures coming from the cameras, the Media Provider makes available a further multicontent capture of the loudest segment of the room, obtained by switching the video source across the three cameras. For the sake of simplicity, only one audio capture is advertised for the audio of the whole room.

The three cameras are placed in front of three participants (Alice, Bob, and Ciccio), whose vCard and conference role details are also provided.

Media captures are arranged into four capture scene views:

  1. (VC0, VC1, VC2) - left, center, and right camera video captures
  2. (VC3) - video capture associated with loudest room segment
  3. (VC4) - video capture zoomed-out view of all people in the room
  4. (AC0) - main audio

There are two encoding groups: (i) EG0, for video encodings, and (ii) EG1, for audio encodings.

As to the simultaneous sets, VC1 and VC4 cannot be transmitted simultaneously since they are captured by the same device, i.e., the central camera (VC4 is a zoomed-out view while VC1 is a focused view of the front participant). On the other hand, VC3 and VC4 cannot be simultaneous either, since VC3, the loudest segment of the room, might be at a certain point in time focusing on the central part of the room, i.e., the same as VC1. The simultaneous sets would then be the following:

  • SS1:
    made by VC3 and all the captures in the first capture scene view (VC0,VC1,and VC2)
    SS2:
    made by VC0, VC2, and VC4

CS1 0.0 0.0 10.0 0.0 1.0 10.0 true EG1 main audio from the room 1 it static room alice bob ciccio CS1 -2.0 0.0 10.0 -3.0 20.0 9.0 -1.0 20.0 9.0 -3.0 20.0 11.0 -1.0 20.0 11.0 true EG0 left camera video capture 1 it static individual ciccio CS1 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 true EG0 central camera video capture 1 it static individual alice CS1 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 20.0 11.0 true EG0 right camera video capture 1 it static individual bob CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:0 EG0 loudest room segment 2 it static individual CS1 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 true EG0 zoomed-out view of all people in the room 2 it static room alice bob ciccio 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 VC0 VC1 VC2 VC3 VC4 AC0 VC3 SE1 VC0 VC2 VC4 ns2:fn ns2:textBob minute taker ns2:fn ns2:textAlice presenter ns2:fn ns2:textCiccio chairman timekeeper

28. MCC Example

Enhancing the scenario presented in the previous example, the Media Provider is able to advertise a composed capture VC7 made by a big picture representing the current speaker (VC3) and two picture-in-picture boxes representing the previous speakers (the previous one, VC5, and the oldest one, VC6). The provider does not want to instantiate and send VC5 and VC6, so it does not associate any encoding group with them. Their XML representations are provided for enabling the description of VC7.

A possible description for that scenario could be the following:

CS1 0.0 0.0 10.0 0.0 1.0 10.0 true EG1 main audio from the room 1 it static room alice bob ciccio CS1 0.5 1.0 0.5 0.5 0.0 0.5 true EG0 left camera video capture 1 it static individual ciccio CS1 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 true EG0 central camera video capture 1 it static individual alice CS1 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 20.0 11.0 true EG0 right camera video capture 1 it static individual bob CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:0 EG0 loudest room segment 2 it static individual CS1 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 true EG0 zoomed-out view of all people in the room 2 it static room alice bob ciccio CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:1 previous loudest room segment per the most recent iteration of the sound level detection algorithm it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:2 previous loudest room segment per the second most recent iteration of the sound level detection algorithm it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 VC3 VC5 VC6 3 EG0 big picture of the current speaker + pips about previous speakers 3 it static individual 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 participants' individual videos VC0 VC1 VC2 loudest segment of the room VC3 loudest segment of the room + pips VC7 room audio AC0 room video VC4 VC3 VC7 SE1 VC0 VC2 VC4 ns2:fn ns2:textBob minute taker ns2:fn ns2:textAlice presenter ns2:fn ns2:textCiccio chairman timekeeper

29. References

29.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5646]

Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.

[RFC6351]

Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011, <https://www.rfc-editor.org/info/rfc6351>.

[RFC7303]

Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <https://www.rfc-editor.org/info/rfc7303>.

[RFC7852]

Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, <https://www.rfc-editor.org/info/rfc7852>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8845]

Duckworth, M., Ed., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", RFC 8845, DOI 10.17487/RFC8845, January 2021, <https://www.rfc-editor.org/info/rfc8845>.

[RFC8847]

Presta, R. and S P. Romano, "Protocol for Controlling Multiple Streams for Telepresence (CLUE)", RFC 8847, DOI 10.17487/RFC8847, January 2021, <https://www.rfc-editor.org/info/rfc8847>.

[RFC8850]

Holmberg, C., "Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel", RFC 8850, DOI 10.17487/RFC8850, January 2021, <https://www.rfc-editor.org/info/rfc8850>.

29.2. Informative References

[RFC3550]

Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC3688]

Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC4353]

Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <https://www.rfc-editor.org/info/rfc4353>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC7667]

Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <https://www.rfc-editor.org/info/rfc7667>.

Acknowledgements

The authors thank all the CLUE contributors for their valuable feedback and support. Thanks also to Alissa Cooper, whose AD review helped us improve the quality of the document.

Authors' Addresses

Roberta Presta

University of Napoli

Via Claudio 21

80125 Napoli

Italy

Simon Pietro Romano

University of Napoli

Via Claudio 21

80125 Napoli

Italy