RFC 8846
An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model
RFC 8846: An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model 🎀
Okay bestie, this is part 1 of 13 of RFC 8846, so we're just getting started 💖. The title block says it's from the IETF, written by R. Presta and S P. Romano at the University of Napoli. It's on the Standards Track, with ISSN 2070-1721, and it's dated January 2021. The block doesn't have any Obsoletes or Updates lines, so this doc doesn't replace or update anything else 🧚.
Abstract ✨
Alright, so this doc gives you an XML schema file for CLUE data model types 🦋. CLUE is short for "Controlling Multiple Streams for Telepresence," and it's also the name of the IETF working group that made this doc (plus some companion docs) 🌸. The main point is that it sets up a coherent structure for all the info that describes a telepresence scenario, so it's giving organized 💅.
Status of This Memo ✨
This is an Internet Standards Track document 👑.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 💜. If you want more on Internet Standards, check Section 2 of RFC 7841 🌈.
For the current status, any errata, or how to send feedback, go to https://www.rfc-editor.org/info/rfc8846 🍓.
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://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💀.
Table of Contents 🧚
1. Introduction
2. Terminology
3. Definitions
4. XML Schema
5. <mediaCaptures>
6. <encodingGroups>
7. <captureScenes>
8. <simultaneousSets>
9. <globalViews>
10. <captureEncodings>
11. <mediaCapture>
11.1. captureID Attribute
11.2. mediaType Attribute
11.3. <captureSceneIDREF>
11.4. <encGroupIDREF>
11.5. <spatialInformation>
11.5.1. <captureOrigin>
11.5.2. <captureArea>
11.6. <nonSpatiallyDefinable>
11.7. <content>
11.8. <synchronizationID>
11.9. <allowSubsetChoice>
11.10. <policy>
11.11. <maxCaptures>
11.12. <individual>
11.13. <description>
11.14. <priority>
11.15. <lang>
11.16. <mobility>
11.17. <relatedTo>
11.18. <view>
11.19. <presentation>
11.20. <embeddedText>
11.21. <capturedPeople>
11.21.1. <personIDREF>
12. Audio Captures
12.1. <sensitivityPattern>
13. Video Captures
14. Text Captures
15. Other Capture Types
16. <captureScene>
16.1. <sceneInformation>
16.2. <sceneViews>
16.3. sceneID Attribute
16.4. scale Attribute
17. <sceneView>
17.1. <mediaCaptureIDs>
17.2. sceneViewID Attribute
18. <encodingGroup>
18.1. <maxGroupBandwidth>
18.2. <encodingIDList>
18.3. encodingGroupID Attribute
19. <simultaneousSet>
19.1. setID Attribute
19.2. mediaType Attribute
19.3. <mediaCaptureIDREF>
19.4. <sceneViewIDREF>
19.5. <captureSceneIDREF>
20. <globalView>
21. <people>
21.1. <person>
21.1.1. personID Attribute
21.1.2. <personInfo>
21.1.3. <personType>
22. <captureEncoding>
22.1. <captureID>
22.2. <encodingID>
22.3. <configuredContent>
23. <clueInfo>
24. XML Schema Extensibility
24.1. Example of Extension
25. Security Considerations
26. IANA Considerations
26.1. XML Namespace Registration
26.2. XML Schema Registration
26.3. Media Type Registration for "application/clue_info+xml"
26.4. Registry for Acceptable <view> Values
26.5. Registry for Acceptable <presentation> Values
26.6. Registry for Acceptable <sensitivityPattern> Values
26.7. Registry for Acceptable <personType> Values
27. Sample XML File
28. MCC Example
29. References
29.1. Normative References
29.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌸
So this doc is the XML schema file for CLUE data model types 🎀. For anyone who needs a refresher, CLUE stands for "Controlling Multiple Streams for Telepresence," and it's the working group name for this doc and its companions. The full CLUE framework gets a thorough write-up in [RFC8845] 📚.
The schema is built on the info in [RFC8845] 💅. It takes the info and constraints from that doc and turns them into a formal representation of the concepts 🦋.
The doc sets up a coherent structure for the info that describes a telepresence scenario 💖. That info gets used in the CLUE protocol messages [RFC8847], which handle the chat between a Media Provider and a Media Consumer 🫶. The CLUE protocol messages are XML messages, and they let (i) a Media Provider advertise its telepresence capabilities (media captures, capture scenes, and other CLUE features) using the format defined here, and (ii) a Media Consumer ask for the telepresence options it wants, in the form of capture encodings described in this doc ✨.
2. Terminology 💜
Here's the key word situation, and it's giving very official 👑. 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 doc uses the same definitions as [RFC8845], with one exception: the "CLUE Participant" definition 🌈. Here are some of the main terms we'll see a lot:
- 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 turns physical input, like audio, video, or text, into an electrical signal. Usually that signal is fed into a media encoder ⚡.
- Capture Encoding: A specific encoding of a Media Capture, which a Media Provider sends to a Media Consumer via RTP 🦋.
- Capture Scene: A structure for a spatial region that one or more Capture Devices capture, with each device capturing a portion of that region 🏠. The region can match a real place in physical space, like a room. A Capture Scene has attributes and one or more Capture Scene Views, and each view includes one or more Media Captures 💅.
- Capture Scene View (CSV): A list of Media Captures of the same media type that together make one way to represent the whole Capture Scene 🌸.
- CLUE Participant: This term comes from the CLUE protocol doc [RFC8847] 💖.
- Consumer: Short for Media Consumer 🫶.
- Encoding or Individual Encoding: A set of parameters for a way to encode a Media Capture so it becomes a Capture Encoding ✨.
- Encoding Group: A set of encoding parameters for the total media encoding capability, which gets divided across possibly several Individual Encodings 🍓.
- Endpoint: A CLUE-capable device that is the logical end point for receiving, decoding, and rendering media streams, and/or the starting point for capturing, encoding, and sending them 🌈. An endpoint is made of one or more physical devices that source and sink media streams, plus exactly one participant [RFC4353] (which in turn includes exactly one SIP User Agent). Endpoints can be anything from multiscreen or multicamera rooms to handheld devices 📱.
- Media: Any data that can be conveyed over RTP after suitable encoding, including audio, video, or timed text 🎶.
- Media Capture: A source of Media, such as one or more Capture Devices, or something constructed from other media streams 🎥.
- Media Consumer: A CLUE-capable device that wants to receive Capture Encodings 👀.
- Media Provider: A CLUE-capable device that wants to send Capture Encodings 📤.
- Multiple Content Capture (MCC): A Capture that mixes and/or switches other Captures of a single type, like all audio or all video. Depending on time or space, particular Media Captures may or may not show up in the resulting Capture Encoding. Denoted as "MCCn" in the example cases in this document 🎞️.
- Multipoint Control Unit (MCU): A CLUE-capable device that connects two or more endpoints into one single multimedia conference [RFC7667] 🤝. An MCU includes a Mixer, similar to the ones in [RFC4353], but it doesn't have to send media to each participant 🙌.
- Plane of Interest: The spatial plane within a scene that holds the most relevant subject matter 👑.
- Provider: Same as a Media Provider 📦.
- Render: The process of generating a representation from Media, like displayed motion video or sound coming out of loudspeakers 🔊.
- Scene: Same as a Capture Scene 🏞️.
- Simultaneous Transmission Set: A set of Media Captures that a Media Provider can transmit at the same time 🎬.
- Single Media Capture: A capture with media from a single source Capture Device, like audio from one microphone or video from one camera 🎙️.
- Spatial Relation: How two objects are arranged in space, as opposed to their relation in time or other relationships 📐.
- Stream: A Capture Encoding that a Media Provider sends to a Media Consumer via RTP [RFC3550] 🌊.
- Stream Characteristics: The media stream attributes that are commonly used in non-CLUE SIP/SDP environments (like media codec, bitrate, resolution, profile/level, and so on), plus CLUE-specific attributes like the Capture ID or a spatial location 🏷️.
- Video Capture: A Media Capture for video 📹.
4. XML Schema 🦋
This section holds the XML schema for the CLUE data model definition 💖.
The element and attribute definitions are formal representations of the concepts needed to describe a Media Provider's capabilities, along with the streams a Media Consumer asks for, based on the Media Provider's ADVERTISEMENT [RFC8847] ✨.
The main groups of info are:
<mediaCaptures>: the list of media captures available (Section 5)<encodingGroups>: the list of encoding groups (Section 6)<captureScenes>: the list of capture scenes (Section 7)<simultaneousSets>: the list of simultaneous transmission sets (Section 8)<globalViews>: the list of global views sets (Section 9)<people>: metadata about the participants represented in the telepresence session (Section 21)<captureEncodings>: the list of instantiated capture encodings (Section 10)
All of the above refer to concepts introduced in [RFC8845] and then detailed further in this doc 🌈. That's the end of part 1, so stay tuned for part 2 🫶💖
okay so the schema is still going and it's giving main character energy 💖 ✨ 🎀
<?xml version="1.0" encoding="UTF-8" ?>
<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">
<!-- Import xCard XML schema -->
<xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0"
schemaLocation=
"https://www.iana.org/assignments/xml-registry/schema/
vcard-4.0.xsd"/>
<!-- ELEMENT DEFINITIONS -->
<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"/>
<!-- MEDIA CAPTURES TYPE -->
<!-- envelope of media captures -->
<xs:complexType name="mediaCapturesType">
<xs:sequence>
<xs:element name="mediaCapture" type="mediaCaptureType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- DESCRIPTION element -->
<xs:element name="description">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!-- MEDIA CAPTURE TYPE -->
<xs:complexType name="mediaCaptureType" abstract="true">
<xs:sequence>
<!-- mandatory fields -->
<xs:element name="captureSceneIDREF" type="xs:IDREF"/>
<xs:choice>
<xs:sequence>
<xs:element name="spatialInformation"
type="tns:spatialInformationType"/>
</xs:sequence>
<xs:element name="nonSpatiallyDefinable" type="xs:boolean"
fixed="true"/>
</xs:choice>
<!-- for handling multicontent captures: -->
<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:sequence>
<xs:element name="individual" type="xs:boolean" fixed="true"/>
</xs:choice>
<!-- optional fields -->
<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:sequence>
<xs:attribute name="captureID" type="xs:ID" use="required"/>
<xs:attribute name="mediaType" type="xs:string" use="required"/>
</xs:complexType>
<!-- POLICY TYPE -->
<xs:simpleType name="policyType">
<xs:restriction base="xs:string">
<xs:pattern value="([a-zA-Z0-9])+[:]([0-9])+"/>
</xs:restriction>
</xs:simpleType>
<!-- CONTENT TYPE -->
<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:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!-- MAX CAPTURES TYPE -->
<xs:simpleType name="positiveShort">
<xs:restriction base="xs:unsignedShort">
<xs:minInclusive value="1">
</xs:minInclusive>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="maxCapturesType">
<xs:simpleContent>
<xs:extension base="positiveShort">
<xs:attribute name="exactNumber"
type="xs:boolean"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- CAPTURED PEOPLE TYPE -->
<xs:complexType name="capturedPeopleType">
<xs:sequence>
<xs:element name="personIDREF" type="xs:IDREF"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- PEOPLE TYPE -->
<xs:complexType name="peopleType">
<xs:sequence>
<xs:element name="person" type="personType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- PERSON TYPE -->
<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:sequence>
<xs:attribute name="personID" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!-- PERSON TYPE ELEMENT -->
<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:documentation>
</xs:annotation>
</xs:element>
<!-- VIEW ELEMENT -->
<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:documentation>
</xs:annotation>
</xs:element>
<!-- PRESENTATION ELEMENT -->
<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:documentation>
</xs:annotation>
</xs:element>
<!-- SPATIAL INFORMATION TYPE -->
<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:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!-- POINT TYPE -->
<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:sequence>
</xs:complexType>
<!-- CAPTURE ORIGIN TYPE -->
<xs:complexType name="captureOriginType">
<xs:sequence>
<xs:element name="capturePoint" type="pointType"></xs:element>
<xs:element name="lineOfCapturePoint" type="pointType"
minOccurs="0">
</xs:element>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- CAPTURE AREA TYPE -->
<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:sequence>
</xs:complexType>
<!-- MOBILITY TYPE -->
<xs:simpleType name="mobilityType">
<xs:restriction base="xs:string">
<xs:enumeration value="static" />
<xs:enumeration value="dynamic" />
<xs:enumeration value="highly-dynamic" />
</xs:restriction>
</xs:simpleType>
<!-- TEXT CAPTURE TYPE -->
<xs:complexType name="textCaptureType">
<xs:complexContent>
<xs:extension base="tns:mediaCaptureType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- OTHER CAPTURE TYPE -->
<xs:complexType name="otherCaptureType">
<xs:complexContent>
<xs:extension base="tns:mediaCaptureType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- AUDIO CAPTURE TYPE -->
<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:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- SENSITIVITY PATTERN ELEMENT -->
<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:documentation>
</xs:annotation>
</xs:element>
<!-- VIDEO CAPTURE TYPE -->
<xs:complexType name="videoCaptureType">
<xs:complexContent>
<xs:extension base="tns:mediaCaptureType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- EMBEDDED TEXT ELEMENT -->
<xs:element name="embeddedText">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:boolean">
<xs:attribute name="lang" type="xs:language"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!-- CAPTURE SCENES TYPE -->
<!-- envelope of capture scenes -->
<xs:complexType name="captureScenesType">
<xs:sequence>
<xs:element name="captureScene" type="captureSceneType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>5. <mediaCaptures> ✨
<mediaCaptures> is the list of one or more media captures hanging out on the Media Provider's side 📸. Each media capture gets its own <mediaCapture> element (Section 11) 💖
6. <encodingGroups> 🎀
<encodingGroups> is the list of encoding groups the Media Provider has organized 🧚 Each encoding group is represented by an <encodingGroup> element (Section 18) ✨
7. <captureScenes> 🌸
<captureScenes> is the list of capture scenes the Media Provider has put together 🎬 Each capture scene is represented by a <captureScene> element (Section 16) 🦋
8. <simultaneousSets> 💜
<simultaneousSets> holds the simultaneous sets the Media Provider has indicated 👯♀️ Each simultaneous set is represented by a <simultaneousSet> element (Section 19) 🫶
9. <globalViews> 🌈
<globalViews> holds a set of alternative ways to represent all the scenes the Media Provider offers to a Media Consumer 🌍 Each alternative is called a "global view", and it's represented by a <globalView> element (Section 20) 👑
10. <captureEncodings> 🍓
<captureEncodings> is a list of capture encodings 📋 It can be the list of desired capture encodings the Media Consumer asks for, or the list of instantiated captures on the provider's side 💅 Each capture encoding is represented by a <captureEncoding> element (Section 22) ✨
11. <mediaCapture> 🎥
A media capture is the core representation of a media flow that's available on the provider's side 💖 Media captures have two kinds of features: (i) features that don't depend on the specific type of medium, and (ii) features that are media specific 😭 The features shared by all media types live in the media capture type, which is designed as an abstract complex type 🧚 Media-specific captures, like video captures, audio captures, and others, are specializations of that abstract media capture type, the classic generalization-specialization hierarchy 🌸
Here's the XML schema definition of the media capture type 💅
<!-- MEDIA CAPTURE TYPE -->
<xs:complexType name="mediaCaptureType" abstract="true">
<xs:sequence>
<!-- mandatory fields -->
<xs:element name="captureSceneIDREF" type="xs:IDREF"/>
<xs:choice>
<xs:sequence>
<xs:element name="spatialInformation"
type="tns:spatialInformationType"/>
</xs:sequence>
<xs:element name="nonSpatiallyDefinable" type="xs:boolean"
fixed="true"/>
</xs:choice>
<!-- for handling multicontent captures: -->
<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:sequence>
<xs:element name="individual" type="xs:boolean" fixed="true"/>
</xs:choice>
<!-- optional fields -->
<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:sequence>
<xs:attribute name="captureID" type="xs:ID" use="required"/>
<xs:attribute name="mediaType" type="xs:string" use="required"/>
</xs:complexType>11.1. captureID Attribute 🪪
The captureID attribute is a mandatory field holding the identifier of the media capture 🔑 That identifier is how other data model elements reference the capture, like simultaneous sets, capture encodings, and others via <mediaCaptureIDREF> 🧷
11.2. mediaType Attribute 🎶
The mediaType attribute is a mandatory attribute that specifies the media type of the capture 🎧 Common standard values are "audio", "video", and "text", as defined in [RFC6838] 📺 Other values can be provided too 🍒 It's assumed that implementations agree on how to interpret those other values 🤝 The mediaType attribute is kept as generic as possible, and here's why 🧠: (i) the basic media capture type is abstract; (ii) "concrete" definitions for the standard audio, video, and text capture types [RFC6838] have been specified; (iii) a generic otherCaptureType type has been defined; and (iv) the mediaType attribute is defined generically as a string, with no particular template 🫧 So, if you go with a brand new media type and want to interoperate with others, you'll need an application-level agreement on how to interpret that information 🫶💀
11.3. <captureSceneIDREF>
<captureSceneIDREF> is a mandatory field, so bestie, you can't skip it 🫶. It holds the identifier of the capture scene your media capture is defined in, which is the value of the sceneID attribute (see Section 16.3) of that scene. Here's the tea: each media capture MUST be defined within one and only one capture scene. One scene, no sharing 💅. When a media capture is spatially definable, some spatial info comes along with it as point coordinates (see Section 11.5). Those coordinates are relative to the coordinate space defined for the capture scene that holds the capture 🗺️.
11.4. <encGroupIDREF>
<encGroupIDREF> is optional, so it's your call 🌸. It holds the identifier of the encoding group the media capture is associated with, i.e., the value of the encodingGroupID attribute (see Section 18.3) of that encoding group. ngl, the important bit is this: media captures that aren't associated with any encoding group cannot be instantiated as media streams 💀.
11.5. <spatialInformation>
Okay so media captures come in two flavors: (i) non spatially definable captures and (ii) spatially definable captures ✨.
A capture is spatially definable when you can provide at least one of these: (i) the position of the capture device within the telepresence room of origin (that's the capture point), along with its capturing direction, given by a second point (the point on line of capture), or (ii) the area it represents inside the telepresence room, listed as four coplanar points that identify the plane of interest (the area of capture). The coordinates of the points mentioned above MUST be expressed according to the coordinate space of the capture scene the media captures belong to 📐.
Non spatially definable captures can't be characterized within the physical space of the telepresence room of origin. Examples are recordings, text captures, DVDs, registered presentations, or external streams that get played in the room and sent to remote sites 📼.
Spatially definable captures represent a part of the telepresence room, and that captured part is described by means of the <spatialInformation> element. By comparing the <spatialInformation> elements of different media captures within the same capture scene, a consumer can better figure out the spatial relationships between them and render them correctly 🧩. Non spatially definable captures don't embed such elements in their XML description. Instead, they're characterized by having the <nonSpatiallyDefinable> tag set to "true" (see Section 11.6) 🙈.
Here's the definition of the spatial information type 👇
<!-- SPATIAL INFORMATION TYPE -->
<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:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>The <captureOrigin> contains the coordinates of the capture device taking the capture (aka the capture point) as well as, optionally, the pointing direction (aka 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 point coordinates is specified in the scale attribute (see Section 16.4) of the capture scene the media capture belongs to. Basically, all the spatially definable media captures referring to the same capture scene share one coordinate system and express their spatial info using the same scale 📏✨.
11.5.1. <captureOrigin>
The <captureOrigin> element represents 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 🎙️.
Here's the XML schema definition of the <captureOrigin> element type:
<!-- CAPTURE ORIGIN TYPE -->
<xs:complexType name="captureOriginType">
<xs:sequence>
<xs:element name="capturePoint" type="pointType"/>
<xs:element name="lineOfCapturePoint" type="pointType"
minOccurs="0"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- POINT TYPE -->
<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:sequence>
</xs:complexType>The point type holds 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 <lineOfCapturePoint> element, both of the type "pointType". <capturePoint> specifies the three coordinates identifying the position of the capture device. <lineOfCapturePoint> is another pointType element representing the "point on line of capture", which gives the pointing direction of the capture device 🧭.
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. Here's the XML schema definition:
<!-- CAPTURE AREA TYPE -->
<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:sequence>
</xs:complexType>11.6. <nonSpatiallyDefinable>
When media captures are non spatially definable, they MUST be marked with the boolean <nonSpatiallyDefinable> element set to "true", and no <spatialInformation> MUST be provided. And yes, <nonSpatiallyDefinable> and <spatialInformation> are mutually exclusive tags, according to the <choice> section within the XML schema definition of the media capture type 🙅♀️.
11.7. <content>
A media capture can be (i) an individual media capture or (ii) an MCC. An MCC is made of different captures that can be arranged spatially (by a composition operation), temporally (by a switching operation), or come from orchestrating both techniques together 🎬.
If a media capture is an MCC, then it MAY show the <content> element in its XML data model representation. The <content> element is composed of a list of media capture identifiers ("mediaCaptureIDREF") and capture scene view identifiers ("sceneViewIDREF"), where the latter ones are used as shortcuts to refer to multiple capture identifiers. The referenced captures are used to create the MCC according to a certain strategy. If the <content> element does not appear in an MCC, or it has no child elements, then the MCC is assumed to be made of multiple sources, but no information regarding those sources is provided 🤷♀️.
<!-- CONTENT TYPE -->
<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:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>11.8. <synchronizationID>
<synchronizationID> is an optional element for multiple content captures that contains a numeric identifier. Multiple content captures marked with the same identifier in the <synchronizationID> contain at all times captures coming from the same sources. It's the Media Provider that determines what the source is for the captures. That way, the Media Provider can choose how to group together single captures for the purpose of keeping them synchronized according to the <synchronizationID> element 🔄.
11.9. <allowSubsetChoice>
<allowSubsetChoice> is an optional boolean element for multiple content captures. It indicates whether or not the Provider allows the Consumer to choose a specific subset of the captures referenced by the MCC. If this attribute is true, and the MCC references other captures, then the Consumer MAY specify in a CONFIGURE message a specific subset of those captures to be included in the MCC, and the Provider MUST then include only that subset. If this attribute is false, or the MCC does not reference other captures, then the Consumer MUST NOT select a subset. If <allowSubsetChoice> is not shown in the XML description of the MCC, its value is to be considered "false" 💜.
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 <mediaCaptureIDREF> list. The <policy> value is in the form of a token that indicates the policy and an index representing an instance of the policy, separated by a ":" (e.g., SoundLevel:2, RoundRobin:0, etc.). Here's the XML schema defining the type of the <policy> element 🧾:
<!-- POLICY TYPE -->
<xs:simpleType name="policyType">
<xs:restriction base="xs:string">
<xs:pattern value="([a-zA-Z0-9])+[:]([0-9])+"/>
</xs:restriction>
</xs:simpleType>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> 🎀
Okay so <maxCaptures> is an optional element, but it's only for MCCs (multiple content captures) 💅 It tells you how many media captures can show up in the capture encoding at a time. If you skip it, then every single media capture listed in <content> is allowed to appear at once ✨ Here's the type definition:
<!-- MAX CAPTURES TYPE -->
<xs:simpleType name="positiveShort">
<xs:restriction base="xs:unsignedShort">
<xs:minInclusive value="1">
</xs:minInclusive>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="maxCapturesType">
<xs:simpleContent>
<xs:extension base="positiveShort">
<xs:attribute name="exactNumber"
type="xs:boolean"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>So when the exactNumber attribute is set to "true", it means the <maxCaptures> value is the exact number of media captures showing up at a time 🔥 Otherwise, the number of represented media captures MUST be considered <= the <maxCaptures> value. Not me being picky, but that's the rule 🙈
Let's make it concrete. An audio MCC with <maxCaptures> set to 1 means a media stream from that MCC will only ever contain audio from a single one of its constituent captures at a time 🎧 Now if <maxCaptures> is 4 and exactNumber is "true"? Then the media stream received from the MCC will always contain a mix of audio from exactly four of its constituent captures. Iconic, no notes 👑
11.12. <individual> 🦋
<individual> is a boolean element that MUST be used for single-content captures. Its value is fixed and set to "true". It's basically the tag saying "hey, this capture is NOT an MCC" 💖 And it's mutually exclusive with the MCC-related tags from Sections 11.7 to 11.11. That's enforced by the <choice> section in the XML schema definition of the media capture type, so you can't have both. Main character energy, one capture type at a time 🌸
11.13. <description> 📝
<description> is for human-readable textual info. It shows up in the XML definitions of media captures, capture scenes, and capture scene views, so each one can have a readable description: media captures get descriptions of media captures, capture scenes get descriptions of capture scenes, and so on 🧚 According to the data model definition of a media capture (Section 11)), you can have zero or more <description> elements, each one in a different language. Like a whole multilingual group chat 🌈
Here's the element definition:
<!-- DESCRIPTION element -->
<xs:element name="description">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>So yes, <description> is a string element with a lang attribute that tells you which language the text is in. That attribute follows the Language-Tag ABNF production from [RFC5646] 🫶
11.14. <priority> 🔥
<priority> is an optional unsigned integer that shows how important a media capture is, from the Media Provider's point of view 👑 The receiver can use it to automatically figure out which contribution from the Media Provider matters most. Here's the twist: the higher the importance, the lower the number 💀 And if there's no priority assigned, you can't assume anything about how important that media capture is relative to the others. No vibes-based guessing 🙈
11.15. <lang> 🌸
<lang> is an optional element that holds the language used in the capture. You can have zero or more <lang> elements in the XML description of a media capture ✨ Each one has to be compliant with the Language-Tag ABNF production from [RFC5646] 🫶
11.16. <mobility> 🦋
<mobility> is an optional element that says whether the capture device can move around during the telepresence session 🧚 It can be one of three values, and they're giving very different energy:
static: SHOULD NOT change for the duration of the CLUE session, across multiple ADVERTISEMENT messages. Chill, stays put 🪑dynamic: MAY change in each new ADVERTISEMENT message. It can be assumed to remain unchanged until there's a new ADVERTISEMENT message. Little moves, but only when there's a new update 💜highly-dynamic: MAY change dynamically, even between consecutive ADVERTISEMENT messages. The spatial information in an ADVERTISEMENT message is just a snapshot of the current values at the moment the message is sent 📸 Full chaos mode, fr fr 🌪️
11.17. <relatedTo> 🎀
The optional <relatedTo> element holds the value of the captureID attribute (Section 11.1) of the media capture that the current one refers to 💖 So a capture tagged with <relatedTo> could be, for example, the translation of the referred capture into a different language. Bestie, that's a whole translation situation 🌍
11.18. <view> ✨
The <view> element is an optional tag that describes what's shown in the spatial area covered by a media capture 👀 It's a simple string, with an annotation pointing to an IANA registry that was set up ad hoc:
<!-- VIEW ELEMENT -->
<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:documentation>
</xs:annotation>
</xs:element>The current possible values, per the CLUE framework document [RFC8845], are: "room", "table", "lectern", "individual", and "audience" 🏛️ Five options, and each one is a whole vibe 💅
11.19. <presentation> 🍓
The <presentation> element is an optional tag for media captures that carry info about presentations in the telepresence session 📊 Same deal as <view>: a simple string with an annotation pointing to an ad hoc IANA registry:
<!-- PRESENTATION ELEMENT -->
<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:documentation>
</xs:annotation>
</xs:element>The current possible values, per [RFC8845], are "slides" and "images" 🖼️ Slides served, no cap 🔥
11.20. <embeddedText> 💜
The <embeddedText> element is a boolean that tells you there's text embedded in the media capture, like text burned into a video capture 🎬 The language of that embedded text is reported in the lang attribute of <embeddedText> ✨
The XML schema definition is:
<!-- EMBEDDED TEXT ELEMENT -->
<xs:element name="embeddedText">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:boolean">
<xs:attribute name="lang" type="xs:language"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>11.21. <capturedPeople> 🫶
This optional element shows which telepresence session participants are represented within the media captures 👯 For each participant, there's a <personIDREF> element.
11.21.1. <personIDREF> 🧚
<personIDREF> holds the identifier of the represented person, which is the value of the related personID attribute (Section 21.1.1) 🪪 If you want the details about that participant, you can look them up in the <people> list (Section 21) 📇
12. Audio Captures 🎧
Audio captures inherit all the features of a generic media capture and add some audio-specific stuff on top 🔊 Here's the XML schema definition of the audio capture type:
<!-- AUDIO CAPTURE TYPE -->
<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:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>One example of audio-specific info is the <sensitivityPattern> element (Section 12.1) 🎙️
12.1. <sensitivityPattern> 💖
<sensitivityPattern> is an optional field that describes the nominal sensitivity pattern of the microphone capturing the audio signal 🎤 It's a simple string with an annotation pointing to an ad hoc IANA registry:
<!-- SENSITIVITY PATTERN ELEMENT -->
<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:documentation>
</xs:annotation>
</xs:element>The current possible values, per [RFC8845], are "uni", "shotgun", "omni", "figure8", "cardioid", and "hyper-cardioid" 🌟 Six mic patterns, all serving different looks 💅
13. Video Captures 📹
Video captures are like audio captures: they take a generic media capture and extend it with video-specific features 🎥 Here's the XML schema representation of the video capture type:
<!-- VIDEO CAPTURE TYPE -->
<xs:complexType name="videoCaptureType">
<xs:complexContent>
<xs:extension base="tns:mediaCaptureType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>14. Text Captures 💬
Just like audio and video captures, text captures extend the generic media capture information 🫧
There are no known properties of text-based media that aren't already covered by the generic mediaCaptureType, so text captures are defined like this:
<!-- TEXT CAPTURE TYPE -->
<xs:complexType name="textCaptureType">
<xs:complexContent>
<xs:extension base="tns:mediaCaptureType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>Text captures MUST be marked as non spatially definable. In other words, they MUST present in their XML description the<nonSpatiallyDefinable>(Section 11.6) element set to"true". Non-negotiable, bestie 🙅♀️💅
Okay bestie, let's get into the rest of this 🎀✨
15. Other Capture Types 🦋
Okay so, other media capture types can be described using the CLUE data model 💅. You represent them with the "otherCaptureType" type. This type is basically a blank canvas that gets filled in with elements from extensions of the schema, meaning elements defined in other XML schemas (see Section 24 for an example) 🧚. The otherCaptureType inherits all the features of the abstract mediaCaptureType, so it's giving full inheritance energy 👑.
The XML schema representation of the otherCaptureType is the following:
<!-- OTHER CAPTURE TYPE -->
<xs:complexType name="otherCaptureType">
<xs:complexContent>
<xs:extension base="tns:mediaCaptureType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>Now, when you're defining new media capture types that will be described with the <otherMediaCapture> element, the spatial properties of those new types SHOULD be defined 🌸. That covers things like whether they're spatially definable, whether they should be tied to an area of capture, and any other properties that might be defined. Be intentional about it, bestie 🫶.
16. <captureScene> 🎬
A Media Provider organizes the available captures into capture scenes so the receiver can handle both rendering and selection of the group of captures 💖. Capture scenes are made of media captures and capture scene views. A capture scene view is a set of media captures of the same media type, and each one is an alternative way to completely represent a capture scene for a fixed media type. Iconic design, honestly 😭.
The XML schema representation of a <captureScene> element is the following:
<!-- CAPTURE SCENE TYPE -->
<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:sequence>
<xs:attribute name="sceneID" type="xs:ID" use="required"/>
<xs:attribute name="scale" type="scaleType" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>Each capture scene is identified by a "sceneID" attribute 🆔. The <captureScene> element can hold zero or more textual <description> elements, as defined in Section 11.13 📝. Besides <description>, there's the optional <sceneInformation> element (Section 16.1), which holds structured info about the scene in vCard format, and the optional <sceneViews> element (Section 16.2), which is the list of capture scene views. When there's no <sceneViews>, the capture scene is assumed to be made of all the media captures whose mandatory captureSceneIDREF attribute contains the value of its sceneID attribute. Main character energy for sure 💅.
16.1. <sceneInformation>
The <sceneInformation> element holds optional info about the capture scene in the vCard format, as specified in the xCard specification [RFC6351] 🪪.
16.2. <sceneViews>
The <sceneViews> element is a mandatory field of a capture scene. It contains the list of scene views, and each scene view is represented by a <sceneView> element (Section 17) 🌈.
<!-- SCENE VIEWS TYPE -->
<!-- envelope of scene views of a capture scene -->
<xs:complexType name="sceneViewsType">
<xs:sequence>
<xs:element name="sceneView" type="sceneViewType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>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 given in the spatial information of the media captures in that capture scene. It can take three values:
"mm": the scale is in millimeters. Systems that know their physical dimensions (for example, professionally installed telepresence room systems) should always provide these real-world measurements 🤩."unknown": the scale is the same for every media capture in the capture scene, but the unit of measure is undefined. Systems that aren't aware of specific physical dimensions yet still know relative distances should pick "unknown" for the scale of the capture scene they describe 🤷♀️."noscale": there's no common physical scale among the media captures in the capture scene. The scale could be different for each media capture 🙈.
<!-- SCALE TYPE -->
<xs:simpleType name="scaleType">
<xs:restriction base="xs:string">
<xs:enumeration value="mm"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="noscale"/>
</xs:restriction>
</xs:simpleType>17. <sceneView> 👀
A <sceneView> element represents a capture scene view, which holds a set of media captures of the same media type describing a capture scene 💜.
A <sceneView> element is characterized as follows.
<!-- SCENE VIEW TYPE -->
<xs:complexType name="sceneViewType">
<xs:sequence>
<xs:element ref="description" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="mediaCaptureIDs" type="captureIDListType"/>
</xs:sequence>
<xs:attribute name="sceneViewID" type="xs:ID" use="required"/>
</xs:complexType>One or more optional <description> elements give human-readable info 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>
<mediaCaptureIDs> is the list of identifiers of the media captures included in the scene view. It's an element of the captureIDListType type, which is defined as a sequence of <mediaCaptureIDREF> elements, each containing the identifier of a media capture listed within the <mediaCaptures> element 🗂️:
<!-- CAPTURE ID LIST TYPE -->
<xs:complexType name="captureIDListType">
<xs:sequence>
<xs:element name="mediaCaptureIDREF" type="xs:IDREF"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>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 up of one or more individual encodings plus some parameters that apply to the group as a whole. Encoding groups hold references to the individual encodings that can be applied to media captures. The definition of the <encodingGroup> element is the following:
<!-- ENCODING GROUP TYPE -->
<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:sequence>
<xs:attribute name="encodingGroupID" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>The contained elements are described further in the following subsections 🔍.
18.1. <maxGroupBandwidth>
<maxGroupBandwidth> 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. <encodingIDList>
<encodingIDList> is the list of individual encodings grouped together in the encoding group. Each individual encoding is represented through its identifier, held inside an <encodingID> element 🪄.
<!-- ENCODING ID LIST TYPE -->
<xs:complexType name="encodingIDListType">
<xs:sequence>
<xs:element name="encodingID" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>18.3. encodingGroupID Attribute 🆔
The encodingGroupID attribute contains the identifier of the encoding group.
19. <simultaneousSet> 🤝
<simultaneousSet> represents a simultaneous transmission set, which is a list of captures of the same media type that a Media Provider can transmit at the same time. There are different simultaneous transmission sets for each media type 🎶.
<!-- SIMULTANEOUS SET 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:sequence>
<xs:attribute name="setID" type="xs:ID" use="required"/>
<xs:attribute name="mediaType" type="xs:string"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>Besides the identifiers of the captures (<mediaCaptureIDREF> elements), the identifiers of capture scene views and capture scenes can also be used as shortcuts (<sceneViewIDREF> and <captureSceneIDREF> elements). For example, say 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 all be sent to the Media Consumer at the same time, then instead of listing 5 <mediaCaptureIDREF> elements in the simultaneous set (one for AC11, one for AC12, and so on), you can just have two <sceneViewIDREF> 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 so the receiver can work out which media captures can be sent simultaneously together 🚨.
19.3. <mediaCaptureIDREF>
<mediaCaptureIDREF> contains the identifier of the media capture that belongs to the simultaneous set 🎯.
19.4. <sceneViewIDREF>
<sceneViewIDREF> contains the identifier of the scene view holding a group of captures that can be sent at the same time as the other captures in the simultaneous set 💫.
19.5. <captureSceneIDREF>
<captureSceneIDREF> contains the identifier of the capture scene where all the included captures of a certain media type can be sent together with the other captures in the simultaneous set 🥰.
20. <globalView> 🌸
okay so <globalView> is a set of captures that all share the same media type, and it's basically a highlight reel of the Media Provider's whole offer 🎬✨. Its content is built using only scene view identifiers, which go inside <sceneViewIDREF> elements. Every global view gets its own unique identifier in the "globalViewID" attribute 🦋
<!-- GLOBAL VIEW TYPE -->
<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:sequence>
<xs:attribute name="globalViewID" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>21. <people> 🫶
this one's all about the humans!! 💜 Info about the participants who show up in the media captures lives in the <people> element. As the XML schema below shows, you get one <person> element for each participant.
<!-- PEOPLE TYPE -->
<xs:complexType name="peopleType">
<xs:sequence>
<xs:element name="person" type="personType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>21.1. <person> 🧚
<person> holds all the metadata about someone represented in one or more media captures, and it's giving main character energy 👑 It carries the person's vCard (via the <personInfo> element, see Section 21.1.2) and their conference role(s) (via one or more <personType> elements, see Section 21.1.3). It also has a mandatory "personID" attribute (Section 21.1.1).
<!-- PERSON TYPE -->
<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:sequence>
<xs:attribute name="personID" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>21.1.1. personID Attribute 💅
The "personID" attribute carries the identifier of a represented person. You can use that identifier to point at the participant, like in the <capturedPeople> element of the media captures representation (Section 11.21). Iconic behaviour, honestly 🌈
21.1.2. <personInfo> 📇
The <personInfo> element is the XML representation of every field in a vCard, as defined in the xCard document [RFC6351]. The vcardType comes from the xCard XML schema in Appendix A of [RFC7852]. And as that schema spells out, the <fn> element within <vcard> is mandatory, so don't forget it 🙈
21.1.3. <personType> 🎀
The value of the <personType> element tells you what role the represented participant plays in the telepresence session organization. It's a simple string, with an annotation that points to an IANA registry that's defined ad hoc:
<!-- PERSON TYPE ELEMENT -->
<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:documentation>
</xs:annotation>
</xs:element>The current possible values, per the CLUE framework document [RFC8845], are: "presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice-chairman", and "observer". Okay, so many roles to play with! ✨
A participant can play more than one conference role. When that happens, you'll see more than one <personType> element in their description 💖
22. <captureEncoding> 🦋
a capture encoding happens when you pair a media capture with an individual encoding, and that combo becomes a capture stream as defined in [RFC8845] 🔥 Capture encodings get used inside CONFIGURE messages that go from a Media Consumer to a Media Provider, and they describe the streams the Media Consumer wants. For each stream it wants, the Media Consumer has to be able to say: (i) the capture identifier of the wanted capture, which the Media Provider advertised; (ii) the encoding identifier of the encoding to use, picked from the ones the Media Provider advertised; and (iii) optionally, if it's a multicontent capture, the list of capture identifiers it wants. All of these identifiers are supposed to show up in the ADVERTISEMENT message that the CONFIGURE message refers to. Here's the XML model for <captureEncoding>:
<!-- CAPTURE ENCODING TYPE -->
<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:sequence>
<xs:attribute name="ID" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>22.1. <captureID> 🧁
<captureID> is the mandatory element holding the identifier of the media capture that got encoded to form the capture encoding.
22.2. <encodingID> 🍓
<encodingID> is the mandatory element holding the identifier of the individual encoding that got applied.
22.3. <configuredContent> 🌷
<configuredContent> is an optional element, used when you're configuring an MCC. It holds the list of capture identifiers and capture scene view identifiers that the Media Consumer wants within the MCC. This element is structured like the <content> element used to describe an MCC's content. The total number of media captures listed in the <configuredContent> MUST be lower than or equal to the value carried within the <maxCaptures> attribute of the MCC. Rules are rules, bestie 📏
23. <clueInfo> 🌟
the <clueInfo> element has everything needed to represent the Media Provider's telepresence capabilities under the CLUE framework 💅 It's made up of:
- the list of the available media captures (see "<mediaCaptures>", Section 5)
- the list of encoding groups (see "<encodingGroups>", Section 6)
- the list of capture scenes (see "<captureScenes>", Section 7)
- the list of simultaneous transmission sets (see "<simultaneousSets>", Section 8)
- the list of global views sets (see "<globalViews>", Section 9)
- metadata about the participants represented in the telepresence session (see "<people>", Section 21)
Real talk: this one was only made for data model testing purposes 🧪 It looks a lot like the body of an ADVERTISEMENT message, but it's not actually used in the CLUE protocol message definitions. The telepresence capability descriptions that follow this data model spec, in Sections 27 and 28, are written using the <clueInfo> element.
<!-- CLUE INFO TYPE -->
<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:sequence>
<xs:attribute name="clueInfoID" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>24. XML Schema Extensibility 🧩
the telepresence data model in this document is meant to be extensible, and it's so intentional about it 💖 You extend it by defining elements or attributes in namespaces other than "urn:ietf:params:xml:ns:clue-info" and "urn:ietf:params:xml:ns:vcard-4.0". You can do that anywhere the schema allows extensions, meaning wherever the XML schema definition specifies "anyAttribute" or "anyElement". Elements or attributes from unknown namespaces MUST be ignored. Extensibility was favored as much as possible, since custom implementations were expected. So the schema gives people enough flexibility to define custom extensions without losing compliance with the standard. It does this with <xs:any> elements and <xs:anyAttribute> attributes, which is a common approach in schemas, and it still matches the Unique Particle Attribution (UPA) constraint 🌈
24.1. Example of Extension 🎀
okay so when you want to extend the CLUE data model, you need to specify a brand-new schema with its own namespace attached. bestie, this is the part where we actually see it happen 💅
Here's the example. The extension adds a new audio capture attribute called "newAudioFeature" 🎧, plus an attribute that describes captures belonging to a user-defined "otherCaptureType" 🦋. There's also an XML document that follows the extension, and the results are validated against the current XML schema for the CLUE data model ✨
<?xml version="1.0" encoding="UTF-8" ?>
<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">
<!-- Import xCard XML schema -->
<xs:import namespace="urn:ietf:params:xml:ns:vcard-4.0"
schemaLocation=
"https://www.iana.org/assignments/xml-registry/schema/
vcard-4.0.xsd"/>
<!-- Import CLUE XML schema -->
<xs:import namespace="urn:ietf:params:xml:ns:clue-info"
schemaLocation="clue-data-model-schema.xsd"/>
<!-- ELEMENT DEFINITIONS -->
<xs:element name="newAudioFeature" type="xs:string"/>
<xs:element name="otherMediaCaptureTypeFeature" type="xs:string"/>
</xs:schema>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<clueInfo xmlns="urn:ietf:params:xml:ns:clue-info"
xmlns:ns2="urn:ietf:params:xml:ns:vcard-4.0"
xmlns:ns3="urn:ietf:params:xml:ns:clue-info-ext"
clueInfoID="NapoliRoom">
<mediaCaptures>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="audioCaptureType"
captureID="AC0"
mediaType="audio">
<captureSceneIDREF>CS1</captureSceneIDREF>
<nonSpatiallyDefinable>true</nonSpatiallyDefinable>
<individual>true</individual>
<encGroupIDREF>EG1</encGroupIDREF>
<ns3:newAudioFeature>newAudioFeatureValue
</ns3:newAudioFeature>
</mediaCapture>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="otherCaptureType"
captureID="OMC0"
mediaType="other media type">
<captureSceneIDREF>CS1</captureSceneIDREF>
<nonSpatiallyDefinable>true</nonSpatiallyDefinable>
<encGroupIDREF>EG1</encGroupIDREF>
<ns3:otherMediaCaptureTypeFeature>OtherValue
</ns3:otherMediaCaptureTypeFeature>
</mediaCapture>
</mediaCaptures>
<encodingGroups>
<encodingGroup encodingGroupID="EG1">
<maxGroupBandwidth>300000</maxGroupBandwidth>
<encodingIDList>
<encodingID>ENC4</encodingID>
<encodingID>ENC5</encodingID>
</encodingIDList>
</encodingGroup>
</encodingGroups>
<captureScenes>
<captureScene scale="unknown" sceneID="CS1"/>
</captureScenes>
</clueInfo>25. Security Considerations 🔐
this doc is basically an XML schema for telepresence scenarios 📹 the info it models is what CLUE needs for a full-fledged media stream negotiation and rendering, so it's kinda the backbone 🦴 the XML elements defined here get used inside CLUE protocol messages to describe both the media streams in the Media Provider's telepresence offer and the selection the Media Consumer wants. security stuff from [RFC8845], Section 15 applies here too, so go read that bestie 🫶
Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints. authenticated access is strongly advisable 🙈 especially if you're sending info about individuals (<personalInfo>) and/or scenes (<sceneInformation>). there might be more exceptions depending on how critical the setup and configuration of a session is ⚖️ in principle someone could even decide no protection at all is needed for a particular session 🤷♀️ here's why authentication hasn't been made a mandatory requirement.
okay the real tea: some info from the Media Provider could reveal sensitive stuff about who and what is in the transmitted streams 👀 the vCard inside the <personInfo> elements (Section 21.1) mandatorily contains the identity of the represented person 🪪 optionally, vCards can also carry the person's contact addresses, plus their photo and other personal data 📸 similar privacy-critical info can come through <sceneInformation> elements (Section 16.1) describing the capture scenes 🏛️ and the <description> elements (Section 11.13) can also specify details about the content of media captures, capture scenes, and scene views that should be protected 🔒
integrity attacks on the data model info inside CLUE messages can totally wreck the telepresence session's setup 💀 they mislead the Media Consumer's and Media Provider's understanding of the offered and desired media streams. not it 😭
the assurance of authenticated access and of data model integrity is up to the transport mechanisms involved, namely the CLUE protocol [RFC8847] and the CLUE data channel [RFC8850] 🚚
and XML parsers need to be robust against malformed documents 🧼 reading malformed docs from unknown or untrusted sources could let an attacker gain the privileges of the user running the XML parser 😱 in an extreme situation, the entire machine could be compromised. so yeah, be careful out there bestie 🫣
26. IANA Considerations 📋
this doc registers a new XML namespace, a new XML schema, the media type for the schema, and four new registries associated with acceptable <view>, <presentation>, <sensitivityPattern>, and <personType> values. IANA slay 👑
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:
<CODE BEGINS>
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>CLUE Data Model Namespace</title>
</head>
<body>
<h1>Namespace for CLUE Data Model</h1>
<h2>urn:ietf:params:xml:ns:clue-info</h2>
<p>See
<a href="https://www.rfc-editor.org/rfc/rfc8846.txt">RFC 8846</a>.
</p>
</body>
</html>
<CODE ENDS>26.2. XML Schema Registration 🧾
this section registers an XML schema following 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 in Section 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 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:
- 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 <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 <sensitivityPattern> 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 <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-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 🧁
okay the next bit is a sample XML document that's a schema-compliant example of a CLUE telepresence scenario 🎀 taking inspiration from the examples in the framework spec [RFC8845], it shows the XML representation of an endpoint-style Media Provider's ADVERTISEMENT ✨
there are three cameras, and the central one can also capture a zoomed-out view of the whole telepresence room 📷 besides the three video captures from the cameras, the Media Provider also offers a multicontent capture of the loudest segment of the room, made by switching the video source across the three cameras 🔄 and to keep things simple, 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), and their vCard and conference role details are provided too 💅
okay so the media captures get arranged into four capture scene views 💖
(VC0, VC1, VC2)- left, center, and right camera video captures 📸(VC3)- video capture associated with loudest room segment 🔊(VC4)- video capture zoomed-out view of all people in the room 🌸(AC0)- main audio 🎧
there are two encoding groups 🫶: EG0 is for video encodings and EG1 is for audio encodings.
now the simultaneous sets... ngl this part is so important bestie 😭
VC1 and VC4 cannot be transmitted at the same time because they're captured by the same device, aka the central camera 🎥 (VC4 is the zoomed-out view while VC1 is the focused view of the front participant). and VC3 and VC4 cannot be simultaneous either, since VC3 (the loudest segment of the room) might at some point be focusing on the central part of the room, which is the same thing VC1 is looking at 🙈
so the simultaneous sets end up being:
- SS1: made by
VC3and all the captures in the first capture scene view (VC0,VC1,and VC2) 💜 - SS2: made by
VC0,VC2, andVC4🦋
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <clueInfo xmlns="urn:ietf:params:xml:ns:clue-info" xmlns:ns2="urn:ietf:params:xml:ns:vcard-4.0" clueInfoID="NapoliRoom"> <mediaCaptures> <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="audioCaptureType" captureID="AC0" mediaType="audio"> <captureSceneIDREF>CS1</captureSceneIDREF> <spatialInformation> <captureOrigin> <capturePoint> <x>0.0</x> <y>0.0</y> <z>10.0</z> </capturePoint> <lineOfCapturePoint> <x>0.0</x> <y>1.0</y> <z>10.0</z> </lineOfCapturePoint> </captureOrigin> </spatialInformation> <individual>true</individual> <encGroupIDREF>EG1</encGroupIDREF> <description lang="en">main audio from the room </description> <priority>1</priority> <lang>it</lang> <mobility>static</mobility> <view>room</view> <capturedPeople> <personIDREF>alice</personIDREF> <personIDREF>bob</personIDREF> <personIDREF>ciccio</personIDREF> </capturedPeople> </mediaCapture> <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="videoCaptureType" captureID="VC0" mediaType="video"> <captureSceneIDREF>CS1</captureSceneIDREF> <spatialInformation> <captureOrigin> <capturePoint> <x>-2.0</x> <y>0.0</y> <z>10.0</z> </capturePoint> </captureOrigin> <captureArea> <bottomLeft> <x>-3.0</x> <y>20.0</y> <z>9.0</z> </bottomLeft> <bottomRight> <x>-1.0</x> <y>20.0</y> <z>9.0</z> </bottomRight> <topLeft> <x>-3.0</x> <y>20.0</y> <z>11.0</z> </topLeft> <topRight> <x>-1.0</x> <y>20.0</y> <z>11.0</z> </topRight> </captureArea> </spatialInformation> <individual>true</individual> <encGroupIDREF>EG0</encGroupIDREF> <description lang="en">left camera video capture </description> <priority>1</priority> <lang>it</lang> <mobility>static</mobility> <view>individual</view> <capturedPeople> <personIDREF>ciccio</personIDREF> </capturedPeople> </mediaCapture> <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="videoCaptureType" captureID="VC1" mediaType="video"> <captureSceneIDREF>CS1</captureSceneIDREF> <spatialInformation> <captureOrigin> <capturePoint> <x>0.0</x> <y>0.0</y> <z>10.0</z> </capturePoint> </captureOrigin> <captureArea> <bottomLeft> <x>-1.0</x> <y>20.0</y> <z>9.0</z> </bottomLeft> <bottomRight> <x>1.0</x> <y>20.0</y> <z>9.0</z> </bottomRight> <topLeft> <x>-1.0</x> <y>20.0</y> <z>11.0</z> </topLeft> <topRight> <x>1.0</x> <y>20.0</y> <z>11.0</z> </topRight> </captureArea> </spatialInformation> <individual>true</individual> <encGroupIDREF>EG0</encGroupIDREF> <description lang="en">central camera video capture </description> <priority>1</priority> <lang>it</lang> <mobility>static</mobility> <view>individual</view> <capturedPeople> <personIDREF>alice</personIDREF> </capturedPeople> </mediaCapture> <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="videoCaptureType" captureID="VC2" mediaType="video"> <captureSceneIDREF>CS1</captureSceneIDREF> <spatialInformation> <captureOrigin> <capturePoint> <x>2.0</x> <y>0.0</y> <z>10.0</z> </capturePoint> </captureOrigin> <captureArea> <bottomLeft> <x>1.0</x> <y>20.0</y> <z>9.0</z> </bottomLeft> <bottomRight> <x>3.0</x> <y>20.0</y> <z>9.0</z> </bottomRight> <topLeft> <x>1.0</x> <y>20.0</y> <z>11.0</z> </topLeft> <topRight> <x>3.0</x> <y>20.0</y> <z>11.0</z> </topRight> </captureArea> </spatialInformation> <individual>true</individual> <encGroupIDREF>EG0</encGroupIDREF> <description lang="en">right camera video capture </description> <priority>1</priority> <lang>it</lang> <mobility>static</mobility> <view>individual</view> <capturedPeople> <personIDREF>bob</personIDREF> </capturedPeople> </mediaCapture> <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="videoCaptureType" captureID="VC3" mediaType="video"> <captureSceneIDREF>CS1</captureSceneIDREF> <spatialInformation> <captureArea> <bottomLeft> <x>-3.0</x> <y>20.0</y> <z>9.0</z> </bottomLeft> <bottomRight> <x>3.0</x> <y>20.0</y> <z>9.0</z> </bottomRight> <topLeft> <x>-3.0</x> <y>20.0</y> <z>11.0</z> </topLeft> <topRight> <x>3.0</x> <y>20.0</y> <z>11.0</z> </topRight> </captureArea> </spatialInformation> <content> <sceneViewIDREF>SE1</sceneViewIDREF> </content> <policy>SoundLevel:0</policy> <encGroupIDREF>EG0</encGroupIDREF> <description lang="en">loudest room segment</description> <priority>2</priority> <lang>it</lang> <mobility>static</mobility> <view>individual</view> </mediaCapture> <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="videoCaptureType" captureID="VC4" mediaType="video"> <captureSceneIDREF>CS1</captureSceneIDREF> <spatialInformation> <captureOrigin> <capturePoint> <x>0.0</x> <y>0.0</y> <z>10.0</z> </capturePoint> </captureOrigin> <captureArea> <bottomLeft> <x>-3.0</x> <y>20.0</y> <z>7.0</z> </bottomLeft> <bottomRight> <x>3.0</x> <y>20.0</y> <z>7.0</z> </bottomRight> <topLeft> <x>-3.0</x> <y>20.0</y> <z>13.0</z> </topLeft> <topRight> <x>3.0</x> <y>20.0</y> <z>13.0</z> </topRight> </captureArea> </spatialInformation> <individual>true</individual> <encGroupIDREF>EG0</encGroupIDREF> <description lang="en">zoomed-out view of all people in the room</description> <priority>2</priority> <lang>it</lang> <mobility>static</mobility> <view>room</view> <capturedPeople> <personIDREF>alice</personIDREF> <personIDREF>bob</personIDREF> <personIDREF>ciccio</personIDREF> </capturedPeople> </mediaCapture> </mediaCaptures> <encodingGroups> <encodingGroup encodingGroupID="EG0"> <maxGroupBandwidth>600000</maxGroupBandwidth> <encodingIDList> <encodingID>ENC1</encodingID> <encodingID>ENC2</encodingID> <encodingID>ENC3</encodingID> </encodingIDList> </encodingGroup> <encodingGroup encodingGroupID="EG1"> <maxGroupBandwidth>300000</maxGroupBandwidth> <encodingIDList> <encodingID>ENC4</encodingID> <encodingID>ENC5</encodingID> </encodingIDList> </encodingGroup> </encodingGroups> <captureScenes> <captureScene scale="unknown" sceneID="CS1"> <sceneViews>
<sceneView sceneViewID="SE1">
<mediaCaptureIDs>
<mediaCaptureIDREF>VC0</mediaCaptureIDREF>
<mediaCaptureIDREF>VC1</mediaCaptureIDREF>
<mediaCaptureIDREF>VC2</mediaCaptureIDREF>
</mediaCaptureIDs>
</sceneView>
<sceneView sceneViewID="SE2">
<mediaCaptureIDs>
<mediaCaptureIDREF>VC3</mediaCaptureIDREF>
</mediaCaptureIDs>
</sceneView>
<sceneView sceneViewID="SE3">
<mediaCaptureIDs>
<mediaCaptureIDREF>VC4</mediaCaptureIDREF>
</mediaCaptureIDs>
</sceneView>
<sceneView sceneViewID="SE4">
<mediaCaptureIDs>
<mediaCaptureIDREF>AC0</mediaCaptureIDREF>
</mediaCaptureIDs>
</sceneView>
</sceneViews>
</captureScene>
</captureScenes>
<simultaneousSets>
<simultaneousSet setID="SS1">
<mediaCaptureIDREF>VC3</mediaCaptureIDREF>
<sceneViewIDREF>SE1</sceneViewIDREF>
</simultaneousSet>
<simultaneousSet setID="SS2">
<mediaCaptureIDREF>VC0</mediaCaptureIDREF>
<mediaCaptureIDREF>VC2</mediaCaptureIDREF>
<mediaCaptureIDREF>VC4</mediaCaptureIDREF>
</simultaneousSet>
</simultaneousSets>
<people>
<person personID="bob">
<personInfo>
<ns2:fn>
<ns2:text>Bob</ns2:text>
</ns2:fn>
</personInfo>
<personType>minute taker</personType>
</person>
<person personID="alice">
<personInfo>
<ns2:fn>
<ns2:text>Alice</ns2:text>
</ns2:fn>
</personInfo>
<personType>presenter</personType>
</person>
<person personID="ciccio">
<personInfo>
<ns2:fn>
<ns2:text>Ciccio</ns2:text>
</ns2:fn>
</personInfo>
<personType>chairman</personType>
<personType>timekeeper</personType>
</person>
</people>
</clueInfo>28. MCC Example ✨
Okay so this one builds on the last example and it's giving main character energy 🎬💖. The Media Provider can now advertise a composed capture called VC7 🦋. It's a big picture showing the current speaker (VC3), with two picture-in-picture boxes for the previous speakers: the previous one (VC5) and the oldest one (VC6) 🌸.
The provider doesn't want to instantiate and send VC5 and VC6, so it doesn't link any encoding group to them 🙈. Their XML representations are still included anyway, so VC7 can be described properly ✨🫶.
Here's a possible description for that scenario, bestie 💅:
Okay bestie, the MCC example is giving full conference-room energy 🎀 Alice, Bob, and Ciccio are all sitting in NapoliRoom, and every capture gets its own little entry in the list ✨
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<clueInfo xmlns="urn:ietf:params:xml:ns:clue-info"
xmlns:ns2="urn:ietf:params:xml:ns:vcard-4.0" clueInfoID="NapoliRoom">
<mediaCaptures>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="audioCaptureType" captureID="AC0"
mediaType="audio">
<captureSceneIDREF>CS1</captureSceneIDREF>
<spatialInformation>
<captureOrigin>
<capturePoint>
<x>0.0</x>
<y>0.0</y>
<z>10.0</z>
</capturePoint>
<lineOfCapturePoint>
<x>0.0</x>
<y>1.0</y>
<z>10.0</z>
</lineOfCapturePoint>
</captureOrigin>
</spatialInformation>
<individual>true</individual>
<encGroupIDREF>EG1</encGroupIDREF>
<description lang="en">main audio from the room
</description>
<priority>1</priority>
<lang>it</lang>
<mobility>static</mobility>
<view>room</view>
<capturedPeople>
<personIDREF>alice</personIDREF>
<personIDREF>bob</personIDREF>
<personIDREF>ciccio</personIDREF>
</capturedPeople>
</mediaCapture>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="videoCaptureType" captureID="VC0"
mediaType="video">
<captureSceneIDREF>CS1</captureSceneIDREF>
<spatialInformation>
<captureOrigin>
<capturePoint>
<x>0.5</x>
<y>1.0</y>
<z>0.5</z>
</capturePoint>
<lineOfCapturePoint>
<x>0.5</x>
<y>0.0</y>
<z>0.5</z>
</lineOfCapturePoint>
</captureOrigin>
</spatialInformation>
<individual>true</individual>
<encGroupIDREF>EG0</encGroupIDREF>
<description lang="en">left camera video capture
</description>
<priority>1</priority>
<lang>it</lang>
<mobility>static</mobility>
<view>individual</view>
<capturedPeople>
<personIDREF>ciccio</personIDREF>
</capturedPeople>
</mediaCapture>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="videoCaptureType" captureID="VC1"
mediaType="video">
<captureSceneIDREF>CS1</captureSceneIDREF>
<spatialInformation>
<captureOrigin>
<capturePoint>
<x>0.0</x>
<y>0.0</y>
<z>10.0</z>
</capturePoint>
</captureOrigin>
<captureArea>
<bottomLeft>
<x>-1.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomLeft>
<bottomRight>
<x>1.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomRight>
<topLeft>
<x>-1.0</x>
<y>20.0</y>
<z>11.0</z>
</topLeft>
<topRight>
<x>1.0</x>
<y>20.0</y>
<z>11.0</z>
</topRight>
</captureArea>
</spatialInformation>
<individual>true</individual>
<encGroupIDREF>EG0</encGroupIDREF>
<description lang="en">central camera video capture
</description>
<priority>1</priority>
<lang>it</lang>
<mobility>static</mobility>
<view>individual</view>
<capturedPeople>
<personIDREF>alice</personIDREF>
</capturedPeople>
</mediaCapture>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="videoCaptureType" captureID="VC2"
mediaType="video">
<captureSceneIDREF>CS1</captureSceneIDREF>
<spatialInformation>
<captureOrigin>
<capturePoint>
<x>2.0</x>
<y>0.0</y>
<z>10.0</z>
</capturePoint>
</captureOrigin>
<captureArea>
<bottomLeft>
<x>1.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomLeft>
<bottomRight>
<x>3.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomRight>
<topLeft>
<x>1.0</x>
<y>20.0</y>
<z>11.0</z>
</topLeft>
<topRight>
<x>3.0</x>
<y>20.0</y>
<z>11.0</z>
</topRight>
</captureArea>
</spatialInformation>
<individual>true</individual>
<encGroupIDREF>EG0</encGroupIDREF>
<description lang="en">right camera video capture
</description>
<priority>1</priority>
<lang>it</lang>
<mobility>static</mobility>
<view>individual</view>
<capturedPeople>
<personIDREF>bob</personIDREF>
</capturedPeople>
</mediaCapture>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="videoCaptureType" captureID="VC3"
mediaType="video">
<captureSceneIDREF>CS1</captureSceneIDREF>
<spatialInformation>
<captureArea>
<bottomLeft>
<x>-3.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomLeft>
<bottomRight>
<x>3.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomRight>
<topLeft>
<x>-3.0</x>
<y>20.0</y>
<z>11.0</z>
</topLeft>
<topRight>
<x>3.0</x>
<y>20.0</y>
<z>11.0</z>
</topRight>
</captureArea>
</spatialInformation>
<content>
<sceneViewIDREF>SE1</sceneViewIDREF>
</content>
<policy>SoundLevel:0</policy>
<encGroupIDREF>EG0</encGroupIDREF>
<description lang="en">loudest room segment</description>
<priority>2</priority>
<lang>it</lang>
<mobility>static</mobility>
<view>individual</view>
</mediaCapture>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="videoCaptureType" captureID="VC4"
mediaType="video">
<captureSceneIDREF>CS1</captureSceneIDREF>
<spatialInformation>
<captureOrigin>
<capturePoint>
<x>0.0</x>
<y>0.0</y>
<z>10.0</z>
</capturePoint>
</captureOrigin>
<captureArea>
<bottomLeft>
<x>-3.0</x>
<y>20.0</y>
<z>7.0</z>
</bottomLeft>
<bottomRight>
<x>3.0</x>
<y>20.0</y>
<z>7.0</z>
</bottomRight>
<topLeft>
<x>-3.0</x>
<y>20.0</y>
<z>13.0</z>
</topLeft>
<topRight>
<x>3.0</x>
<y>20.0</y>
<z>13.0</z>
</topRight>
</captureArea>
</spatialInformation>
<individual>true</individual>
<encGroupIDREF>EG0</encGroupIDREF>
<description lang="en">
zoomed-out view of all people in the room
</description>
<priority>2</priority>
<lang>it</lang>
<mobility>static</mobility>
<view>room</view>
<capturedPeople>
<personIDREF>alice</personIDREF>
<personIDREF>bob</personIDREF>
<personIDREF>ciccio</personIDREF>
</capturedPeople>
</mediaCapture>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="videoCaptureType" captureID="VC5"
mediaType="video">
<captureSceneIDREF>CS1</captureSceneIDREF>
<spatialInformation>
<captureArea>
<bottomLeft>
<x>-3.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomLeft>
<bottomRight>
<x>3.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomRight>
<topLeft>
<x>-3.0</x>
<y>20.0</y>
<z>11.0</z>
</topLeft>
<topRight>
<x>3.0</x>
<y>20.0</y>
<z>11.0</z>
</topRight>
</captureArea>
</spatialInformation>
<content>
<sceneViewIDREF>SE1</sceneViewIDREF>
</content>
<policy>SoundLevel:1</policy>
<description lang="en">previous loudest room segment
per the most recent iteration of the sound level
detection algorithm
</description>The example keeps going from here, so we'll pick up the rest next 🦋
<lang>it</lang>
<mobility>static</mobility>
<view>individual</view>
</mediaCapture>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="videoCaptureType" captureID="VC6"
mediaType="video">
<captureSceneIDREF>CS1</captureSceneIDREF>
<spatialInformation>
<captureArea>
<bottomLeft>
<x>-3.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomLeft>
<bottomRight>
<x>3.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomRight>
<topLeft>
<x>-3.0</x>
<y>20.0</y>
<z>11.0</z>
</topLeft>
<topRight>
<x>3.0</x>
<y>20.0</y>
<z>11.0</z>
</topRight>
</captureArea>
</spatialInformation>
<content>
<sceneViewIDREF>SE1</sceneViewIDREF>
</content>
<policy>SoundLevel:2</policy>
<description lang="en">previous loudest room segment
per the second most recent iteration of the sound
level detection algorithm
</description>
<lang>it</lang>
<mobility>static</mobility>
<view>individual</view>
</mediaCapture>
<mediaCapture
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="videoCaptureType" captureID="VC7"
mediaType="video">
<captureSceneIDREF>CS1</captureSceneIDREF>
<spatialInformation>
<captureArea>
<bottomLeft>
<x>-3.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomLeft>
<bottomRight>
<x>3.0</x>
<y>20.0</y>
<z>9.0</z>
</bottomRight>
<topLeft>
<x>-3.0</x>
<y>20.0</y>
<z>11.0</z>
</topLeft>
<topRight>
<x>3.0</x>
<y>20.0</y>
<z>11.0</z>
</topRight>
</captureArea>
</spatialInformation>
<content>
<mediaCaptureIDREF>VC3</mediaCaptureIDREF>
<mediaCaptureIDREF>VC5</mediaCaptureIDREF>
<mediaCaptureIDREF>VC6</mediaCaptureIDREF>
</content>
<maxCaptures exactNumber="true">3</maxCaptures>
<encGroupIDREF>EG0</encGroupIDREF>
<description lang="en">big picture of the current
speaker + pips about previous speakers</description>
<priority>3</priority>
<lang>it</lang>
<mobility>static</mobility>
<view>individual</view>
</mediaCapture>
</mediaCaptures>
<encodingGroups>
<encodingGroup encodingGroupID="EG0">
<maxGroupBandwidth>600000</maxGroupBandwidth>
<encodingIDList>
<encodingID>ENC1</encodingID>
<encodingID>ENC2</encodingID>
<encodingID>ENC3</encodingID>
</encodingIDList>
</encodingGroup>
<encodingGroup encodingGroupID="EG1">
<maxGroupBandwidth>300000</maxGroupBandwidth>
<encodingIDList>
<encodingID>ENC4</encodingID>
<encodingID>ENC5</encodingID>
</encodingIDList>
</encodingGroup>
</encodingGroups>
<captureScenes>
<captureScene scale="unknown" sceneID="CS1">
<sceneViews>
<sceneView sceneViewID="SE1">
<description lang="en">participants' individual
videos</description>
<mediaCaptureIDs>
<mediaCaptureIDREF>VC0</mediaCaptureIDREF>
<mediaCaptureIDREF>VC1</mediaCaptureIDREF>
<mediaCaptureIDREF>VC2</mediaCaptureIDREF>
</mediaCaptureIDs>
</sceneView>
<sceneView sceneViewID="SE2">
<description lang="en">loudest segment of the
room</description>
<mediaCaptureIDs>
<mediaCaptureIDREF>VC3</mediaCaptureIDREF>
</mediaCaptureIDs>
</sceneView>
<sceneView sceneViewID="SE5">
<description lang="en">loudest segment of the
room + pips</description>
<mediaCaptureIDs>
<mediaCaptureIDREF>VC7</mediaCaptureIDREF>
</mediaCaptureIDs>
</sceneView>
<sceneView sceneViewID="SE4">
<description lang="en">room audio</description>
<mediaCaptureIDs>
<mediaCaptureIDREF>AC0</mediaCaptureIDREF>
</mediaCaptureIDs>
</sceneView>
<sceneView sceneViewID="SE3">
<description lang="en">room video</description>
<mediaCaptureIDs>
<mediaCaptureIDREF>VC4</mediaCaptureIDREF>
</mediaCaptureIDs>
</sceneView>
</sceneViews>
</captureScene>
</captureScenes>
<simultaneousSets>
<simultaneousSet setID="SS1">
<mediaCaptureIDREF>VC3</mediaCaptureIDREF>
<mediaCaptureIDREF>VC7</mediaCaptureIDREF>
<sceneViewIDREF>SE1</sceneViewIDREF>
</simultaneousSet>
<simultaneousSet setID="SS2">
<mediaCaptureIDREF>VC0</mediaCaptureIDREF>
<mediaCaptureIDREF>VC2</mediaCaptureIDREF>
<mediaCaptureIDREF>VC4</mediaCaptureIDREF>
</simultaneousSet>
</simultaneousSets>
<people>
<person personID="bob">
<personInfo>
<ns2:fn>
<ns2:text>Bob</ns2:text>
</ns2:fn>
</personInfo>
<personType>minute taker</personType>
</person>
<person personID="alice">
<personInfo>
<ns2:fn>
<ns2:text>Alice</ns2:text>
</ns2:fn>
</personInfo>
<personType>presenter</personType>
</person>
<person personID="ciccio">
<personInfo>
<ns2:fn>
<ns2:text>Ciccio</ns2:text>
</ns2:fn>
</personInfo>
<personType>chairman</personType>
<personType>timekeeper</personType>
</person>
</people>
</clueInfo>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. You're all literally the best, no cap 💖
Authors' Addresses 🎀
Roberta Presta
University of Napoli
Via Claudio 21
80125 Napoli
Italy
Email: roberta.presta@unina.itSimon Pietro Romano
University of Napoli
Via Claudio 21
80125 Napoli
Italy
Email: spromano@unina.it📦 where this page comes from
- ietf: rfc8846 2021-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms