rfc8847v2.txt   rfc8847.txt 
Internet Engineering Task Force (IETF) R. Presta Internet Engineering Task Force (IETF) R. Presta
Request for Comments: 8847 S P. Romano Request for Comments: 8847 S P. Romano
Category: Experimental University of Napoli Category: Experimental University of Napoli
ISSN: 2070-1721 July 2020 ISSN: 2070-1721 January 2021
Protocol for Controlling Multiple Streams for Telepresence (CLUE) Protocol for Controlling Multiple Streams for Telepresence (CLUE)
Abstract Abstract
The Controlling Multiple Streams for Telepresence (CLUE) protocol is The Controlling Multiple Streams for Telepresence (CLUE) protocol is
an application protocol conceived for the description and negotiation an application protocol conceived for the description and negotiation
of a telepresence session. The design of the CLUE protocol takes of a telepresence session. The design of the CLUE protocol takes
into account the requirements and the framework defined within the into account the requirements and the framework defined within the
IETF CLUE Working Group. A companion document, RFC 8848, delves into IETF CLUE Working Group. A companion document, RFC 8848, delves into
skipping to change at line 44 skipping to change at line 44
publication by the Internet Engineering Steering Group (IESG). Not publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841. Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8847. https://www.rfc-editor.org/info/rfc8847.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at line 82 skipping to change at line 82
6.1. Media Provider's State Machine 6.1. Media Provider's State Machine
6.2. Media Consumer's State Machine 6.2. Media Consumer's State Machine
7. Versioning 7. Versioning
8. Extensions 8. Extensions
8.1. Extension Example 8.1. Extension Example
9. XML Schema 9. XML Schema
10. Call Flow Example 10. Call Flow Example
10.1. CLUE Message No. 1: 'options' 10.1. CLUE Message No. 1: 'options'
10.2. CLUE Message No. 2: 'optionsResponse' 10.2. CLUE Message No. 2: 'optionsResponse'
10.3. CLUE Message No. 3: 'advertisement' 10.3. CLUE Message No. 3: 'advertisement'
10.4. CLUE Message No. 4: 'configure + ack' 10.4. CLUE Message No. 4: 'configure+ack'
10.5. CLUE Message No. 5: 'configureResponse' 10.5. CLUE Message No. 5: 'configureResponse'
10.6. CLUE Message No. 6: 'advertisement' 10.6. CLUE Message No. 6: 'advertisement'
10.7. CLUE Message No. 7: 'ack' 10.7. CLUE Message No. 7: 'ack'
10.8. CLUE Message No. 8: 'configure' 10.8. CLUE Message No. 8: 'configure'
10.9. CLUE Message No. 9: 'configureResponse' 10.9. CLUE Message No. 9: 'configureResponse'
11. Security Considerations 11. Security Considerations
12. IANA Considerations 12. IANA Considerations
12.1. URN Sub-Namespace Registration 12.1. URN Sub-Namespace Registration
12.2. XML Schema Registration 12.2. XML Schema Registration
12.3. Media Type Registration for "application/clue+xml" 12.3. Media Type Registration for "application/clue+xml"
skipping to change at line 170 skipping to change at line 170
conference [RFC7667]. An MCU includes a mixer (as defined in conference [RFC7667]. An MCU includes a mixer (as defined in
[RFC4353]), without the requirement per [RFC4353] to send media to [RFC4353]), without the requirement per [RFC4353] to send media to
each participant. each participant.
Media: Any data that, after suitable encoding, can be conveyed over Media: Any data that, after suitable encoding, can be conveyed over
RTP, including audio, video, or timed text. RTP, including audio, video, or timed text.
Media Capture: A source of media -- for example, from one or more Media Capture: A source of media -- for example, from one or more
Capture Devices or constructed from other Media streams. Capture Devices or constructed from other Media streams.
Media Consumer (MC): A CLUE Participant (i.e., an Endpoint or an Media Consumer (MC): A CP (i.e., an Endpoint or an MCU) able to
MCU) able to receive Capture Encodings. receive Capture Encodings.
Media Provider (MP): A CLUE Participant (i.e., an Endpoint or an Media Provider (MP): A CP (i.e., an Endpoint or an MCU) able to send
MCU) able to send Capture Encodings. Capture Encodings.
Stream: A Capture Encoding sent from a Media Provider to a Media Stream: A Capture Encoding sent from an MP to an MC via RTP
Consumer via RTP [RFC3550]. [RFC3550].
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. Overview of the CLUE Protocol 4. Overview of the CLUE Protocol
skipping to change at line 199 skipping to change at line 199
The CLUE protocol is conceived to enable CLUE telepresence sessions. The CLUE protocol is conceived to enable CLUE telepresence sessions.
It is designed to address Session Description Protocol (SDP) It is designed to address Session Description Protocol (SDP)
limitations in terms of the description of some information about the limitations in terms of the description of some information about the
multimedia streams that are involved in a real-time multimedia multimedia streams that are involved in a real-time multimedia
conference. Indeed, by simply using SDP, it is not possible to conference. Indeed, by simply using SDP, it is not possible to
convey information about the features of the flowing multimedia convey information about the features of the flowing multimedia
streams that are needed to enable a "being there" rendering streams that are needed to enable a "being there" rendering
experience. Such information is contained in the CLUE framework experience. Such information is contained in the CLUE framework
document [RFC8845] and formally defined and described in the CLUE document [RFC8845] and formally defined and described in the CLUE
data model document [RFC8846]. The CLUE protocol represents the data model document [RFC8846]. The CLUE protocol represents the
mechanism for the exchange of telepresence information between CLUE mechanism for the exchange of telepresence information between CPs.
Participants. It mainly provides the messages to enable a Media It mainly provides the messages to enable an MP to advertise its
Provider to advertise its telepresence capabilities and to enable a telepresence capabilities and to enable an MC to select the desired
Media Consumer to select the desired telepresence options. telepresence options.
The CLUE protocol, as defined in this document and further described The CLUE protocol, as defined in this document and further described
below, is a stateful client-server XML-based application protocol. below, is a stateful client-server XML-based application protocol.
CLUE protocol messages flow on a reliable and ordered SCTP-over-DTLS CLUE protocol messages flow on a reliable and ordered SCTP-over-DTLS
transport channel connecting two CLUE Participants. Messages carry transport channel connecting two CPs. Messages carry information
information taken from the XML-based CLUE data model [RFC8846]. taken from the XML-based CLUE data model [RFC8846]. Three main
Three main communication phases can be identified: communication phases can be identified:
Establishment of the CLUE data channel: Establishment of the CLUE data channel:
In this phase, the CLUE data channel setup takes place. If it In this phase, the CLUE data channel setup takes place. If it
completes successfully, the CPs are able to communicate and start completes successfully, the CPs are able to communicate and start
the initiation phase. the initiation phase.
Negotiation of the CLUE protocol version and extensions Negotiation of the CLUE protocol version and extensions
(initiation phase): (initiation phase):
The CPs connected via the CLUE data channel agree on the protocol The CPs connected via the CLUE data channel agree on the protocol
version and extensions to be used during the telepresence session. version and extensions to be used during the telepresence session.
Special CLUE messages are used for such a task ('options' and Special CLUE messages are used for such a task ('options' and
'optionsResponse'). The negotiation of the version and extensions 'optionsResponse'). The negotiation of the version and extensions
can be performed once during the CLUE session and only at this can be performed once during the CLUE session and only at this
stage. At the end of that basic negotiation, each CP starts its stage. At the end of that basic negotiation, each CP starts its
activity as a CLUE MP and/or CLUE MC. activity as a CLUE MP and/or CLUE MC.
Description and negotiation of CLUE telepresence capabilities: Description and negotiation of CLUE telepresence capabilities:
In this phase, the MP-MC dialogues take place on the data channel In this phase, the MP-MC dialogues take place on the data channel
by means of the CLUE protocol messages. by means of the CLUE protocol messages.
As soon as the channel is ready, the CLUE Participants must agree on As soon as the channel is ready, the CPs must agree on the protocol
the protocol version and extensions to be used within the version and extensions to be used within the telepresence session.
telepresence session. CLUE protocol version numbers are CLUE protocol version numbers are characterized by a major version
characterized by a major version number and a minor version number, number and a minor version number, both unsigned integers, separated
both unsigned integers, separated by a dot. While minor version by a dot. While minor version numbers denote backward-compatible
numbers denote backward-compatible changes in the context of a given changes in the context of a given major version, different major
major version, different major version numbers generally indicate a version numbers generally indicate a lack of interoperability between
lack of interoperability between the protocol implementations. In the protocol implementations. In order to correctly establish a CLUE
order to correctly establish a CLUE dialogue, the involved CPs must dialogue, the involved CPs must have in common a major version number
have in common a major version number (see Section 7 for further (see Section 7 for further details). The subset of the extensions
details). The subset of the extensions that are allowed within the that are allowed within the CLUE session is also determined in the
CLUE session is also determined in the initiation phase. It includes initiation phase. It includes only the extensions that are supported
only the extensions that are supported by both parties. A mechanism by both parties. A mechanism for the negotiation of the CLUE
for the negotiation of the CLUE protocol version and extensions is protocol version and extensions is part of the initiation phase.
part of the initiation phase. According to such a solution, the CP According to such a solution, the CP that is the CLUE Channel
that is the CLUE Channel Initiator (CI) issues a proper CLUE message Initiator (CI) issues a proper CLUE message ('options') to the CP
('options') to the CP that is the Channel Receiver (CR), specifying that is the Channel Receiver (CR), specifying the supported version
the supported version and extensions. The CR then answers by and extensions. The CR then answers by selecting the subset of the
selecting the subset of the CI extensions that it is able to support CI extensions that it is able to support and determines the protocol
and determines the protocol version to be used. version to be used.
After the negotiation phase is completed, CLUE Participants describe After the negotiation phase is completed, CPs describe and agree on
and agree on the media flows to be exchanged. In many cases, CPs the media flows to be exchanged. In many cases, CPs will seek to
will seek to both transmit and receive media. Hence, in a call both transmit and receive media. Hence, in a call between two CPs
between two CPs (e.g., CPs A and B), there would be two separate (e.g., CPs A and B), there would be two separate message exchange
message exchange sequences, as follows: sequences, as follows:
1. the one needed to describe and set up the media streams sent from 1. the one needed to describe and set up the media streams sent from
A to B, i.e., the dialogue between A's Media Provider side and A to B, i.e., the dialogue between A's MP side and B's MC side.
B's Media Consumer side.
2. the one needed to describe and set up the media streams sent from 2. the one needed to describe and set up the media streams sent from
B to A, i.e., the dialogue between B's Media Provider side and B to A, i.e., the dialogue between B's MP side and A's MC side.
A's Media Consumer side.
CLUE messages for the media session description and negotiation are CLUE messages for the media session description and negotiation are
designed by considering the MP side to be the server side of the designed by considering the MP side to be the server side of the
protocol, since it produces and provides media streams, and the MC protocol, since it produces and provides media streams, and the MC
side as the client side of the protocol, since it requests and side as the client side of the protocol, since it requests and
receives media streams. The messages that are exchanged to set up receives media streams. The messages that are exchanged to set up
the telepresence media session are described by focusing on a single the telepresence media session are described by focusing on a single
MP-MC dialogue. MP-MC dialogue.
The MP first advertises its available media captures and encoding The MP first advertises its available media captures and encoding
skipping to change at line 319 skipping to change at line 317
* ack * ack
* configure * configure
* configureResponse * configureResponse
While the 'options' and 'optionsResponse' messages are exchanged in While the 'options' and 'optionsResponse' messages are exchanged in
the initiation phase between the CPs, the other messages are involved the initiation phase between the CPs, the other messages are involved
in MP-MC dialogues. Please note that the word "dialogue" as used in in MP-MC dialogues. Please note that the word "dialogue" as used in
this document is not related to SIP's usage of the same term. It this document is not related to SIP's usage of the same term. It
refers to message exchange sequences between a CLUE Media Provider refers to message exchange sequences between a CLUE MP and a Clue MC.
and a Clue Media Consumer.
Each CLUE message inherits a basic structure, as depicted in the Each CLUE message inherits a basic structure, as depicted in the
following excerpt (Figure 1): following excerpt (Figure 1):
<xs:complexType name="clueMessageType" abstract="true"> <xs:complexType name="clueMessageType" abstract="true">
<xs:sequence> <xs:sequence>
<xs:element name="clueId" type="xs:string" minOccurs="0"/> <xs:element name="clueId" type="xs:string" minOccurs="0"/>
<xs:element name="sequenceNr" type="xs:positiveInteger"/> <xs:element name="sequenceNr" type="xs:positiveInteger"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="protocol" type="xs:string" fixed="CLUE" <xs:attribute name="protocol" type="xs:string" fixed="CLUE"
skipping to change at line 373 skipping to change at line 370
content of the "v" attribute is composed of the major version content of the "v" attribute is composed of the major version
number followed by a dot and then by the minor version number of number followed by a dot and then by the minor version number of
the CLUE protocol in use. The major number cannot be "0", and if the CLUE protocol in use. The major number cannot be "0", and if
it is more than one digit, it cannot start with a "0". Allowed it is more than one digit, it cannot start with a "0". Allowed
values of this kind are "1.3", "2.0", "20.44", etc. This document values of this kind are "1.3", "2.0", "20.44", etc. This document
describes version 1.0. describes version 1.0.
Each CP is responsible for creating and updating up to three Each CP is responsible for creating and updating up to three
independent streams of sequence numbers in messages it sends: (i) one independent streams of sequence numbers in messages it sends: (i) one
for the messages sent in the initiation phase, (ii) one for the for the messages sent in the initiation phase, (ii) one for the
messages sent as a MP (if it is acting as a MP), and (iii) one for messages sent as an MP (if it is acting as an MP), and (iii) one for
the messages sent as a MC (if it is acting as a MC). the messages sent as an MC (if it is acting as an MC).
In particular, CLUE response messages ('optionsResponse', 'ack', In particular, CLUE response messages ('optionsResponse', 'ack',
'configureResponse') derive from a base type, inheriting from the 'configureResponse') derive from a base type, inheriting from the
clueMessageType, which is defined as follows (Figure 2): clueMessageType, which is defined as follows (Figure 2):
<xs:complexType name="clueResponseType"> <xs:complexType name="clueResponseType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="clueMessageType"> <xs:extension base="clueMessageType">
<xs:sequence> <xs:sequence>
<xs:element name="responseCode" type="responseCodeType"/> <xs:element name="responseCode" type="responseCodeType"/>
skipping to change at line 398 skipping to change at line 395
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
Figure 2: Structure of CLUE Response Messages Figure 2: Structure of CLUE Response Messages
The elements <responseCode> and <reasonString> are populated as The elements <responseCode> and <reasonString> are populated as
detailed in Section 5.7. detailed in Section 5.7.
5.1. 'options' 5.1. 'options'
The 'options' message is sent by the CLUE Participant that is the The 'options' message is sent by the CP that is the CI to the CP that
Channel Initiator to the CLUE Participant that is the Channel is the CR as soon as the CLUE data channel is ready. Besides the
Receiver as soon as the CLUE data channel is ready. Besides the
information envisioned in the basic structure, it specifies: information envisioned in the basic structure, it specifies:
<mediaProvider>: A mandatory boolean field set to "true" if the CP <mediaProvider>: A mandatory boolean field set to "true" if the CP
is able to act as a MP. is able to act as an MP.
<mediaConsumer>: A mandatory boolean field set to "true" if the CP <mediaConsumer>: A mandatory boolean field set to "true" if the CP
is able to act as a MC. is able to act as an MC.
<supportedVersions>: The list of supported versions. <supportedVersions>: The list of supported versions.
<supportedExtensions>: The list of supported extensions. <supportedExtensions>: The list of supported extensions.
The XML schema of such a message is shown below (Figure 3): The XML schema of such a message is shown below (Figure 3):
<!-- CLUE OPTIONS --> <!-- CLUE OPTIONS -->
<xs:complexType name="optionsMessageType"> <xs:complexType name="optionsMessageType">
<xs:complexContent> <xs:complexContent>
skipping to change at line 480 skipping to change at line 476
content of each <version> element is a string made of the major content of each <version> element is a string made of the major
version number followed by a dot and then by the minor version number version number followed by a dot and then by the minor version number
(e.g., 1.3 or 2.4). Exactly one <version> element MUST be provided (e.g., 1.3 or 2.4). Exactly one <version> element MUST be provided
for each major version supported, containing the maximum minor for each major version supported, containing the maximum minor
version number of such a version, since all minor versions are version number of such a version, since all minor versions are
backward compatible. If no <supportedVersions> is carried within the backward compatible. If no <supportedVersions> is carried within the
'options' message, the CI supports only the version declared in the 'options' message, the CI supports only the version declared in the
"v" attribute and all the versions having the same major version "v" attribute and all the versions having the same major version
number and lower minor version number. For example, if the "v" number and lower minor version number. For example, if the "v"
attribute has a value of "3.4" and there is no <supportedVersions> attribute has a value of "3.4" and there is no <supportedVersions>
tag in the 'options' message, it means the CI supports only major element in the 'options' message, it means the CI supports only major
version 3 with all minor versions from 3.0 through 3.4. If version 3 with all minor versions from 3.0 through 3.4. If
<supportedVersion> is provided, at least one <version> tag MUST be <supportedVersions> is provided, at least one <version> element MUST
included. In this case, the "v" attribute SHOULD be set to the be included. In this case, the "v" attribute SHOULD be set to the
largest minor version of the smallest major version advertised in the largest minor version of the smallest major version advertised in the
<supportedVersions> list. Indeed, the intention behind the "v" <supportedVersions> list. Indeed, the intention behind the "v"
attribute is that some implementation that receives a version number attribute is that some implementation that receives a version number
in the "v" field with a major number higher than it understands is in the "v" field with a major number higher than it understands is
supposed to close the connection, since it runs a risk of supposed to close the connection, since it runs a risk of
misinterpreting the contents of messages. The minor version is less misinterpreting the contents of messages. The minor version is less
useful in this context, since minor versions are defined to be both useful in this context, since minor versions are defined to be both
backward and forward compatible and the value can in any case be backward and forward compatible and the value can in any case be
parsed out of the <version> list. It is more useful to know the parsed out of the <version> list. It is more useful to know the
highest minor version supported than some random minor version, as it highest minor version supported than some random minor version, as it
skipping to change at line 516 skipping to change at line 512
The 'optionsResponse' (Figure 4) is sent by a CR to a CI as a reply The 'optionsResponse' (Figure 4) is sent by a CR to a CI as a reply
to the 'options' message. The 'optionsResponse' contains a mandatory to the 'options' message. The 'optionsResponse' contains a mandatory
response code and a reason string indicating the processing result of response code and a reason string indicating the processing result of
the 'options' message. If the responseCode is between 200 and 299 the 'options' message. If the responseCode is between 200 and 299
inclusive, the response MUST also include <mediaProvider>, inclusive, the response MUST also include <mediaProvider>,
<mediaConsumer>, <version>, and <commonExtensions> elements; it MAY <mediaConsumer>, <version>, and <commonExtensions> elements; it MAY
include them for any other response code. <mediaProvider> and include them for any other response code. <mediaProvider> and
<mediaConsumer> elements (which are of a boolean nature) are <mediaConsumer> elements (which are of a boolean nature) are
associated with the supported roles (in terms of the MP and the MC, associated with the supported roles (in terms of the MP and the MC,
respectively), similarly to what the CI does in the 'options' respectively), similarly to what the CI does in the 'options'
message. The <version> field indicates the highest commonly message. The <version> element indicates the highest commonly
supported version number. The content of the <version> element MUST supported version number. The content of the <version> element MUST
be a string made of the major version number followed by a dot and be a string made of the major version number followed by a dot and
then by the minor version number (e.g., 1.3 or 2.4). Finally, the then by the minor version number (e.g., 1.3 or 2.4). Finally, the
commonly supported extensions are copied in the <commonExtensions> commonly supported extensions are copied in the <commonExtensions>
field. element.
<!-- CLUE 'optionsResponse' --> <!-- CLUE 'optionsResponse' -->
<xs:complexType name="optionsResponseMessageType"> <xs:complexType name="optionsResponseMessageType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="clueResponseType"> <xs:extension base="clueResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="mediaProvider" type="xs:boolean" <xs:element name="mediaProvider" type="xs:boolean"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="mediaConsumer" type="xs:boolean" <xs:element name="mediaConsumer" type="xs:boolean"
minOccurs="0"/> minOccurs="0"/>
skipping to change at line 546 skipping to change at line 542
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/> <xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
Figure 4: Structure of a CLUE 'optionsResponse' Message Figure 4: Structure of a CLUE 'optionsResponse' Message
Upon reception of the 'optionsResponse', the version to be used is Upon reception of the 'optionsResponse', the version to be used is
the one provided in the <version> tag of the message. The subsequent the one provided in the <version> element of the message. The
CLUE messages MUST use such a version number in the "v" attribute. subsequent CLUE messages MUST use such a version number in the "v"
The allowed extensions in the CLUE dialogue are those indicated in attribute. The allowed extensions in the CLUE dialogue are those
the <commonExtensions> element of the 'optionsResponse' message. indicated in the <commonExtensions> element of the 'optionsResponse'
message.
5.3. 'advertisement' 5.3. 'advertisement'
The 'advertisement' message is used by each MP to advertise the The 'advertisement' message is used by each MP to advertise the
available media captures and related information to the corresponding available media captures and related information to the corresponding
MC. The MP sends an 'advertisement' to the MC as soon as it is ready MC. The MP sends an 'advertisement' to the MC as soon as it is ready
after the successful completion of the initiation phase, i.e., as after the successful completion of the initiation phase, i.e., as
soon as the CPs have agreed on the version and extensions of the CLUE soon as the CPs have agreed on the version and extensions of the CLUE
protocol. During a single CLUE session, an MP may send new protocol. During a single CLUE session, an MP may send new
'advertisement' messages to replace the previous advertisement if, 'advertisement' messages to replace the previous advertisement if,
skipping to change at line 616 skipping to change at line 613
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/> <xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
Figure 5: Structure of a CLUE 'advertisement' Message Figure 5: Structure of a CLUE 'advertisement' Message
5.4. 'ack' 5.4. 'ack'
The 'ack' message is sent by a MC to a MP to acknowledge an The 'ack' message is sent by an MC to an MP to acknowledge an
'advertisement' message. As can be seen from the message schema 'advertisement' message. As can be seen from the message schema
provided in the following excerpt (Figure 6), the 'ack' contains a provided in the following excerpt (Figure 6), the 'ack' contains a
response code and may contain a reason string for describing the response code and may contain a reason string for describing the
processing result of the 'advertisement'. The <advSequenceNr> processing result of the 'advertisement'. The <advSequenceNr>
element carries the sequence number of the 'advertisement' message element carries the sequence number of the 'advertisement' message
the 'ack' refers to. the 'ack' refers to.
<!-- 'ack' MESSAGE TYPE --> <!-- 'ack' MESSAGE TYPE -->
<xs:complexType name="advAcknowledgementMessageType"> <xs:complexType name="advAcknowledgementMessageType">
<xs:complexContent> <xs:complexContent>
skipping to change at line 642 skipping to change at line 639
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/> <xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
Figure 6: Structure of a CLUE 'ack' Message Figure 6: Structure of a CLUE 'ack' Message
5.5. 'configure' 5.5. 'configure'
The 'configure' message is sent from a MC to a MP to list the The 'configure' message is sent from an MC to an MP to list the
advertised captures the MC wants to receive. The MC MUST send a advertised captures the MC wants to receive. The MC MUST send a
'configure' after the reception of an 'advertisement', as well as 'configure' after the reception of an 'advertisement', as well as
each time it wants to request other captures that have been each time it wants to request other captures that have been
previously advertised by the MP. The content of the 'configure' previously advertised by the MP. The content of the 'configure'
message is shown below (Figure 7). message is shown below (Figure 7).
<!-- CLUE 'configure' MESSAGE TYPE --> <!-- CLUE 'configure' MESSAGE TYPE -->
<xs:complexType name="configureMessageType"> <xs:complexType name="configureMessageType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="clueMessageType"> <xs:extension base="clueMessageType">
skipping to change at line 676 skipping to change at line 673
</xs:complexType> </xs:complexType>
Figure 7: Structure of a CLUE 'configure' Message Figure 7: Structure of a CLUE 'configure' Message
The <advSequenceNr> element contains the sequence number of the The <advSequenceNr> element contains the sequence number of the
'advertisement' message the 'configure' refers to. 'advertisement' message the 'configure' refers to.
The optional <ack> element, when present, contains a success response The optional <ack> element, when present, contains a success response
code, as defined in Section 5.7. It indicates that the 'configure' code, as defined in Section 5.7. It indicates that the 'configure'
message also acknowledges with success the referred advertisement message also acknowledges with success the referred advertisement
('configure' + 'ack' message). The <ack> element MUST NOT be present ('configure+ack' message). The <ack> element MUST NOT be present if
if an 'ack' message (associated with the advertisement carrying that an 'ack' message (associated with the advertisement carrying that
specific sequence number) has already been sent back to the MP. specific sequence number) has already been sent back to the MP.
The most important content of the 'configure' message is the list of The most important content of the 'configure' message is the list of
capture encodings provided in the <captureEncodings> element (see capture encodings provided in the <captureEncodings> element (see
[RFC8846] for the definition of <captureEncodings>). Such an element [RFC8846] for the definition of <captureEncodings>). Such an element
contains a sequence of capture encodings, representing the streams to contains a sequence of capture encodings, representing the streams to
be instantiated. be instantiated.
5.6. 'configureResponse' 5.6. 'configureResponse'
The 'configureResponse' message is sent from the MP to the MC to The 'configureResponse' message is sent from the MP to the MC to
communicate the processing result of requests carried in the communicate the processing result of requests carried in the
previously received 'configure' message. As shown in Figure 8, it previously received 'configure' message. As shown in Figure 8, it
contains a response code (and, optionally, a reason string) contains a response code (and, optionally, a reason string)
indicating either the success or failure (along with failure details) indicating either the success or failure (along with failure details)
of the 'configure' request processing. The <confSequenceNr> field of the 'configure' request processing. The <confSequenceNr> element
that follows contains the sequence number of the 'configure' message that follows contains the sequence number of the 'configure' message
the response refers to. There is no partial execution of commands. the response refers to. There is no partial execution of commands.
As an example, if a MP is able to understand all the selected capture As an example, if an MP is able to understand all the selected
encodings except one, then the whole command fails and nothing is capture encodings except one, then the whole command fails and
instantiated. nothing is instantiated.
<!-- 'configureResponse' MESSAGE TYPE --> <!-- 'configureResponse' MESSAGE TYPE -->
<xs:complexType name="configureResponseMessageType"> <xs:complexType name="configureResponseMessageType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="clueResponseType"> <xs:extension base="clueResponseType">
<xs:sequence> <xs:sequence>
<xs:element name="confSequenceNr" <xs:element name="confSequenceNr"
type="xs:positiveInteger" /> type="xs:positiveInteger" />
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0"/> minOccurs="0"/>
skipping to change at line 807 skipping to change at line 804
+----------+---------------+----------------------------------------+ +----------+---------------+----------------------------------------+
Table 1: CLUE Response Codes Table 1: CLUE Response Codes
6. Protocol State Machines 6. Protocol State Machines
The CLUE protocol is an application protocol used between two CPs in The CLUE protocol is an application protocol used between two CPs in
order to properly configure a multimedia telepresence session. CLUE order to properly configure a multimedia telepresence session. CLUE
protocol messages flow over the CLUE data channel, an SCTP-over-DTLS protocol messages flow over the CLUE data channel, an SCTP-over-DTLS
channel established as depicted in [RFC8850]. We herein discuss the channel established as depicted in [RFC8850]. We herein discuss the
state machines associated with the CLUE Participant (Figure 9), the state machines associated with the CP (Figure 9), the MP role
MP role (Figure 10 in Section 6.1), and the MC role (Figure 11 in (Figure 10 in Section 6.1), and the MC role (Figure 11 in
Section 6.2), respectively. Endpoints often wish to both send and Section 6.2), respectively. Endpoints often wish to both send and
receive media, i.e., act as both a MP and a MC. As such, there will receive media, i.e., act as both an MP and an MC. As such, there
often be two sets of messages flowing in opposite directions; the will often be two sets of messages flowing in opposite directions;
state machines of these two flows do not interact with each other. the state machines of these two flows do not interact with each
Only the CLUE application logic is considered. The interaction of other. Only the CLUE application logic is considered. The
CLUE protocol and SDP negotiations for the media streams exchanged is interaction of CLUE protocol and SDP negotiations for the media
discussed in [RFC8848]. streams exchanged is discussed in [RFC8848].
+----+ +----+
+---------------------->|IDLE|<----------------------------+ +---------------------->|IDLE|<----------------------------+
| +-+--+ | | +-+--+ |
| | | | | |
| | start | | | start |
| | channel | | | channel |
| v | | v |
| channel error / +--------+ | | channel error / +--------+ |
| session ends | CHANNEL| | | session ends | CHANNEL| |
skipping to change at line 854 skipping to change at line 851
| +----+ | CLUE messages | | +----+ | CLUE messages |
| |<-----------------+ | |<-----------------+
| +----+ | | +----+ |
| | MC | | | | MC | |
| +----+ | | +----+ |
| | | |
+---------+ +---------+
Figure 9: CLUE Participant State Machine Figure 9: CLUE Participant State Machine
The main state machines focus on the behavior of the CLUE Participant The main state machines focus on the behavior of the CP acting as a
(CP) acting as a CLUE Channel Initiator / Channel Receiver (CI/CR). CLUE CI/CR.
The initial state is the IDLE state. When in the IDLE state, the The initial state is the IDLE state. When in the IDLE state, the
CLUE data channel is not established and no CLUE-controlled media are CLUE data channel is not established and no CLUE-controlled media are
exchanged between the two CLUE-capable devices in question (if there exchanged between the two CLUE-capable devices in question (if there
is an ongoing exchange of media streams, such media streams are not is an ongoing exchange of media streams, such media streams are not
currently CLUE controlled). currently CLUE controlled).
When the CLUE data channel is set up ("start channel"), the CP moves When the CLUE data channel is set up ("start channel"), the CP moves
from the IDLE state to the CHANNEL SETUP state. from the IDLE state to the CHANNEL SETUP state.
skipping to change at line 911 skipping to change at line 908
'options'/'optionsResponse' message, it MUST ignore the message and 'options'/'optionsResponse' message, it MUST ignore the message and
stay in the ACTIVE state. stay in the ACTIVE state.
6.1. Media Provider's State Machine 6.1. Media Provider's State Machine
As soon as the sub-state machine of the MP (Figure 10) is activated, As soon as the sub-state machine of the MP (Figure 10) is activated,
it is in the ADV state. In the ADV state, the MP prepares the it is in the ADV state. In the ADV state, the MP prepares the
'advertisement' message reflecting its actual telepresence 'advertisement' message reflecting its actual telepresence
capabilities. capabilities.
+-----+ +-----+
+------------>| ADV |<-------------------+ +------------>| ADV |<-------------------+
| +-+---+ | | +-+---+ |
| advertisement| NACK received | | advertisement| NACK received |
| sent| | | sent| |
| v | | v |
changed| +--------+ | changed| +--------+ |
telepresence+-------------+WAIT FOR+-----------------+ telepresence+-------------+WAIT FOR+-----------------+
settings| +----------+ ACK | settings| +----------+ ACK |
| |configure +-+------+ | |configure +-+------+
| | + ack | | | +ack |
| |received |ack received | |received |ack received
| | v | | v
| | +--------+ | | +--------+
+-------------+WAIT FOR| +-------------+WAIT FOR|
| | | CONF | | | | CONF |
| | +-+------+<-----------------------------+ | | +-+------+<-----------------------------+
| | | | | | | |
| | |configure received | | | |configure received |
| | v | | | v |
| +--------->+---------+ error configureResponse sent| | +--------->+---------+ error configureResponse sent|
+-------------+CONF |-----------------------------+ +-------------+CONF |-----------------------------+
| +--------->|RESPONSE + | +--------->|RESPONSE +
| | +---------+ | | +---------+
| | | | | |
| | |successful | | |successful
| | |configureResponse | | |configureResponse
| | |sent | | |sent
| | | | | |
| | | | | |
| |configure | | |configure |
| |received v | |received v
| | +-----------+ | | +-----------+
| +----------+ESTABLISHED| | +----------+ESTABLISHED|
+-------------+-----------+ +-------------+-----------+
Figure 10: Media Provider's State Machine Figure 10: Media Provider's State Machine
After the 'advertisement' has been sent ("advertisement sent"), the After the 'advertisement' has been sent ("advertisement sent"), the
MP moves from the ADV state to the WAIT FOR ACK state. If an 'ack' MP moves from the ADV state to the WAIT FOR ACK state. If an 'ack'
message with a successful response code arrives ("ack received"), the message with a successful response code arrives ("ack received"), the
MP moves to the WAIT FOR CONF state. If a NACK arrives (i.e., an MP moves to the WAIT FOR CONF state. If a NACK arrives (i.e., an
'ack' message with an error response code), the MP moves back to the 'ack' message with an error response code), the MP moves back to the
ADV state for preparation of a new 'advertisement'. When in the WAIT ADV state for preparation of a new 'advertisement'. When in the WAIT
FOR ACK state, if a 'configure' message with the <ack> element set to FOR ACK state, if a 'configure' message with the <ack> element set to
skipping to change at line 1050 skipping to change at line 1047
Figure 11: Media Consumer's State Machine Figure 11: Media Consumer's State Machine
In the ADV PROCESSING state, the 'advertisement' is parsed by the MC. In the ADV PROCESSING state, the 'advertisement' is parsed by the MC.
If the 'advertisement' is successfully processed, two scenarios are If the 'advertisement' is successfully processed, two scenarios are
possible. In the first case, the MC issues a successful 'ack' possible. In the first case, the MC issues a successful 'ack'
message to the MP ("ack sent") and moves to the CONF state. This message to the MP ("ack sent") and moves to the CONF state. This
typically happens when the MC needs some more time to produce the typically happens when the MC needs some more time to produce the
'configure' message associated with the received 'advertisement'. In 'configure' message associated with the received 'advertisement'. In
the latter case, the MC is able to immediately prepare and send back the latter case, the MC is able to immediately prepare and send back
to the MP a 'configure' message. Such a message will have the <ack> to the MP a 'configure' message. Such a message will have the <ack>
field set to "200" ("configure+ack sent") and will allow the MC to element set to "200" ("configure+ack sent") and will allow the MC to
move directly to the WAIT FOR CONF RESPONSE state. move directly to the WAIT FOR CONF RESPONSE state.
If the processing of the 'advertisement' is unsuccessful (bad syntax, If the processing of the 'advertisement' is unsuccessful (bad syntax,
missing XML elements, etc.), the MC sends a NACK message (i.e., an missing XML elements, etc.), the MC sends a NACK message (i.e., an
'ack' with an error response code) to the MP and, optionally, further 'ack' with an error response code) to the MP and, optionally, further
describes the problem via a proper reason phrase. In this scenario describes the problem via a proper reason phrase. In this scenario
("NACK sent"), the MC switches back to the WAIT FOR ADV state and ("NACK sent"), the MC switches back to the WAIT FOR ADV state and
waits for a new 'advertisement'. waits for a new 'advertisement'.
When in the CONF state, the MC prepares the 'configure' request to be When in the CONF state, the MC prepares the 'configure' request to be
skipping to change at line 1108 skipping to change at line 1105
server have to test the compliance of the received messages with the server have to test the compliance of the received messages with the
XML schema of the CLUE protocol. If the compliance is not verified, XML schema of the CLUE protocol. If the compliance is not verified,
the message cannot be processed further. the message cannot be processed further.
The client and server cannot communicate if they do not share exactly The client and server cannot communicate if they do not share exactly
the same XML schema. Such a schema is associated with the CLUE URN the same XML schema. Such a schema is associated with the CLUE URN
"urn:ietf:params:xml:ns:clue-protocol". If all CLUE-enabled devices "urn:ietf:params:xml:ns:clue-protocol". If all CLUE-enabled devices
use that schema, there will be no interoperability problems due to use that schema, there will be no interoperability problems due to
schema issues. schema issues.
This document uses XML schema version 1.0 [W3C.REC-xml-20081126]. This document defines version 1.0 of the CLUE protocol schema, using
The version usage is similar in philosophy to the Extensible XML schema version 1.0 [W3C.REC-xml-20081126]. The version usage is
Messaging and Presence Protocol (XMPP) [RFC6120]. A version number similar in philosophy to the Extensible Messaging and Presence
has major and minor components, each a non-negative integer. Changes Protocol (XMPP) [RFC6120]. A version number has major and minor
to the major version denote non-interoperable changes. Changes to components, each a non-negative integer. Changes to the major
the minor version denote schema changes that are backward compatible version denote non-interoperable changes. Changes to the minor
by ignoring unknown XML elements or other backward-compatible version denote schema changes that are backward compatible by
changes. ignoring unknown XML elements or other backward-compatible changes.
The minor versions of the XML schema MUST be backward compatible, not The minor versions of the XML schema MUST be backward compatible, not
only in terms of the schema but semantically and procedurally as only in terms of the schema but semantically and procedurally as
well. This means that they should define further features and well. This means that they should define further features and
functionality besides those defined in the previous versions, in an functionality besides those defined in the previous versions, in an
incremental way, without impacting the basic rules defined in the incremental way, without impacting the basic rules defined in the
previous version of the schema. In this way, if a MP is able to previous version of the schema. In this way, if an MP is able to
"speak", for example, version 1.5 of the protocol while the MC only "speak", for example, version 1.5 of the protocol while the MC only
understands version 1.4, the MP should have no problem in reverting understands version 1.4, the MP should have no problem in reverting
the dialogue back to version 1.4 without exploiting 1.5 features and the dialogue back to version 1.4 without exploiting 1.5 features and
functionality. Version 1.4 is the one to be spoken and has to appear functionality. Version 1.4 is the one to be spoken and has to appear
in the "v" attribute of the subsequent CLUE messages. In other in the "v" attribute of the subsequent CLUE messages. In other
words, in this example, the MP MUST use version 1.4. That said, and words, in this example, the MP MUST use version 1.4. That said, and
in keeping with the general IETF protocol "robustness principle" in keeping with the general IETF protocol "robustness principle"
stating that an implementation must be conservative in its sending stating that an implementation must be conservative in its sending
behavior and liberal in its receiving behavior [RFC1122], CLUE behavior and liberal in its receiving behavior [RFC1122], CPs MUST
Participants MUST ignore unknown elements or attributes that are not ignore unknown elements or attributes that are not envisioned in the
envisioned in the negotiated protocol version and related extensions. negotiated protocol version and related extensions.
8. Extensions 8. Extensions
Although the standard version of the CLUE protocol XML schema is Although the standard version of the CLUE protocol XML schema is
designed to thoroughly cope with the requirements emerging from the designed to thoroughly cope with the requirements emerging from the
application domain, new needs might arise, and new extensions can application domain, new needs might arise, and new extensions can
then be designed. Extensions specify information and behaviors that then be designed. Extensions specify information and behaviors that
are not described in a certain version of the protocol and specified are not described in a certain version of the protocol and specified
in the related RFC document. Such information and behaviors can be in the related RFC document. Such information and behaviors can be
optionally used in a CLUE dialogue and MUST be negotiated in the CLUE optionally used in a CLUE dialogue and MUST be negotiated in the CLUE
skipping to change at line 1561 skipping to change at line 1558
| | | |
| | | |
|9. configureResponse | |9. configureResponse |
+-------------------->| +-------------------->|
| | | |
| | | |
. . . .
. . . .
. . . .
Two CLUE Participants, CP1 and CP2, have successfully set up the CLUE Two CPs, CP1 and CP2, have successfully set up the CLUE channel
channel according to [RFC8850]. CP1 is the CI, and CP2 is the CR. according to [RFC8850]. CP1 is the CI, and CP2 is the CR.
* The initiation phase starts (negotiation of the CLUE protocol * The initiation phase starts (negotiation of the CLUE protocol
version and extensions). CP1, as the CI, sends to CP2 an version and extensions). CP1, as the CI, sends to CP2 an
'options' message specifying the supported versions and extensions 'options' message specifying the supported versions and extensions
(Section 10.1). CP1 supports (i) version 1.4 with extensions E1, (Section 10.1). CP1 supports (i) version 1.4 with extensions E1,
E2, and E3 and (ii) version 2.7 with extensions E4 and E5. E2, and E3 and (ii) version 2.7 with extensions E4 and E5.
Because of such capabilities, CP1 sends an 'options' message with Because of such capabilities, CP1 sends an 'options' message with
the "v" attribute set to "1.4" and explicitly specifies all the the "v" attribute set to "1.4" and explicitly specifies all the
supported versions and extensions in the corresponding fields of supported versions and extensions in the corresponding fields of
the 'options' message. In the 'options' message, CP1 also the 'options' message. In the 'options' message, CP1 also
specifies that it intends to act as both a MP and a MC. specifies that it intends to act as both an MP and an MC.
* CP2 supports versions 3.0, 2.9, and 1.9 of the CLUE protocol, each * CP2 supports versions 3.0, 2.9, and 1.9 of the CLUE protocol, each
version without any extensions. Version 2.7 is the best common version without any extensions. Version 2.7 is the best common
choice. Given the received 'options' message, CP2 answers with an choice. Given the received 'options' message, CP2 answers with an
'optionsResponse' message in which it specifies only version 2.7 'optionsResponse' message in which it specifies only version 2.7
as the agreed-upon version of the CLUE protocol to be used, as the agreed-upon version of the CLUE protocol to be used,
leaving blank the extensions part of the message to say that no leaving blank the extensions part of the message to say that no
extensions will be used in the CLUE session (Section 10.2). In extensions will be used in the CLUE session (Section 10.2). In
the 'optionsResponse' message, CP2 also specifies that it intends the 'optionsResponse' message, CP2 also specifies that it intends
to act as both a MP and a MC. to act as both an MP and an MC.
After the initiation phase is completed, CP1 and CP2 start their After the initiation phase is completed, CP1 and CP2 start their
activity as the MP and the MC, respectively. For the sake of activity as the MP and the MC, respectively. For the sake of
simplicity, the rest of the call flow focuses only on the dialogue simplicity, the rest of the call flow focuses only on the dialogue
between MP CP1 and MC CP2. between MP CP1 and MC CP2.
* CP1 advertises a telepresence configuration like the one described * CP1 advertises a telepresence configuration like the one described
in [RFC8846], Section 27, where there are (i) three main video in [RFC8846], Section 27, where there are (i) three main video
streams captured by three cameras, with the central camera capable streams captured by three cameras, with the central camera capable
of capturing a zoomed-out view of the overall telepresence room, of capturing a zoomed-out view of the overall telepresence room,
(ii) a multicontent capture of the loudest segment of the room, (ii) a multicontent capture of the loudest segment of the room,
and (iii) one audio capture for the audio of the whole room and (iii) one audio capture for the audio of the whole room
(Section 10.3). (Section 10.3).
* CP2 receives CP1's 'advertisement' message and, after processing * CP2 receives CP1's 'advertisement' message and, after processing
it, sends back to CP1 a 'configure + ack' message in which it it, sends back to CP1 a 'configure+ack' message in which it
declares its interest in the multicontent capture and the audio declares its interest in the multicontent capture and the audio
capture only (Section 10.4). capture only (Section 10.4).
* CP1 answers CP2's 'configure + ack' message with a * CP1 answers CP2's 'configure+ack' message with a
'configureResponse' message that includes a 200 (Success) response 'configureResponse' message that includes a 200 (Success) response
code to accept all of CP2's requests (Section 10.5). code to accept all of CP2's requests (Section 10.5).
* To reflect the changes in its telepresence offer, CP1 issues a new * To reflect the changes in its telepresence offer, CP1 issues a new
'advertisement' message to CP2 (Section 10.6), this time also 'advertisement' message to CP2 (Section 10.6), this time also
adding a composed capture made of a big picture representing the adding a composed capture made of a big picture representing the
current speaker and two picture-in-picture boxes representing the current speaker and two picture-in-picture boxes representing the
previous speakers (see [RFC8846], Section 28 for more details previous speakers (see [RFC8846], Section 28 for more details
regarding the telepresence description). regarding the telepresence description).
skipping to change at line 2060 skipping to change at line 2057
<ns3:fn> <ns3:fn>
<ns3:text>Ciccio</ns3:text> <ns3:text>Ciccio</ns3:text>
</ns3:fn> </ns3:fn>
</personInfo> </personInfo>
<personType>chairman</personType> <personType>chairman</personType>
<personType>timekeeper</personType> <personType>timekeeper</personType>
</person> </person>
</ns2:people> </ns2:people>
</ns2:advertisement> </ns2:advertisement>
10.4. CLUE Message No. 4: 'configure + ack' 10.4. CLUE Message No. 4: 'configure+ack'
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:configure xmlns="urn:ietf:params:xml:ns:clue-info" <ns2:configure xmlns="urn:ietf:params:xml:ns:clue-info"
xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol" xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol"
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0"
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
protocol="CLUE" v="2.7"> protocol="CLUE" v="2.7">
<ns2:clueId>CP2</ns2:clueId> <ns2:clueId>CP2</ns2:clueId>
<ns2:sequenceNr>22</ns2:sequenceNr> <ns2:sequenceNr>22</ns2:sequenceNr>
<ns2:advSequenceNr>11</ns2:advSequenceNr> <ns2:advSequenceNr>11</ns2:advSequenceNr>
skipping to change at line 2660 skipping to change at line 2657
authentication, (ii) protection of all sensitive fields, (iii) mutual authentication, (ii) protection of all sensitive fields, (iii) mutual
authentication between CLUE endpoints, (iv) the presence of authentication between CLUE endpoints, (iv) the presence of
authorization mechanisms, and (v) the presence of native defense authorization mechanisms, and (v) the presence of native defense
mechanisms against malicious activities such as eavesdropping, mechanisms against malicious activities such as eavesdropping,
selective modification, deletion, and replay (and related selective modification, deletion, and replay (and related
combinations thereof). Hence, security of the single components of combinations thereof). Hence, security of the single components of
the CLUE solution cannot be evaluated independently of the integrated the CLUE solution cannot be evaluated independently of the integrated
view of the final architecture. view of the final architecture.
The CLUE protocol is an application-level protocol allowing a Media The CLUE protocol is an application-level protocol allowing a Media
Producer and a Media Consumer to negotiate a variegated set of Producer and an MC to negotiate a variegated set of parameters
parameters associated with the establishment of a telepresence associated with the establishment of a telepresence session. This
session. This unavoidably exposes a CLUE-enabled telepresence system unavoidably exposes a CLUE-enabled telepresence system to a number of
to a number of potential threats, most of which are extensively potential threats, most of which are extensively discussed in the
discussed in the CLUE framework document [RFC8845]. The Security CLUE framework document [RFC8845]. The Security Considerations
Considerations section of [RFC8845] actually discusses issues section of [RFC8845] actually discusses issues associated with the
associated with the setup and management of a telepresence session in setup and management of a telepresence session in both (1) the basic
both (1) the basic case involving two CLUE endpoints acting as the MP case involving two CLUE endpoints acting as the MP and the MC,
and the MC, respectively and (2) the more advanced scenario respectively and (2) the more advanced scenario envisaging the
envisaging the presence of an MCU. presence of an MCU.
The CLUE framework document [RFC8845] also mentions that the The CLUE framework document [RFC8845] also mentions that the
information carried within CLUE protocol messages might contain information carried within CLUE protocol messages might contain
sensitive data, which SHOULD hence be accessed only by authenticated sensitive data, which SHOULD hence be accessed only by authenticated
endpoints. Security issues associated with the CLUE data model endpoints. Security issues associated with the CLUE data model
schema are discussed in [RFC8846]. schema are discussed in [RFC8846].
There is extra information carried by the CLUE protocol that is not There is extra information carried by the CLUE protocol that is not
associated with the CLUE data model schema and that exposes associated with the CLUE data model schema and that exposes
information that might be of concern. This information is primarily information that might be of concern. This information is primarily
exchanged during the negotiation phase via the 'options' and exchanged during the negotiation phase via the 'options' and
'optionsResponse' messages. In the CLUE Participant state machine's 'optionsResponse' messages. In the CP state machine's OPTIONS state,
OPTIONS state, both parties agree on the version and extensions to be both parties agree on the version and extensions to be used in the
used in the subsequent CLUE message exchange phase. A malicious subsequent CLUE message exchange phase. A malicious participant
participant might either (1) try to retrieve a detailed footprint of might either (1) try to retrieve a detailed footprint of a specific
a specific CLUE protocol implementation during this initial setup CLUE protocol implementation during this initial setup phase or
phase or (2) force the communicating party to use a version of the (2) force the communicating party to use a version of the protocol
protocol that is outdated and that they know how to break. Indeed, that is outdated and that they know how to break. Indeed, exposing
exposing all of the supported versions and extensions could all of the supported versions and extensions could conceivably leak
conceivably leak information about the specific implementation of the information about the specific implementation of the protocol. In
protocol. In theory, an implementation could choose not to announce theory, an implementation could choose not to announce all of the
all of the versions it supports if it wants to avoid such leakage, versions it supports if it wants to avoid such leakage, although this
although this would come at the expense of interoperability. With would come at the expense of interoperability. With respect to the
respect to the above considerations, it is noted that the OPTIONS above considerations, it is noted that the OPTIONS state is only
state is only reached after the CLUE data channel has been reached after the CLUE data channel has been successfully set up.
successfully set up. This ensures that only authenticated parties This ensures that only authenticated parties can exchange 'options'
can exchange 'options' messages and related 'optionsResponse' messages and related 'optionsResponse' messages, and hence
messages, and hence drastically reduces the attack surface that is drastically reduces the attack surface that is exposed to malicious
exposed to malicious parties. parties.
The CLUE framework clearly states the requirement to protect CLUE The CLUE framework clearly states the requirement to protect CLUE
protocol messages against threats deriving from the presence of a protocol messages against threats deriving from the presence of a
malicious agent capable of gaining access to the CLUE data channel. malicious agent capable of gaining access to the CLUE data channel.
Such a requirement is met by the CLUE data channel solution described Such a requirement is met by the CLUE data channel solution described
in [RFC8850], which ensures protection from both message recovery and in [RFC8850], which ensures protection from both message recovery and
message tampering. With respect to this last point, any message tampering. With respect to this last point, any
implementation of the CLUE protocol compliant with the CLUE implementation of the CLUE protocol compliant with the CLUE
specification MUST rely on the exchange of messages that flow on top specification MUST rely on the exchange of messages that flow on top
of a reliable and ordered SCTP-over-DTLS transport channel connecting of a reliable and ordered SCTP-over-DTLS transport channel connecting
two CLUE Participants. two CPs.
12. IANA Considerations 12. IANA Considerations
This document registers a new XML namespace, a new XML schema, and This document registers a new XML namespace, a new XML schema, and
the media type for the schema. This document also registers the the media type for the schema. This document also registers the
"CLUE" Application Service tag and the "CLUE" Application Protocol "CLUE" Application Service tag and the "CLUE" Application Protocol
tag and defines registries for the CLUE messages and response codes. tag and defines registries for the CLUE messages and response codes.
12.1. URN Sub-Namespace Registration 12.1. URN Sub-Namespace Registration
skipping to change at line 2772 skipping to change at line 2769
Subject: Registration of media type "application/clue+xml" Subject: Registration of media type "application/clue+xml"
Media type name: application Media type name: application
Subtype name: clue+xml Subtype name: clue+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset. Same as the charset parameter of Optional parameters: charset. Same as the charset parameter of
"application/xml" as specified in [RFC7303], Section 3.2. "application/xml" as specified in [RFC7303], Section 4.2.
Encoding considerations: Same as the encoding considerations of Encoding considerations: Same as the encoding considerations of
"application/xml" as specified in [RFC7303], Section 3.2. "application/xml" as specified in [RFC7303], Section 4.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related to telepresence session control. Some of protocol data related to telepresence session control. Some of
the data could be considered private. This media type does not the data could be considered private. This media type does not
provide any protection; thus, other mechanisms, such as those provide any protection; thus, other mechanisms, such as those
described in Section 11 of this document, are required to protect described in Section 11 of this document, are required to protect
the data. This media type does not contain executable content. the data. This media type does not contain executable content.
Interoperability considerations: None. Interoperability considerations: None.
skipping to change at line 2980 skipping to change at line 2977
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8845] Duckworth, M., Ed., Pepperell, A., and S. Wenger, [RFC8845] Duckworth, M., Ed., Pepperell, A., and S. Wenger,
"Framework for Telepresence Multi-Streams", RFC 8845, "Framework for Telepresence Multi-Streams", RFC 8845,
DOI 10.17487/RFC8845, July 2020, DOI 10.17487/RFC8845, January 2021,
<https://www.rfc-editor.org/info/rfc8845>. <https://www.rfc-editor.org/info/rfc8845>.
[RFC8846] Presta, R. and S P. Romano, "An XML Schema for the [RFC8846] Presta, R. and S P. Romano, "An XML Schema for the
Controlling Multiple Streams for Telepresence (CLUE) Data Controlling Multiple Streams for Telepresence (CLUE) Data
Model", RFC 8846, DOI 10.17487/RFC8846, July 2020, Model", RFC 8846, DOI 10.17487/RFC8846, January 2021,
<https://www.rfc-editor.org/info/rfc8846>. <https://www.rfc-editor.org/info/rfc8846>.
[RFC8848] Hanton, R., Kyzivat, P., Xiao, L., and C. Groves, "Session [RFC8848] Hanton, R., Kyzivat, P., Xiao, L., and C. Groves, "Session
Signaling for Controlling Multiple Streams for Signaling for Controlling Multiple Streams for
Telepresence (CLUE)", RFC 8848, DOI 10.17487/RFC8848, July Telepresence (CLUE)", RFC 8848, DOI 10.17487/RFC8848,
2020, <https://www.rfc-editor.org/info/rfc8848>. January 2021, <https://www.rfc-editor.org/info/rfc8848>.
[RFC8850] Holmberg, C., "Controlling Multiple Streams for [RFC8850] Holmberg, C., "Controlling Multiple Streams for
Telepresence (CLUE) Protocol Data Channel", RFC 8850, Telepresence (CLUE) Protocol Data Channel", RFC 8850,
DOI 10.17487/RFC8850, July 2020, DOI 10.17487/RFC8850, January 2021,
<https://www.rfc-editor.org/info/rfc8850>. <https://www.rfc-editor.org/info/rfc8850>.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126>. <https://www.w3.org/TR/2008/REC-xml-20081126>.
13.2. Informative References 13.2. Informative References
 End of changes. 50 change blocks. 
172 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/