RFC 8846: An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model
- R. Presta,
- S P. Romano
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 at
https://
Copyright Notice
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://
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.¶
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.¶
5. <mediaCaptures>
<mediaCaptures> represents the list of one or more media captures available at the Media Provider's side. Each media capture is represented by a <mediaCapture> element (Section 11).¶
6. <encodingGroups>
<encoding
7. <captureScenes>
<captureScenes> represents the list of the capture scenes organized on the Media Provider's side. Each capture scene is represented by a <captureScene> element (Section 16).¶
8. <simultaneousSets>
<simultaneous
9. <globalViews>
<globalViews> 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 <globalView> element (Section 20).¶
10. <captureEncodings>
<capture
11. <mediaCapture>
A media capture is the
fundamental representation of a media flow
that is available on the provider's side.
Media captures are characterized by (i) a set of features
that are independent from the specific type of medium
and (ii) a set of features that are media specific.
The features that are common to all media types appear within
the media capture type, which has been designed as an abstract
complex type.
Media-specific captures, such as video captures,
audio captures, and others, are specializations of that abstract
media capture type, as in a typical generalization
The following is the XML schema definition of the media capture type:¶
11.1. captureID Attribute
The "captureID" attribute is a mandatory field
containing the identifier of the media capture.
Such an identifier serves as the way the capture is referenced from
other data model elements (e.g., simultaneous sets, capture encodings,
and others via <media
11.2. mediaType Attribute
The "mediaType" attribute is a mandatory attribute specifying
the media type of the capture.
Common standard values are "audio", "video", and "text", as defined in
[RFC6838].
Other values can be provided. It is assumed that implementations agree
on the interpretation of those other values.
The "mediaType" attribute is as generic as possible. Here is why: (i)
the basic media capture type is an abstract one; (ii) "concrete"
definitions for the standard audio, video,
and text capture types [RFC6838] have been specified; (iii) a generic
"other
11.3. <captureSceneIDREF>
<capture
11.4. <encGroupIDREF>
<encGroupIDREF> is an optional field containing the identifier of the encoding group the media capture is associated with, i.e., the value of the encodingGroupID attribute (Section 18.3) of that encoding group. Media captures that are not associated with any encoding group cannot be instantiated as media streams.¶
11.5. <spatialInformation>
Media captures are divided into two categories: (i) non spatially definable captures and (ii) spatially definable captures.¶
Captures are spatially definable when at least it is possible to provide (i) the coordinates of the device position within the telepresence room of origin (capture point) together with its capturing direction specified by a second point (point on line of capture) or (ii) the represented area within the telepresence room, by listing the coordinates of the four coplanar points identifying the plane of interest (area of capture). The coordinates of the above mentioned points MUST be expressed according to the coordinate space of the capture scene the media captures belong to.¶
Non spatially definable captures cannot be characterized within the physical space of the telepresence room of origin. Captures of this kind are, for example, those related to recordings, text captures, DVDs, registered presentations, or external streams that are played in the telepresence room and transmitted to remote sites.¶
Spatially definable captures represent a
part of the telepresence room.
The captured part of the telepresence room is described
by means of the <spatial
The definition of the spatial information type is the following:¶
The <captureOrigin> contains the coordinates of the capture device that is taking the capture (i.e., the capture point) as well as, optionally, the pointing direction (i.e., the point on line of capture); see Section 11.5.1.¶
The <captureArea> is an optional field containing four points defining the captured area covered by the capture (see Section 11.5.2).¶
The scale of the points coordinates is specified in the scale attribute (Section 16.4) of the capture scene the media capture belongs to. Indeed, all the spatially definable media captures referring to the same capture scene share the same coordinate system and express their spatial information according to the same scale.¶
11.5.1. <captureOrigin>
The <captureOrigin> element is used to represent the position and optionally the line of capture of a capture device. <captureOrigin> MUST be included in spatially definable audio captures, while it is optional for spatially definable video captures.¶
The XML schema definition of the <captureOrigin> element type is the following:¶
The point type contains three spatial coordinates (x,y,z) representing a point in the space associated with a certain capture scene.¶
The <captureOrigin> element includes a
mandatory <capturePoint> element and an optional
<line
The coordinates of the point on line of capture
MUST NOT be identical to the capture point coordinates.
For a spatially definable video capture, if the point on line of capture
is provided, it MUST belong to the region between
the point of capture and the capture area.
For a spatially definable audio capture,
if the point on line of capture is not provided,
the sensitivity pattern should be considered omnidirectional
11.5.2. <captureArea>
<captureArea> is an optional element that can be contained within the spatial information associated with a media capture. It represents the spatial area captured by the media capture. <captureArea> MUST be included in the spatial information of spatially definable video captures, while it MUST NOT be associated with audio captures.¶
The XML representation of that area is provided through a set of four point-type elements, <bottomLeft>, <bottomRight>, <topLeft>, and <topRight>, that MUST be coplanar. The four coplanar points are identified from the perspective of the capture device. The XML schema definition is the following:¶
11.6. <nonSpatiallyDefinable>
When media captures are non spatially definable,
they MUST be marked with the boolean
<non
11.7. <content>
A media capture can be (i) an individual media capture or (ii)
an MCC.
An MCC is made by different captures
that can be arranged spatially
(by a composition operation), or temporally (by a switching operation),
or that can result from
the orchestration of both the techniques.
If a media capture is an MCC, then it MAY show in its XML
data model representation the
<content> element. It is composed by a list of media
capture identifiers
11.8. <synchronizationID>
<synchronization
11.9. <allowSubsetChoice>
<allow
11.10. <policy>
<policy> is an optional element
that can be used only for multiple content captures.
It indicates the criteria applied to build the multiple content capture
using the media captures referenced in the <media
At the time of writing, only two switching policies are defined; they are in [RFC8845] as follows:¶
- SoundLevel:
- This indicates that the content of the MCC is determined by a sound
-level -detection algorithm. The loudest (active) speaker (or a previous speaker, depending on the index value) is contained in the MCC.¶ - RoundRobin:
- This indicates that the content of the MCC is determined by a time-based algorithm. For example, the Provider provides content from a particular source for a period of time and then provides content from another source, and so on.¶
Other values for the <policy> element can be used. In this case, it is assumed that implementations agree on the meaning of those other values and/or those new switching policies are defined in later documents.¶
11.11. <maxCaptures>
<maxCaptures> is an optional element that can be used only for MCCs. It provides information about the number of media captures that can be represented in the multiple content capture at a time. If <maxCaptures> is not provided, all the media captures listed in the <content> element can appear at a time in the capture encoding. The type definition is provided below.¶
When the "exactNumber" attribute is set to "true", it means the <maxCaptures> element carries the exact number of the media captures appearing at a time. Otherwise, the number of the represented media captures MUST be considered "<=" the <maxCaptures> value.¶
For instance, an audio MCC having the <maxCaptures> value set to 1 means that a media stream from the MCC will only contain audio from a single one of its constituent captures at a time. On the other hand, if the <maxCaptures> value is set to 4 and the exactNumber attribute is set to "true", it would mean that the media stream received from the MCC will always contain a mix of audio from exactly four of its constituent captures.¶
11.12. <individual>
<individual> is a boolean element that MUST be used for single-content captures. Its value is fixed and set to "true". Such element indicates the capture that is being described is not an MCC. Indeed, <individual> and the aforementioned tags related to MCC attributes (from Sections 11.7 to 11.11) are mutually exclusive, according to the <choice> section within the XML schema definition of the media capture type.¶
11.13. <description>
<description> is used to provide human-readable textual information. This element is included in the XML definition of media captures, capture scenes, and capture scene views to provide human-readable descriptions of, respectively, media captures, capture scenes, and capture scene views. According to the data model definition of a media capture (Section 11)), zero or more <description> elements can be used, each providing information in a different language. The <description> element definition is the following:¶
As can be seen, <description> is a string element with an attribute ("lang") indicating the language used in the textual description. Such an attribute is compliant with the Language-Tag ABNF production from [RFC5646].¶
11.14. <priority>
<priority> is an optional unsigned integer field indicating the importance of a media capture according to the Media Provider's perspective. It can be used on the receiver's side to automatically identify the most relevant contribution from the Media Provider. The higher the importance, the lower the contained value. If no priority is assigned, no assumptions regarding relative importance of the media capture can be assumed.¶
11.15. <lang>
<lang> is an optional element containing the language used in the capture. Zero or more <lang> elements can appear in the XML description of a media capture. Each such element has to be compliant with the Language-Tag ABNF production from [RFC5646].¶
11.16. <mobility>
<mobility> is an optional element indicating whether or not the capture device originating the capture may move during the telepresence session. That optional element can assume one of the three following values:¶
11.17. <relatedTo>
The optional <relatedTo> element contains the value of the captureID attribute (Section 11.1) of the media capture to which the considered media capture refers. The media capture marked with a <relatedTo> element can be, for example, the translation of the referred media capture in a different language.¶
11.18. <view>
The <view> element is an optional tag describing what is represented in the spatial area covered by a media capture. It has been specified as a simple string with an annotation pointing to an IANA registry that is defined ad hoc:¶
The current possible values, as per the CLUE framework document [RFC8845], are: "room", "table", "lectern", "individual", and "audience".¶
11.19. <presentation>
The <presentation> element is an optional tag used for media captures conveying information about presentations within the telepresence session. It has been specified as a simple string with an annotation pointing to an IANA registry that is defined ad hoc:¶
The current possible values, as per the CLUE framework document [RFC8845], are "slides" and "images".¶
11.20. <embeddedText>
The <embeddedText> element is a boolean element indicating that there is text embedded in the media capture (e.g., in a video capture). The language used in such an embedded textual description is reported in the <embeddedText> "lang" attribute.¶
The XML schema definition of the <embeddedText> element is:¶
11.21. <capturedPeople>
This optional element is used to indicate which telepresence session participants are represented in within the media captures. For each participant, a <personIDREF> element is provided.¶
11.21.1. <personIDREF>
<personIDREF> contains the identifier of the represented person, i.e., the value of the related personID attribute (Section 21.1.1). Metadata about the represented participant can be retrieved by accessing the <people> list (Section 21).¶
12. Audio Captures
Audio captures inherit all the features of a generic
media capture and present further audio-specific
characteristics
An example of audio-specific information
that can be included is represented by the <sensitivity
12.1. <sensitivityPattern>
The <sensitivity
The current possible values, as per the CLUE framework document
[RFC8845], are "uni", "shotgun", "omni",
"figure8", "cardioid", and "hyper
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:¶
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 media
Text captures MUST be marked as non spatially definable (i.e., they
MUST present in their XML description the
<non
15. Other Capture Types
Other media capture types can be described by using the CLUE data model.
They can be represented by exploiting the "other
The XML schema representation of the
other
When defining new media capture types that are going to be described
by means of the <other
16. <captureScene>
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 <captureScene> element is the following:¶
Each capture scene is identified by a "sceneID" attribute.
The <captureScene> element can contain zero or more
textual <description> elements, as defined in
Section 11.13.
Besides <description>, there is the optional
<scene
16.1. <sceneInformation>
The <scene
16.2. <sceneViews>
The <sceneViews> element is a mandatory field of a capture scene containing the list of scene views. Each scene view is represented by a <sceneView> element (Section 17).¶
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:¶
17. <sceneView>
A <sceneView> element represents a capture scene view, which contains a set of media captures of the same media type describing a capture scene.¶
A <sceneView> element is characterized as follows.¶
One or more optional <description> elements provide human-readable information about what the scene view contains. <description> is defined in Section 11.13.¶
The remaining child elements are described in the following subsections.¶
17.1. <mediaCaptureIDs>
<media
17.2. sceneViewID Attribute
The sceneViewID attribute is a mandatory attribute containing the identifier of the capture scene view represented by the <sceneView> element.¶
18. <encodingGroup>
The <encodingGroup> 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 <encodingGroup> element is the following:¶
In the following subsections, the contained elements are further described.¶
18.1. <maxGroupBandwidth>
<max
18.2. <encodingIDList>
<encodingIDList> is the list of the individual encodings grouped together in the encoding group. Each individual encoding is represented through its identifier contained within an <encodingID> element.¶
18.3. encodingGroupID Attribute
The encodingGroupID attribute contains the identifier of the encoding group.¶
19. <simultaneousSet>
<simultaneous
Besides the identifiers of the captures
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. <mediaCaptureIDREF>
<media
19.4. <sceneViewIDREF>
<sceneViewIDREF> 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. <captureSceneIDREF>
<capture
20. <globalView>
<globalView> 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
<scene
21. <people>
Information about the participants that are represented in the media captures is conveyed via the <people> element. As it can be seen from the XML schema depicted below, for each participant, a <person> element is provided.¶
21.1. <person>
<person> 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 <personInfo> element; see Section 21.1.2) and its conference role(s) (via one or more <personType> elements; see Section 21.1.3). Furthermore, it has a mandatory "personID" attribute (Section 21.1.1).¶
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 <captured
21.1.2. <personInfo>
The <personInfo> 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 <fn> element within <vcard> is mandatory.¶
21.1.3. <personType>
The value of the <personType> 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:¶
The current possible values, as per the CLUE framework document
[RFC8845], are: "presenter",
"timekeeper", "attendee", "minute taker", "translator", "chairman",
"vice
A participant can play more than one conference role. In that case, more than one <personType> element will appear in its description.¶
22. <captureEncoding>
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 <capture
22.1. <captureID>
<captureID> is the mandatory element containing the identifier of the media capture that has been encoded to form the capture encoding.¶
22.2. <encodingID>
<encodingID> is the mandatory element containing the identifier of the applied individual encoding.¶
22.3. <configuredContent>
<configured
23. <clueInfo>
The <clueInfo> 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 Sections 27 and 28 are provided by using the <clueInfo> element.¶
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
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
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 SHOULD
be accessed only by authenticated endpoints.
Indeed, authenticated access is strongly advisable, especially if you
convey information about individuals
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 <personInfo>
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
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 <view>, <presentation>,
<sensitivity
26.1. XML Namespace Registration
26.2. XML Schema Registration
This section registers an XML schema per the guidelines in [RFC3688].¶
26.3. Media Type Registration for "application/clue_info+xml"
This section registers the "application
- 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 25 are 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:
-
- 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 <view> Values
IANA has created a registry of acceptable values for the <view> 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 <presentation> Values
IANA has created a registry of acceptable values for the <presentation> 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 <sensitivityPattern> Values
IANA has created a registry of acceptable values for the
<sensitivity
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 <personType> Values
IANA has created a registry of acceptable values for the
<personType> tag as defined in
Section 21.1.3.
The initial values for this registry are "presenter",
"timekeeper", "attendee", "minute taker", "translator", "chairman",
"vice
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
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:¶
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:¶
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
A possible description for that scenario could be the following:¶
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 , , <https:///RFC2119 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 , , <https:///RFC5646 www >..rfc -editor .org /info /rfc5646 - [RFC6351]
-
Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10
.17487 , , <https:///RFC6351 www >..rfc -editor .org /info /rfc6351 - [RFC7303]
-
Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10
.17487 , , <https:///RFC7303 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 , , <https:///RFC7852 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 , , <https:///RFC8126 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 , , <https:///RFC8174 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 , , <https:///RFC8845 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 , , <https:///RFC8847 www >..rfc -editor .org /info /rfc8847 - [RFC8850]
-
Holmberg, C., "Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel", RFC 8850, DOI 10
.17487 , , <https:///RFC8850 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 , , <https:///RFC3550 www >..rfc -editor .org /info /rfc3550 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC4353]
-
Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10
.17487 , , <https:///RFC4353 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 , , <https:///RFC6838 www >..rfc -editor .org /info /rfc6838 - [RFC7667]
-
Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10
.17487 , , <https:///RFC7667 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.¶