idnits 2.17.1 draft-ietf-clue-protocol-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2018) is 2037 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '1-9' is mentioned on line 1357, but not defined == Missing Reference: '0-9' is mentioned on line 1363, but not defined == Unused Reference: 'RFC7667' is defined on line 2987, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-clue-datachannel-15 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel') == Outdated reference: A later version (-15) exists of draft-ietf-clue-signaling-13 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-signaling (ref. 'I-D.ietf-clue-signaling') -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE Working Group R. Presta 3 Internet-Draft S. P. Romano 4 Intended status: Standards Track University of Napoli 5 Expires: March 25, 2019 September 21, 2018 7 Protocol for Controlling Multiple Streams for Telepresence (CLUE) 8 draft-ietf-clue-protocol-17 10 Abstract 12 The CLUE protocol is an application protocol conceived for the 13 description and negotiation of a telepresence session. The design of 14 the CLUE protocol takes into account the requirements and the 15 framework defined within the IETF CLUE working group. A companion 16 document delves into CLUE signaling details, as well as on the SIP/ 17 SDP session establishment phase. CLUE messages flow over the CLUE 18 data channel, based on reliable and ordered SCTP over DTLS transport. 19 Message details, together with the behavior of CLUE Participants 20 acting as Media Providers and/or Media Consumers, are herein 21 discussed. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 25, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Overview of the CLUE protocol . . . . . . . . . . . . . . . . 4 61 5. Protocol messages . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1. options . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. optionsResponse . . . . . . . . . . . . . . . . . . . . . 11 64 5.3. advertisement . . . . . . . . . . . . . . . . . . . . . . 12 65 5.4. ack . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 5.5. configure . . . . . . . . . . . . . . . . . . . . . . . . 14 67 5.6. configureResponse . . . . . . . . . . . . . . . . . . . . 15 68 5.7. Response codes and reason strings . . . . . . . . . . . . 16 69 6. Protocol state machines . . . . . . . . . . . . . . . . . . . 18 70 6.1. Media Provider's state machine . . . . . . . . . . . . . 21 71 6.2. Media Consumer's state machine . . . . . . . . . . . . . 22 72 7. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 25 73 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25 74 8.1. Extension example . . . . . . . . . . . . . . . . . . . . 27 75 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 29 76 10. Call flow example . . . . . . . . . . . . . . . . . . . . . . 34 77 10.1. CLUE message nr. 1: 'option' . . . . . . . . . . . . . . 37 78 10.2. CLUE message nr. 2: 'optionResponse' . . . . . . . . . . 39 79 10.3. CLUE message nr. 3: 'advertisement' . . . . . . . . . . 39 80 10.4. CLUE message nr. 4: 'configure + ack' . . . . . . . . . 47 81 10.5. CLUE message nr. 5: 'confResponse' . . . . . . . . . . . 47 82 10.6. CLUE message nr. 6: 'advertisement' . . . . . . . . . . 48 83 10.7. CLUE message nr. 7: 'ack' . . . . . . . . . . . . . . . 58 84 10.8. CLUE message nr. 8: 'configure' . . . . . . . . . . . . 58 85 10.9. CLUE message nr. 9: 'confResponse' . . . . . . . . . . . 59 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 60 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 88 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 61 89 12.2. XML Schema registration . . . . . . . . . . . . . . . . 62 90 12.3. MIME Media Type Registration for 'application/clue+xml' 62 91 12.4. CLUE Protocol Registry . . . . . . . . . . . . . . . . . 63 92 12.4.1. CLUE Message Types . . . . . . . . . . . . . . . . . 63 93 12.4.2. CLUE Response Codes . . . . . . . . . . . . . . . . 64 94 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 96 14.1. Normative References . . . . . . . . . . . . . . . . . . 66 97 14.2. Informative References . . . . . . . . . . . . . . . . . 67 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 100 1. Introduction 102 The CLUE protocol is an application protocol used by two CLUE 103 Participants to enhance the experience of a multimedia telepresence 104 session. The main goals of the CLUE protocol are: 106 1. enabling a Media Provider (MP) to properly announce its current 107 telepresence capabilities to a Media Consumer (MC) in terms of 108 available media captures, groups of encodings, simultaneity 109 constraints and other information defined in 110 [I-D.ietf-clue-framework]; 112 2. enabling an MC to request the desired multimedia streams from the 113 offering MP. 115 CLUE-capable endpoints are connected by means of the CLUE data 116 channel, an SCTP over DTLS channel which is opened and established as 117 described in [I-D.ietf-clue-signaling] and 118 [I-D.ietf-clue-datachannel]. CLUE protocol messages flowing over 119 such a channel are detailed in this document, both syntactically and 120 semantically. 122 In Section 4 we provide a general overview of the CLUE protocol. 123 CLUE protocol messages are detailed in Section 5. The CLUE Protocol 124 state machines are introduced in Section 6. Versioning and 125 extensions are discussed in Section 7 and Section 8, respectively. 126 The XML schema defining the CLUE messages is reported in Section 9. 128 2. Terminology 130 This document refers to the same terminology used in 131 [I-D.ietf-clue-framework] and in [RFC7262]. We briefly recall herein 132 some of the main terms used in the document. The definition of "CLUE 133 Participant" herein proposed is not imported from any of the above 134 documents. 136 Capture Encoding: A specific encoding of a Media Capture, to be sent 137 via RTP [RFC3550]. 139 CLUE Participant (CP): An entity able to use the CLUE protocol 140 within a telepresence session. It can be an endpoint or an MCU 141 able to use the CLUE protocol. 143 CLUE-capable device: A device that supports the CLUE data channel 144 [I-D.ietf-clue-datachannel], the CLUE protocol and the principles 145 of CLUE negotiation, and seeks CLUE-enabled calls. 147 Endpoint: A CLUE-capable device which is the logical point of final 148 termination through receiving, decoding and rendering, and/or 149 initiation through capturing, encoding, and sending of media 150 streams. An endpoint consists of one or more physical devices 151 which source and sink media streams, and exactly one [RFC4353] 152 Participant (which, in turn, includes exactly one SIP User Agent). 153 Endpoints can be anything from multiscreen/multicamera rooms to 154 handheld devices. 156 MCU: a CLUE-capable device that connects two or more endpoints 157 together into one single multimedia conference [RFC5117]. An MCU 158 includes an [RFC4353]-like Mixer, without the [RFC4353] 159 requirement to send media to each participant. 161 Media: Any data that, after suitable encoding, can be conveyed over 162 RTP, including audio, video or timed text. 164 Media Capture: a source of Media, such as from one or more Capture 165 Devices or constructed from other Media streams. 167 Media Consumer (MC): A CLUE Participant (i.e., an Endpoint or an 168 MCU) able to receive Capture Encodings. 170 Media Provider (MP): A CLUE Participant (i.e., an Endpoint or an 171 MCU) able to send Capture Encodings. 173 Stream: a Capture Encoding sent from a Media Provider to a Media 174 Consumer via RTP [RFC3550]. 176 3. Conventions 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 4. Overview of the CLUE protocol 186 The CLUE protocol is conceived to enable CLUE telepresence sessions. 187 It is designed in order to address SDP limitations in terms of the 188 description of some information about the multimedia streams that are 189 involved in a real-time multimedia conference. Indeed, by simply 190 using SDP it is not possible to convey information about the features 191 of the flowing multimedia streams that are needed to enable a "being 192 there" rendering experience. Such information is contained in the 193 CLUE framework document [I-D.ietf-clue-framework] and formally 194 defined and described in the CLUE data model document 195 [I-D.ietf-clue-data-model-schema]. The CLUE protocol represents the 196 mechanism for the exchange of telepresence information between CLUE 197 Participants. It mainly provides the messages to enable a Media 198 Provider to advertise its telepresence capabilities and to enable a 199 Media Consumer to select the desired telepresence options. 201 The CLUE protocol, as defined in the following, is a stateful, 202 client-server, XML-based application protocol. CLUE protocol 203 messages flow on a reliable and ordered SCTP over DTLS transport 204 channel connecting two CLUE Participants. Messages carry information 205 taken from the XML-based CLUE data model 206 ([I-D.ietf-clue-data-model-schema]). Three main communication phases 207 can be identified: 209 1. Establishment of the CLUE data channel: in this phase, the CLUE 210 data channel setup takes place. If it completes successfully, 211 the CPs are able to communicate and start the initiation phase. 213 2. Negotiation of the CLUE protocol version and extensions 214 (initiation phase): the CPs connected via the CLUE data channel 215 agree on the version and on the extensions to be used during the 216 telepresence session. Special CLUE messages are used for such a 217 task ('options' and 'optionsResponse'). The version and 218 extensions negotiation can be performed once during the CLUE 219 session and only at this stage. At the end of that basic 220 negotiation, each CP starts its activity as a CLUE MP and/or CLUE 221 MC. 223 3. CLUE telepresence capabilities description and negotiation: in 224 this phase, the MP-MC dialogues take place on the data channel by 225 means of the CLUE protocol messages. 227 As soon as the channel is ready, the CLUE Participants must agree on 228 the protocol version and extensions to be used within the 229 telepresence session. CLUE protocol version numbers are 230 characterized by a major version number (single digit) and a minor 231 version number (single digit), both unsigned integers, separated by a 232 dot. While minor version numbers denote backward compatible changes 233 in the context of a given major version, different major version 234 numbers generally indicate a lack of interoperability between the 235 protocol implementations. In order to correctly establish a CLUE 236 dialogue, the involved CPs MUST have in common a major version number 237 (see Section 7 for further details). The subset of the extensions 238 that are allowed within the CLUE session is also determined in the 239 initiation phase, such subset being the one including only the 240 extensions that are supported by both parties. A mechanism for the 241 negotiation of the CLUE protocol version and extensions is part of 242 the initiation phase. According to such a solution, the CP which is 243 the CLUE Channel Initiator (CI) issues a proper CLUE message 244 ('options') to the CP which is the Channel Receiver (CR) specifying 245 the supported version and extensions. The CR then answers by 246 selecting the subset of the CI extensions that it is able to support 247 and determines the protocol version to be used. 249 After the negotiation phase is completed, CLUE Participants describe 250 and agree on the media flows to be exchanged. In many cases CPs will 251 seek to both transmit and receive media. Hence in a call between two 252 CPs, A and B, there would be two separate dialogs, as follows: 254 1. the one needed to describe and set up the media streams sent from 255 A to B, i.e., the dialogue between A's Media Provider side and 256 B's Media Consumer side 258 2. the one needed to describe and set up the media streams sent from 259 B to A, i.e., the dialogue between B's Media Provider side and 260 A's Media Consumer side 262 CLUE messages for the media session description and negotiation are 263 designed by considering the MP side as the server side of the 264 protocol, since it produces and provides media streams, and the MC 265 side as the client side of the protocol, since it requests and 266 receives media streams. The messages that are exchanged to set up 267 the telepresence media session are described by focusing on a single 268 MP-MC dialogue. 270 The MP first advertises its available media captures and encoding 271 capabilities to the MC, as well as its simultaneity constraints, 272 according to the information model defined in 273 [I-D.ietf-clue-framework]. The CLUE message conveying the MP's 274 multimedia offer is the 'advertisement' message. Such message 275 leverages the XML data model definitions provided in 276 [I-D.ietf-clue-data-model-schema]. 278 The MC selects the desired streams of the MP by using the 'configure' 279 message, which makes reference to the information carried in the 280 previously received 'advertisement'. 282 Besides 'advertisement' and 'configure', other messages have been 283 conceived in order to provide all the needed mechanisms and 284 operations. Such messages are detailed in the following sections. 286 5. Protocol messages 288 CLUE protocol messages are textual, XML-based messages that enable 289 the configuration of the telepresence session. The formal definition 290 of such messages is provided in the XML Schema provided at the end of 291 this document (Section 9). This section includes non-normative 292 excerpts of the schema to aid in describing it. 294 The XML definitions of the CLUE information provided in 295 [I-D.ietf-clue-data-model-schema] are included within some CLUE 296 protocol messages (namely the 'advertisement' and the 'configure' 297 messages), in order to use the concepts defined in 298 [I-D.ietf-clue-framework]. 300 The CLUE protocol messages are the following: 302 o options 304 o optionsResponse 306 o advertisement 308 o ack 310 o configure 312 o configureResponse 314 While the 'options' and 'optionsResponse' messages are exchanged in 315 the initiation phase between the CPs, the other messages are involved 316 in MP-MC dialogues. 318 Each CLUE message inherits a basic structure depicted in the 319 following excerpt (Figure 1): 321 322 323 324 325 326 328 329 331 332 333 334 335 336 338 Figure 1: Structure of a CLUE message 340 The information contained in each CLUE message is: 342 o clueId: an optional XML element containing the identifier (in the 343 form of a generic string) of the CP within the telepresence 344 system; 346 o sequenceNr: an XML element containing the local message sequence 347 number. The sender must increment the sequence numbers by one for 348 each new message sent, the receiver must remember the most recent 349 sequence number received and send back a 402 error if it receives 350 a message with an unexpected sequence number (e.g., sequence 351 number gap, repeated sequence number, sequence number too small). 352 The initial sequence number can be chosen randomly by each party; 354 o protocol: a mandatory attribute set to "CLUE", identifying the 355 procotol the messages refer to; 357 o v: a mandatory attribute carrying the version of the protocol. 358 The content of the "v" attribute is composed by the major version 359 number followed by a dot and then by the minor version number of 360 the CLUE protocol in use. The major number cannot be "0" and, if 361 it is more than one digit, it cannot start with a "0". Allowed 362 values are of this kind are, e.g., "1.3", "2.0", "20.44" etc. 363 This document describes version 1.0. 365 Each CP is responsible for creating and updating up to three 366 independent streams of sequence numbers in messages it sends: (i) one 367 for the messages sent in the initiation phase, (ii) one for the 368 messages sent as MP (if it is acting as a MP), and (iii) one for the 369 messages sent as MC (if it is acting as a MC). 371 In particular, CLUE response messages ('optionsResponse', 'ack', 372 'configureResponse') derive from a base type, inheriting from the 373 clueMessageType, which is defined as follows (Figure 2): 375 376 377 378 379 380 381 382 383 384 386 Figure 2: Structure of CLUE response messages 388 The elements and get populated as 389 detailed in Section 5.7 391 5.1. options 393 The 'options' message is sent by the CLUE Participant which is the 394 Channel Initiator to the CLUE Participant which is the Channel 395 Receiver as soon as the CLUE data channel is ready. Besides the 396 information envisioned in the basic structure, it specifies: 398 o : a mandatory boolean field set to "true" if the CP 399 is able to act as a MP 401 o : a mandatory boolean field set to "true" if the CP 402 is able to act as a MC 404 o : the list of the supported versions 406 o : the list of the supported extensions 408 The XML Schema of such a message is reported below (Figure 3): 410 411 412 413 414 415 416 417 419 421 423 424 425 426 427 429 430 431 432 434 435 436 437 439 440 441 442 444 445 446 447 449 450 451 452 453 454 455 456 457 458 459 Figure 3: Structure of CLUE 'options' message 461 contains the list of the versions that are 462 supported by the CI, each one represented in a child 463 element. The content of each element is a string made by 464 the major version number followed by a dot and then by the minor 465 version number (e.g., 1.3 or 2.4). Exactly one element 466 MUST be provided for each major version supported, containing the 467 maximum minor version number of such a version, since all minor 468 versions are backward compatible. If no is 469 carried within the 'options' message, the CI supports only the 470 version declared in the "v" attribute and all the versions having the 471 same major version number and lower minor version number. For 472 example, if the "v" attribute has a value of "3.4" and there is no 473 tag in the 'options' message, it means the CI 474 supports only major version 3 with all the minor versions comprised 475 between 3.0 and 3.4, with version 3.4 included. If a 476 is provided, at least one tag MUST be 477 included. In this case, the "v" attribute SHOULD be set to the 478 largest minor version of the smallest major version advertised in the 479 list. Indeed, the intention behind the "v" 480 attribute is that some implementation that receives a version number 481 in the "v" field with a major number higher than it understands is 482 supposed to close the connection, since it runs a risk of 483 misinterpreting the contents of messages. The minor version is 484 obviously less useful in this context, since minor versions are 485 defined to be both backwards and forwards compatible, but it is more 486 useful to know the highest minor version supported than some random 487 minor version, as it indicates the full feature set that is 488 supported. The reason why it is less useful is that the value can in 489 any case be parsed out of the list. 491 The element specifies the list of extensions 492 supported by the CI. If there is no in the 493 'options' message, the CI does not support anything other than what 494 is envisioned in the versions it supports. For each extension, an 495 element is provided. An extension is characterized by a 496 name, an XML schema of reference where the extension is defined, and 497 the version of the protocol which the extension refers to. 499 5.2. optionsResponse 501 The 'optionsResponse' (Figure 4) is sent by a CR to a CI as a reply 502 to the 'options' message. The 'optionsResponse' contains a mandatory 503 response code and a reason string indicating the processing result of 504 the 'options' message. If the responseCode is between 200 and 299 505 inclusive, the response MUST also include , 506 , and elements; it MAY 507 include them for any other response code. and 508 elements are associated with the supported roles (in 509 terms of, respectively MP and MC), similarly to what the CI does in 510 the 'options' message. The field indicates the highest 511 commonly supported version number. The content of the 512 element MUST be a string made of the major version number followed by 513 a dot and then by the minor version number (e.g., 1.3 or 2.4). 514 Finally, the commonly supported extensions are copied in the 515 field. 517 518 519 520 521 522 524 526 527 529 531 532 533 534 535 537 Figure 4: Structure of CLUE 'optionsResponse' message 539 Upon reception of the 'optionsResponse' the version to be used is the 540 one provided in the tag of the message. The following CLUE 541 messages MUST use such a version number in the "v" attribute. The 542 allowed extensions in the CLUE dialogue are those indicated in the 543 of the 'optionsResponse' message. 545 5.3. advertisement 547 The 'advertisement' message is used by the MP to advertise the 548 available media captures and related information to the MC. The MP 549 sends an 'advertisement' to the MC as soon as it is ready after the 550 successful completion of the initiation phase, i.e., as soon as the 551 version and the extensions of the CLUE protocol are agreed between 552 the CPs. During a single CLUE session, an MP may send new 553 'advertisement' messages to replace the previous advertisement, if, 554 for instance, its CLUE telepresence media capabilities change mid- 555 call. A new 'advertisement' completely replaces the previous 556 'advertisement'. 558 The 'advertisement' structure is defined in the schema excerpt below 559 (Figure 5). The 'advertisement' contains elements compliant with the 560 CLUE data model that characterize the MP's telepresence offer. 561 Namely, such elements are: the list of the media captures 562 (), of the encoding groups (), of the 563 capture scenes (), of the simultaneous sets 564 (), of the global views (), and of the 565 represented participants (). Each of them is fully described 566 in the CLUE framework document and formally defined in the CLUE data 567 model document. 569 570 571 572 573 574 575 576 577 578 579 581 583 584 586 587 588 589 590 592 Figure 5: Structure of CLUE 'advertisement' message 594 5.4. ack 596 The 'ack' message is sent by a MC to a MP to acknowledge an 597 'advertisement' message. As it can be seen from the message schema 598 provided in the following excerpt (Figure 6), the 'ack' contains a 599 response code and a reason string for describing the processing 600 result of the 'advertisement'. The carries the 601 sequence number of 'advertisement' message the 'ack' refers to. 603 604 605 606 607 608 609 611 612 613 614 615 617 Figure 6: Structure of CLUE 'ack' message 619 5.5. configure 621 The 'configure' message is sent from a MC to a MP to list the 622 advertised captures the MC wants to receive. The MC can send a 623 'configure' after the reception of an 'advertisement' or each time it 624 wants to request other captures that have been previously advertised 625 by the MP. The content of the 'configure' message is shown below 626 (Figure 7). 628 629 630 631 632 633 634 635 637 639 641 642 643 644 645 647 Figure 7: Structure of CLUE 'configure' message 649 The element contains the sequence number of the 650 'advertisement' message the 'configure' refers to. 652 The optional element, when present, contains a success response 653 code, as defined in Section 5.7. It indicates that the 'configure' 654 message also acknowledges with success the referred advertisement 655 ('configure' + 'ack' message), by applying in that way a piggybacking 656 mechanism for simultaneously acknowledging and replying to the 657 'advertisement' message. The element MUST NOT be present if an 658 'ack' message has been already sent back to the MP. 660 The most important content of the 'configure' message is the list of 661 the capture encodings provided in the element (see 662 [I-D.ietf-clue-data-model-schema] for the definition of 663 ). Such an element contains a sequence of capture 664 encodings, representing the streams to be instantiated. 666 5.6. configureResponse 668 The 'configureResponse' message is sent from the MP to the MC to 669 communicate the processing result of requests carried in the 670 previously received 'configure' message. It contains (Figure 8) a 671 response code with a reason string indicating either the success or 672 the failure (along with failure details) of a 'configure' request 673 processing. Following, the field contains the 674 sequence number of the 'configure' message the response refers to. 676 There is no partial execution of commands. As an example, if a MP is 677 able to understand all the selected capture encodings except one, 678 then the whole command fails and nothing is instantiated. 680 681 682 683 684 685 686 688 689 690 691 692 694 Figure 8: Structure of CLUE 'configureResponse' message 696 5.7. Response codes and reason strings 698 Response codes are defined as a sequence of three digits. A well- 699 defined meaning is associated with the first digit. Response codes 700 beginning with "2" are associated with successful responses. 701 Response codes that do not begin with either "2" or "1" indicate an 702 error response, i.e., that an error occurred while processing a CLUE 703 request. In particular, response codes beginning with "3" indicate 704 problems with the XML content of the message ("Bad syntax", "Invalid 705 value", etc.), while response codes beginning with "4" refer to 706 problems related to CLUE protocol semantics ("Invalid sequencing", 707 "Version not supported", etc.). 200, 300 and 400 codes are 708 considered catch-alls. Further response codes can be either defined 709 in future versions of the protocol (by adding them to the related 710 IANA registry), or defined by leveraging the extension mechanism. In 711 both cases, the new response codes MUST be registered with IANA. 712 Such new response codes MUST NOT overwrite the ones here defined and 713 they MUST respect the semantics of the first code digit. 715 This document does not define response codes starting with "1", and 716 such response codes are not allowed to appear in major version 1 of 717 the CLUE protocol. The range from 100 to 199 inclusive is reserved 718 for future major versions of the protocol to define response codes 719 for delayed or incomplete operations if necessary. Response codes 720 starting with "5" through "9" are reserved for future major versions 721 of the protocol to define new classes of response, and are not 722 allowed in major version 1 of the CLUE protocol. Response codes 723 starting with "0" are not allowed. 725 The response codes and strings defined for use with version 1 of the 726 CLUE protocol are listed in Figure 9. The "Description" text 727 contained in the table can be sent in the element of a 728 response message. Implementations can (and are encouraged to) 729 include more specific descriptions of the error condition, if 730 possible. 732 +-----------------+----------------------+--------------------------+ 733 | | | | 734 | Response code | Reason string | Description | 735 | | | | 736 +-----------------+----------------------+--------------------------+ 737 | | | | 738 | 200 | Success | The request has been | 739 | | | successfully processed. | 740 | | | | 741 +-----------------+----------------------+--------------------------+ 742 | | | | 743 | 300 | Low-level request | A generic low-level | 744 | | error. | request error has | 745 | | | occurred. | 746 | | | | 747 +-----------------+----------------------+--------------------------+ 748 | | | | 749 | 301 | Bad syntax | The XML syntax of the | 750 | | | message is not correct. | 751 +-----------------+----------------------+--------------------------+ 752 | | | | 753 | 302 | Invalid value | The message | 754 | | | contains an invalid | 755 | | | parameter value. | 756 +-----------------+----------------------+--------------------------+ 757 | | | | 758 | 303 | Conflicting values | The message | 759 | | | contains values that | 760 | | | cannot be used together.| 761 +-----------------+----------------------+--------------------------+ 762 | | | | 763 | 400 | Semantic errors | Semantic errors in the | 764 | | | received CLUE protocol | 765 | | | message. | 766 | | | | 767 +-----------------+----------------------+--------------------------+ 768 | | | | 769 | 401 | Version not supported| The protocol version | 770 | | | used in the message | 771 | | | is not supported. | 772 | | | | 773 +-----------------+----------------------+--------------------------+ 774 | | | | 775 | 402 | Invalid sequencing | Sequence number gap; | 776 | | | repeated sequence number;| 777 | | | sequence number outdated.| 778 +-----------------+----------------------+--------------------------+ 779 | | | | 780 | 403 | Invalid identifier | The clueId used in | 781 | | | the message is | 782 | | | not valid or unknown. | 783 +-----------------+----------------------+--------------------------+ 784 | | | The sequence number of | 785 | 404 | advertisement | the advertisement the | 786 | | Expired | configure refers to is | 787 | | | out of date. | 788 +-----------------+----------------------+--------------------------+ 789 | | | | 790 | 405 | Subset choice not | The subset choice is not | 791 | | allowed | allowed for the specified| 792 | | | Multiple Content Capture | 793 +-----------------+----------------------+--------------------------+ 795 Figure 9: CLUE response codes 797 6. Protocol state machines 799 The CLUE protocol is an application protocol used between two CPs in 800 order to properly configure a multimedia telepresence session. CLUE 801 protocol messages flow over the CLUE Data Channel, a DTLS/SCTP 802 channel established as depicted in [I-D.ietf-clue-datachannel]. We 803 herein discuss the state machines associated, respectively, with the 804 CLUE Participant (Figure 10), with the MC process (Figure 11) and 805 with the MP process (Figure 12). Endpoints often wish to both send 806 and receive media, i.e., act as both MP and MC. As such there will 807 often be two sets of messages flowing in opposite directions; the 808 state machines of these two flows do not interact with each other. 809 Only the CLUE application logic is considered. The interaction of 810 CLUE protocol and SDP negotiations for the media streams exchanged is 811 treated in [I-D.ietf-clue-signaling]. 813 The main state machines focus on the behavior of the CLUE Participant 814 (CP) acting as a CLUE Channel Initiator/Receiver (CI/CR). 816 The initial state is the IDLE one. When in the IDLE state, the CLUE 817 data channel is not established and no CLUE-controlled media are 818 exchanged between the two considered CLUE-capable devices (if there 819 is an ongoing exchange of media streams, such media streams are not 820 currently CLUE-controlled). 822 When the CLUE data channel set up starts ("start channel"), the CP 823 moves from the IDLE state to the CHANNEL SETUP state. 825 If the CLUE data channel is successfully set up ("channel 826 established"), the CP moves from the CHANNEL SETUP state to the 827 OPTIONS state. Otherwise if "channel error", it moves back to the 828 IDLE state. The same transition happens if the CLUE-enabled 829 telepresence session ends ("session ends"), i.e., when an SDP 830 negotiation for removing the CLUE data channel is performed. 832 When in the OPTIONS state, the CP addresses the initiation phase 833 where both parts agree on the version and on the extensions to be 834 used in the subsequent CLUE messages exchange phase. If the CP is 835 the Channel Initiator (CI), it sends an 'options' message and waits 836 for the 'optionsResponse' message. If the CP is the Channel Receiver 837 (CR), it waits for the 'options' message and, as soon as it arrives, 838 replies with the 'optionsResponse' message. If the negotiation is 839 successfully completed ("OPTIONS phase success"), the CP moves from 840 the OPTIONS state to the ACTIVE state. If the initiation phase fails 841 ("OPTIONS phase failure"), the CP moves from the OPTIONS state to the 842 IDLE state. The initiation phase might fail because of one of the 843 following reasons: 845 1. the CI receives an 'optionsResponse' with an error response code 847 2. the CI does not receive any 'optionsResponse' and a timeout error 848 is raised 850 3. the CR does not receive any 'options' and a timeout error is 851 raised 853 When in the ACTIVE state, the CP starts the envisioned sub-state 854 machines (i.e., the MP state machine and the MC state machine) 855 according to the roles it plays in the telepresence sessions. Such 856 roles have been previously declared in the 'options' and 857 'optionsResponse' messages involved in the initiation phase (see 858 OPTIONS sections Section 5.1 and Section 5.2 for the details). When 859 in the ACTIVE state, the CP delegates the sending and the processing 860 of the CLUE messages to the appropriate MP/MC sub-state machines. If 861 the CP receives a further 'options'/'optionsResponse' message, it 862 MUST ignore the message and stay in the ACTIVE state. 864 +----+ 865 +---------------------->|IDLE|<----------------------------+ 866 | +-+--+ | 867 | | | 868 | | start | 869 | | channel | 870 | v | 871 | channel error/ +--------+ | 872 | session ends | CHANNEL| | 873 +----------------------+ SETUP | | 874 | +--+-----+ | 875 | | | 876 | | channel | 877 | | established | 878 | channel error/ v OPTIONS phase | 879 | session ends +-------+ failure | 880 +-----------------------+OPTIONS+--------------------------+ 881 | +-+-----+ 882 | | 883 | | OPTIONS phase 884 | | success 885 | v 886 | channel error/ +---------+ 887 | session ends | ACTIVE | 888 +----------------------+ | 889 | +----+ +------------------+ 890 | | MP | | send/receive | 891 | +----+ | CLUE messages | 892 | |<-----------------+ 893 | +----+ | 894 | | MC | | 895 | +----+ | 896 | | 897 +---------+ 899 Figure 10: CLUE Participant state machine 901 6.1. Media Provider's state machine 903 As soon as the sub-state machine of the MP (Figure 11) is activated, 904 it is in the ADV state. In the ADV state, the MP prepares the 905 'advertisement' message reflecting its actual telepresence 906 capabilities. 908 After the 'advertisement' has been sent ("advertisement sent"), the 909 MP moves from the ADV state to the WAIT FOR ACK state. If an 'ack' 910 message with a successful response code arrives ("ack received"), the 911 MP moves to the WAIT FOR CONF state. If a NACK arrives (i.e., an 912 'ack' message with an error response code), the MP moves back to the 913 ADV state for preparing a new 'advertisement'. When in the WAIT FOR 914 ACK state, if a 'configure' message with the element set to 915 TRUE arrives ("configure+ack received"), the MP goes directly to the 916 CONF RESPONSE state. 'configure+ack' messages referring to out-of- 917 date (i.e., having a sequence number equal to or less than the 918 highest seen so far) advertisements MUST be ignored, i.e., they do 919 not trigger any state transition. If the telepresence settings of 920 the MP change while in the WAIT FOR ACK state ("changed telepresence 921 settings"), the MP switches from the WAIT FOR ACK state to the ADV 922 state to create a new 'advertisement'. 924 When in the WAIT FOR CONF state, the MP listens to the channel for a 925 'configure' request coming from the MC. When a 'configure' arrives 926 ("configure received"), the MP switches to the CONF RESPONSE state. 927 If the telepresence settings change in the meanwhile ("changed 928 telepresence settings"), the MP moves from the WAIT FOR CONF back to 929 the ADV state to create the new 'advertisement' to be sent to the MC. 931 The MP in the CONF RESPONSE state processes the received 'configure' 932 in order to produce a 'configureResponse' message. If the MP 933 successfully processes the MC's configuration, then it sends a 200 934 'configureResponse' ("success configureResponse sent") and moves to 935 the ESTABLISHED state. If there are errors in the 'configure' 936 processing, then the MP issues a 'configureResponse' carrying an 937 error response code and it goes back to the WAIT FOR CONF state to 938 wait for a new configuration request. Finally, if there are changes 939 in the MP's telepresence settings ("changed telepresence settings"), 940 the MP switches to the ADV state. 942 The MP in the ESTABLISHED state has successfully negotiated the media 943 streams with the MC by means of the CLUE messages. If there are 944 changes in the MP's telepresence settings ("changed telepresence 945 settings"), the MP moves back to the ADV state. In the ESTABLISHED 946 state, the CLUE-controlled media streams of the session are those 947 described in the last successfully processed 'configure' message. 949 Messages not shown for a state do not cause the state to change. 951 +-----+ 952 +------------>| ADV |<-------------------+ 953 | +-+---+ | 954 | advertisement| NACK received | 955 | sent| | 956 | v | 957 changed| +--------+ | 958 telepresence+-------------+WAIT FOR+-----------------+ 959 settings| +----------+ ACK | 960 | |configure +-+------+ 961 | | + ack | 962 | |received |ack received 963 | | v 964 | | +--------+ 965 +-------------+WAIT FOR| 966 | | | CONF | 967 | | +-+------+<-----------------------------+ 968 | | | | 969 | | |configure received | 970 | | v | 971 | +--------->+---------+ error configureResponse sent| 972 +-------------+CONF |-----------------------------+ 973 | +--------->|RESPONSE + 974 | | +---------+ 975 | | | 976 | | |success 977 | | |configureResponse 978 | | |sent 979 | | | 980 | | | 981 | |configure | 982 | |received v 983 | | +-----------+ 984 | +----------+ESTABLISHED| 985 +-------------+-----------+ 987 Figure 11: Media Provider's state machine 989 6.2. Media Consumer's state machine 991 As soon as the sub-state machine of the MC (Figure 12) is activated, 992 it is in the WAIT FOR ADV state. An MC in the WAIT FOR ADV state is 993 waiting for an 'advertisement' coming from the MP. If the 994 'advertisement' arrives ("ADV received"), the MC reaches the ADV 995 PROCESSING state. Otherwise, the MC stays in the WAIT FOR ADV state. 997 In the ADV PROCESSING state, the 'advertisement' is parsed by the MC. 998 If the 'advertisement' is successfully processed, there are two 999 possibilities. In the former case, the MC issues a successful 'ack' 1000 message to the MP ("ACK sent") and moves to the CONF state. This 1001 typically happens when the MC needs some more time to produce the 1002 'configure' message associated with the received 'advertisement'. In 1003 the latter case, the MC is able to immediately prepare and send back 1004 to the MP a 'configure' message. Such a message will have the 1005 field set to "200" ("configure+ack sent") and will allow the MC to 1006 move directly to the WAIT FOR CONF RESPONSE state. 1008 If the ADV processing is unsuccessful (bad syntax, missing XML 1009 elements, etc.), the MC sends a NACK message (i.e., an 'ack' with an 1010 error response code) to the MP and optionally further describes the 1011 problem via a proper reason phrase. In this way ("NACK sent"), the 1012 MC switches back to the WAIT FOR ADV state, waiting for a new 1013 'advertisement'. 1015 When in the CONF state, the MC prepares the 'configure' request to be 1016 issued to the MP on the basis of the previously ack-ed 1017 'advertisement'. When the 'configure' has been sent ("configure 1018 sent"), the MC moves to the WAIT FOR CONF RESPONSE state. If a new 1019 'advertisement' arrives in the meanwhile ("advertisement received"), 1020 the MC goes back to the ADV PROCESSING state. 1022 In the WAIT FOR CONF RESPONSE state, the MC waits for the MP's 1023 response to the issued 'configure' or 'configure+ack'. If a 200 1024 'configureResponse' message is received ("successful 1025 configureResponse received"), it means that the MP and the MC have 1026 successfully agreed on the media streams to be shared. Then, the MC 1027 can move to the ESTABLISHED state. On the other hand, if an error 1028 response is received ("error configureResponse received"), the MC 1029 moves back to the CONF state to prepare a new 'configure' request. 1030 If a new 'advertisement' is received in the WAIT FOR CONF RESPONSE 1031 state, the MC switches to the ADV PROCESSING state. 1033 When the MC is in the ESTABLISHED state, the telepresence session 1034 configuration has been set up at the CLUE application level according 1035 to the MC's preferences. Both the MP and the MC have agreed on (and 1036 are aware of) the CLUE-controlled media streams to be exchanged 1037 within the call. While in the ESTABLISHED state, it might happen 1038 that the MC decides to change something in the call settings. The MC 1039 then issues a new 'configure' ("configure sent") and goes to wait for 1040 the new 'configureResponse' in the WAIT FOR CONF RESPONSE state. On 1041 the other hand, in the ESTABLISHED state, if a new 'advertisement' 1042 arrives from the MP ("advertisement received"), it means that 1043 something has changed on the MP's side. The MC then moves to the ADV 1044 PROCESSING state. 1046 Messages not shown for a state do not cause the state to change. 1048 +----------+ 1049 | WAIT FOR | 1050 | ADV | 1051 +----+-----+<--------+ 1052 | | 1053 advertisement| NACK sent| 1054 received| | 1055 v | 1056 +-----------+--------+ 1057 | ADV + 1058 | PROCESSING|<-----------------------+ 1059 +-+-----+---+ | 1060 | | | 1061 configure+ack | | ack | 1062 sent | | sent | 1063 | v | 1064 | +-----+ | 1065 | |CONF | advertisement received | 1066 +----------------------->| +-------------------------+ 1067 |error | +--+--+ | 1068 |configureResponse | | | 1069 |received | |configure | 1070 | | |sent | 1071 | | | | 1072 | v v advertisement | 1073 +------------------+---------------+ received | 1074 +--------->| WAIT FOR +---------------------+ 1075 | | CONF RESPONSE+ | 1076 | +-------+-------+ | 1077 | | | 1078 | | | 1079 | |successful | 1080 | |configureResponse | 1081 | |received | 1082 |configure v | 1083 |sent +-----------+ advertisement received| 1084 +------------+ESTABLISHED+-----------------------+ 1085 +-----------+ 1087 Figure 12: Media Consumer's state machine 1089 7. Versioning 1091 CLUE protocol messages are XML messages compliant to the CLUE 1092 protocol XML schema [I-D.ietf-clue-data-model-schema]. The version 1093 of the protocol corresponds to the version of the schema. Both 1094 client and server have to test the compliance of the received 1095 messages with the XML schema of the CLUE protocol. If the compliance 1096 is not verified, the message cannot be processed further. 1098 Obviously, client and server cannot communicate if they do not share 1099 exactly the same XML schema. Such a schema is associated with the 1100 CLUE URN "urn:ietf:params:xml:ns:clue-protocol". If all CLUE-enabled 1101 devices use that schema there will be no interoperability problems 1102 due to schema issues. 1104 This document defines XML schema version 1.0. The version usage is 1105 similar in philosophy to XMPP ([RFC6120]). A version number has 1106 major and minor components, each a non-negative integer. Major 1107 version changes denote non-interoperable changes. Minor version 1108 changes denote schema changes that are backward compatible by 1109 ignoring unknown XML elements, or other backward compatible changes. 1111 The minor versions of the XML schema MUST be backward compatible, not 1112 only in terms of schema but also semantically and procedurally as 1113 well. This means that they should define further features and 1114 functionality besides those defined in the previous versions, in an 1115 incremental way, without impacting the basic rules defined in the 1116 previous version of the schema. In this way, if a MP is able to 1117 speak, e.g., version 1.5 of the protocol while the MC only 1118 understands version 1.4, the MP should have no problem in reverting 1119 the dialogue back to version 1.4 without exploiting 1.5 features and 1120 functionality. Version 1.4 is the one to be spoken and has to appear 1121 in the "v" attribute of the subsequent CLUE messages. In other 1122 words, in this example, the MP MUST use version 1.4 and downgrade to 1123 the lower version. This said, and coherently with the general IETF 1124 "protocol robustness principle" stating that "an implementation must 1125 be conservative in its sending behavior, and liberal in its receiving 1126 behavior" [RFC1122], CLUE Participants MUST ignore unknown elements 1127 or attributes that are not envisioned in the negotiated protocol 1128 version and related extensions. 1130 8. Extensions 1132 Although the standard version of the CLUE protocol XML schema is 1133 designed to thoroughly cope with the requirements emerging from the 1134 application domain, new needs might arise and extensions can be 1135 designed. Extensions specify information and behaviors that are not 1136 described in a certain version of the protocol and specified in the 1137 related RFC document. Such information and behaviors can be 1138 optionally used in a CLUE dialogue and MUST be negotiated in the CLUE 1139 initiation phase. They can relate to: 1141 1. new information, to be carried in the existing messages. For 1142 example, more fields may be added within an existing message; 1144 2. new messages. This is the case if there is no proper message for 1145 a certain task, so a brand new CLUE message needs to be defined. 1147 As to the first type of extensions, it is possible to distinguish 1148 between protocol-specific and data model information. Indeed, CLUE 1149 messages are envelopes carrying both: 1151 o (i) XML elements defined within the CLUE protocol XML schema 1152 itself (protocol-specific information) 1154 o (ii) other XML elements compliant to the CLUE data model schema 1155 (data model information) 1157 When new protocol-specific information is needed somewhere in the 1158 protocol messages, it can be added in place of the elements and 1159 elements envisioned by the protocol schema. The 1160 policy currently defined in the protocol schema for handling 1161 and elements is: 1163 o elementFormDefault="qualified" 1165 o attributeFormDefault="unqualified" 1167 The new information must be qualified by namespaces other than 1168 "urn:ietf:params:xml:ns:clue-protocol" (the protocol URN) and 1169 "urn:ietf:params:xml:ns:clue-info" (the data model URN). Elements or 1170 attributes from unknown namespaces MUST be ignored. 1172 The other matter concerns data model information. Data model 1173 information is defined by the XML schema associated with the URN 1174 "urn:ietf:params:xml:ns:clue-info". Also for the XML elements 1175 defined in such a schema there are extensibility issues. Those 1176 issues are overcome by using and placeholders. 1177 New information within data model elements can be added in place of 1178 and schema elements, as long as they are 1179 properly namespace qualified. 1181 On the other hand (second type of extensions), "extra" CLUE protocol 1182 messages, i.e., messages not envisioned in the latest standard 1183 version of the schema, can be needed. In that case, the messages and 1184 the associated behavior should be defined in external documents that 1185 both communication parties must be aware of. 1187 As reported in Figure 13, the values of the fields of the 1188 element (either new information or new messages) take the following 1189 values: 1191 o a name; 1193 o an external XML Schema defining the XML information and/or the XML 1194 messages representing the extension; 1196 o the major standard version of the protocol that the extension 1197 refers to. 1199 1200 1201 1202 1203 1204 1205 1206 1207 1209 Figure 13: The element 1211 The above described element is carried within the 1212 'options' and 'optionsResponse' messages to represent the extensions 1213 supported both by the CI and the CR. 1215 Extensions MUST be defined in a separate XML schema file and MUST be 1216 provided with a companion document describing their semantics and 1217 use. 1219 8.1. Extension example 1221 An example of extension might be a "new" capture attribute (i.e., a 1222 capture attribute which is not envisioned in the current standard 1223 defining the CLUE data model in [I-D.ietf-clue-data-model-schema]) 1224 needed to further describe a video capture. 1226 The CLUE data model document ([I-D.ietf-clue-data-model-schema]) 1227 envisions the possibility of adding this kind of "extra" information 1228 in the description of a video capture by keeping the compatibility 1229 with the CLUE data model schema. This is made possible thanks to the 1230 presence of the element in the XML definition of the video 1231 capture, allowing for the introduction of a new XML field in the XML 1232 description. For the sake of convenience, the XML definition of a 1233 video capture taken from [I-D.ietf-clue-data-model-schema] is 1234 reported in Figure 14 below. 1236 1237 1238 1239 1240 1241 1243 1244 1245 1246 1247 1249 Figure 14: XML definition of a CLUE video capture 1251 According to such a definition, a video capture might have, after the 1252 set of the generic media capture attributes, a set of new attributes 1253 defined elsewhere, i.e., in an XML schema defining an extension. The 1254 XML schema defining the extension might look like the following 1255 (Figure 15): 1257 1258 1265 1271 1272 1273 1274 1275 1276 1277 1278 1280 1282 1283 1285 Figure 15: XML schema defining an extension 1287 By using the extension above, a video capture can be further 1288 described in the advertisement using the element 1289 containing two extra information ( and 1290 ) besides using the attributes envisioned for a 1291 generic media capture. As stated in this document, both participants 1292 must be aware of the extension schema and related semantics to use 1293 such an extension and must negotiate it via the 'options' and 1294 'optionsResponse' mechanism. 1296 9. XML Schema 1298 NOTE TO THE RFC-Editor: Please replace "data-model-schema-18.xsd" 1299 with the right schema location for the CLUE data model schema 1300 document (which is still to be defined at the time of this writing) 1301 in this section prior to publication as an RFC. 1303 In this section, the XML schema defining the CLUE messages is 1304 provided (Figure 16). 1306 1307 1315 1316 1318 1319 1320 1321 1322 1323 1324 1326 1327 1328 1329 1330 1331 1332 1334 1335 1336 1337 1338 1339 1340 1341 1342 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1375 1377 1379 1380 1381 1382 1383 1384 1385 1386 1387 1389 1390 1391 1392 1393 1394 1395 1396 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1420 1422 1423 1425 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1441 1442 1443 1445 1448 1449 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1478 1480 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1495 1496 1497 1498 1499 1500 1502 Figure 16: Schema defining CLUE messages 1504 10. Call flow example 1506 In this section the CLUE protocol messages exchanged in the following 1507 call flow are detailed. 1509 +-----+ +-----+ 1510 | | | | 1511 | CP1 | | CP2 | 1512 | | | | 1513 +--+--+ +--+--+ 1514 | | 1515 | 1.options | 1516 +----------------->| 1517 | | 1518 | | 1519 |2.optionsResponse | 1520 |<-----------------+ 1521 | | 1522 | | 1523 | 3.advertisement | 1524 +----------------->| 1525 | | 1526 | | 1527 |4.configure+ack | 1528 |<-----------------+ 1529 | | 1530 | | 1531 |5.confResponse | 1532 +----------------->| 1533 | | 1534 | | 1535 |6.advertisement | 1536 +----------------->| 1537 | | 1538 | | 1539 | 7.ack | 1540 |<-----------------+ 1541 | | 1542 | | 1543 | 8.configure | 1544 |<-----------------+ 1545 | | 1546 | | 1547 | 9.confResponse | 1548 +----------------->| 1549 | | 1550 | | 1551 . . 1552 . . 1553 . . 1555 Two CLUE Participants, CP1 and CP2, have successfully set up the CLUE 1556 channel according to document [I-D.ietf-clue-datachannel]. CP1 is 1557 the Channel Initiator (CI) and CP2 is the Channel Receiver (CR). 1559 The initiation phase starts (negotiation of the CLUE protocol version 1560 and extensions). CP1, as the CI, sends to CP2 an 'options' message 1561 specifying the supported versions and extensions (Section 10.1). CP1 1562 supports: (i) version 1.4 with extensions E1, E2 and E3, (ii) version 1563 2.7 with extensions E4 and E5. Because of such capabilities, CP1 1564 sends an 'options' message with the 'v' attribute set to 1.4 and 1565 specifies explicitly all the supported versions and extensions in the 1566 corresponding fields of the 'options' message. In the 'options' 1567 message, CP1 specifies also that it intends to act both as a MP and 1568 as a MC. 1570 CP2 supports version 3.0, version 2.9 and version 1.9 of the CLUE 1571 protocol, each version without any extension. Version 2.7 is the 1572 best common choice. Given the received 'options' message, CP2 1573 answers with an 'optionsResponse' message in which it specifies only 1574 version 2.7 as the agreed version of the CLUE protocol to be used, 1575 leaving blank the extensions part of the message to say that no 1576 extension will be used in the CLUE session (Section 10.2). In the 1577 'optionsResponse' message, CP2 specifies also that it intends to act 1578 both as a MP and as a MC. 1580 After the initiation phase is completed, CP1 and CP2 start their 1581 activity as MP and as MC. For the sake of simplicity, the following 1582 call flow focuses only on the dialogue between MP CP1 and MC CP2. 1584 CP1 advertises a telepresence configuration like the one described in 1585 [I-D.ietf-clue-data-model-schema], Sec. Sample XML File, where there 1586 are (i) three main video streams captured by three cameras, the 1587 central one capable of capturing a zoomed-out view of the overall 1588 telepresence room, (ii) a multi-content capture of the loudest 1589 segment of the room, and (iii) one audio capture for the audio of the 1590 whole room (Section 10.3). 1592 CP2 receives CP1's 'advertisement' message and, after processing it, 1593 sends back to CP1 a 'configure + ack' message where it declares to be 1594 interested only in the multi-content capture and in the audio capture 1595 (Section 10.4). 1597 CP1 answers to CP2's 'configure + ack' message with a 1598 'configureResponse' message including a response code '200 - Success' 1599 to accept all CP2's requests (Section 10.5). 1601 To reflect the changes in its telepresence offer, CP1 issues a new 1602 'advertisement' message to CP2 (Section 10.6), this time adding also 1603 a composed capture made by a big picture representing the current 1604 speaker and two picture-in-picture boxes representing the previous 1605 speakers (see more details about the telepresence description in 1606 [I-D.ietf-clue-data-model-schema], Sec. MCC example). 1608 CP2 acknowledges the second 'advertisement' message with an 'ack' 1609 message (Section 10.7). 1611 In a second moment, CP2 changes the requested media streams from CP1 1612 by sending to CP1 a 'configure' message replacing the previously 1613 selected video streams with the new composed media streams advertised 1614 by CP1 (Section 10.8). 1616 Finally, CP1 accept the last requests of CP2 with a 'confResponse' 1617 message (Section 10.9) 1619 10.1. CLUE message nr. 1: 'option' 1620 1621 1628 CP1 1629 51 1630 true 1631 true 1632 1633 1.4 1634 2.7 1635 1636 1637 1638 E1 1639 URL_E1 1640 1.4 1641 1642 1643 E2 1644 URL_E2 1645 1.4 1646 1647 1648 E3 1649 URL_E3 1650 1.4 1651 1652 1653 E4 1654 URL_E4 1655 2.7 1656 1657 1658 E5 1659 URL_E5 1660 2.7 1661 1662 1663 1665 10.2. CLUE message nr. 2: 'optionResponse' 1667 1668 1675 CP2 1676 62 1677 200 1678 Success 1679 true 1680 true 1681 2.7 1682 1684 10.3. CLUE message nr. 3: 'advertisement' 1686 1687 1694 CP1 1695 11 1696 1697 1701 CS1 1702 1703 1704 1705 0.0 1706 0.0 1707 10.0 1708 1709 1710 0.0 1711 1.0 1712 10.0 1713 1714 1715 1716 true 1717 EG1 1718 main audio from the room 1719 1720 1 1721 it 1722 static 1723 room 1724 1725 alice 1726 bob 1727 ciccio 1728 1729 1730 1733 CS1 1734 1735 1736 1737 -2.0 1738 0.0 1739 10.0 1740 1741 1742 1743 1744 -3.0 1745 20.0 1746 9.0 1747 1748 1749 -1.0 1750 20.0 1751 9.0 1752 1753 1754 -3.0 1755 20.0 1756 11.0 1757 1758 1759 -1.0 1760 20.0 1761 11.0 1762 1763 1764 1765 true 1766 EG0 1767 left camera video capture 1768 1769 1 1770 it 1771 static 1772 individual 1773 1774 ciccio 1775 1776 1777 1780 CS1 1781 1782 1783 1784 0.0 1785 0.0 1786 10.0 1787 1788 1789 1790 1791 -1.0 1792 20.0 1793 9.0 1794 1795 1796 1.0 1797 20.0 1798 9.0 1799 1800 1801 -1.0 1802 20.0 1803 11.0 1804 1805 1806 1.0 1807 20.0 1808 11.0 1809 1810 1811 1812 true 1813 EG0 1814 central camera video capture 1815 1816 1 1817 it 1818 static 1819 individual 1820 1821 alice 1822 1823 1824 1827 CS1 1828 1829 1830 1831 2.0 1832 0.0 1833 10.0 1834 1835 1836 1837 1838 1.0 1839 20.0 1840 9.0 1841 1842 1843 3.0 1844 20.0 1845 9.0 1846 1847 1848 1.0 1849 20.0 1850 11.0 1851 1852 1853 3.0 1854 20.0 1855 11.0 1856 1857 1858 1859 true 1860 EG0 1861 right camera video capture 1862 1863 1 1864 it 1865 static 1866 individual 1867 1868 bob 1869 1870 1871 1874 CS1 1875 1876 1877 1878 -3.0 1879 20.0 1880 9.0 1881 1882 1883 3.0 1884 20.0 1885 9.0 1886 1887 1888 -3.0 1889 20.0 1890 11.0 1891 1892 1893 3.0 1894 20.0 1895 11.0 1896 1897 1898 1899 1900 SE1 1901 1902 SoundLevel:0 1903 EG0 1904 loudest room segment 1905 2 1906 it 1907 static 1908 individual 1909 1910 1913 CS1 1914 1915 1916 1917 0.0 1918 0.0 1919 10.0 1920 1921 1922 1923 1924 -3.0 1925 20.0 1926 7.0 1927 1928 1929 3.0 1930 20.0 1931 7.0 1932 1933 1934 -3.0 1935 20.0 1936 13.0 1937 1938 1939 3.0 1940 20.0 1941 13.0 1942 1943 1944 1945 true 1946 EG0 1947 zoomed out view of all people in the 1948 room 1949 2 1950 it 1951 static 1952 room 1953 1954 alice 1955 bob 1956 ciccio 1957 1958 1959 1960 1961 1962 600000 1963 1964 ENC1 1965 ENC2 1966 ENC3 1967 1968 1969 1970 300000 1971 1972 ENC4 1973 ENC5 1974 1975 1976 1977 1978 1979 1980 1981 1982 VC0 1983 VC1 1984 VC2 1985 1986 1987 1988 1989 VC3 1990 1991 1992 1993 1994 VC4 1995 1996 1997 1998 1999 AC0 2000 2001 2002 2003 2004 2005 2006 2007 VC3 2008 SE1 2009 2010 2011 VC0 2012 VC2 2013 VC4 2014 2015 2016 2017 2018 2019 2020 Bob 2021 2022 2023 minute taker 2024 2025 2026 2027 2028 Alice 2029 2030 2031 presenter 2032 2033 2034 2035 2036 Ciccio 2037 2038 2039 chairman 2040 timekeeper 2041 2042 2043 2044 10.4. CLUE message nr. 4: 'configure + ack' 2046 2047 2054 CP2 2055 22 2056 11 2057 200 2058 2059 2060 AC0 2061 ENC4 2062 2063 2064 VC3 2065 ENC1 2066 2067 SE1 2068 2069 2070 2071 2073 10.5. CLUE message nr. 5: 'confResponse' 2074 2075 2082 CP1 2083 12 2084 200 2085 Success 2086 22 2087 2089 10.6. CLUE message nr. 6: 'advertisement' 2091 2092 2099 CP1 2100 13 2101 2102 2105 CS1 2106 2107 2108 2109 0.0 2110 0.0 2111 10.0 2112 2113 2114 0.0 2115 1.0 2116 10.0 2117 2118 2119 2120 true 2121 EG1 2122 main audio from the room 2123 2124 1 2125 it 2126 static 2127 room 2128 2129 alice 2130 bob 2131 ciccio 2132 2133 2134 2137 CS1 2138 2139 2140 2141 0.5 2142 1.0 2143 0.5 2144 2145 2146 0.5 2147 0.0 2148 0.5 2149 2150 2151 2152 true 2153 EG0 2154 left camera video capture 2155 2156 1 2157 it 2158 static 2159 individual 2160 2161 ciccio 2162 2163 2164 2167 CS1 2168 2169 2170 2171 0.0 2172 0.0 2173 10.0 2174 2175 2176 2177 2178 -1.0 2179 20.0 2180 9.0 2181 2182 2183 1.0 2184 20.0 2185 9.0 2186 2187 2188 -1.0 2189 20.0 2190 11.0 2191 2192 2193 1.0 2194 20.0 2195 11.0 2196 2197 2198 2199 true 2200 EG0 2201 central camera video capture 2202 2203 1 2204 it 2205 static 2206 individual 2207 2208 alice 2209 2210 2211 2214 CS1 2215 2216 2217 2218 2.0 2219 0.0 2220 10.0 2221 2222 2223 2224 2225 1.0 2226 20.0 2227 9.0 2228 2229 2230 3.0 2231 20.0 2232 9.0 2233 2234 2235 1.0 2236 20.0 2237 11.0 2238 2239 2240 3.0 2241 20.0 2242 11.0 2243 2244 2245 2246 true 2247 EG0 2248 right camera video capture 2249 2250 1 2251 it 2252 static 2253 individual 2254 2255 bob 2256 2257 2258 2261 CS1 2262 2263 2264 2265 -3.0 2266 20.0 2267 9.0 2268 2269 2270 3.0 2271 20.0 2272 9.0 2273 2274 2275 -3.0 2276 20.0 2277 11.0 2278 2279 2280 3.0 2281 20.0 2282 11.0 2283 2284 2285 2286 2287 SE1 2288 2289 SoundLevel:0 2290 EG0 2291 loudest room segment 2292 2 2293 it 2294 static 2295 individual 2296 2297 2300 CS1 2301 2302 2303 2304 0.0 2305 0.0 2306 10.0 2307 2308 2309 2310 2311 -3.0 2313 20.0 2314 7.0 2315 2316 2317 3.0 2318 20.0 2319 7.0 2320 2321 2322 -3.0 2323 20.0 2324 13.0 2325 2326 2327 3.0 2328 20.0 2329 13.0 2330 2331 2332 2333 true 2334 EG0 2335 2336 zoomed out view of all people in the room 2337 2338 2 2339 it 2340 static 2341 room 2342 2343 alice 2344 bob 2345 ciccio 2346 2347 2348 2351 CS1 2352 2353 2354 2355 -3.0 2356 20.0 2357 9.0 2358 2359 2360 3.0 2361 20.0 2362 9.0 2363 2364 2365 -3.0 2366 20.0 2367 11.0 2368 2369 2370 3.0 2371 20.0 2372 11.0 2373 2374 2375 2376 2377 SE1 2378 2379 SoundLevel:1 2380 penultimate loudest room segment 2381 2382 it 2383 static 2384 individual 2385 2386 2389 CS1 2390 2391 2392 2393 -3.0 2394 20.0 2395 9.0 2396 2397 2398 3.0 2399 20.0 2400 9.0 2401 2402 2403 -3.0 2404 20.0 2405 11.0 2406 2407 2408 3.0 2410 20.0 2411 11.0 2412 2413 2414 2415 2416 SE1 2417 2418 SoundLevel:2 2419 last but two loudest room segment 2420 2421 it 2422 static 2423 individual 2424 2425 2428 CS1 2429 2430 2431 2432 -3.0 2433 20.0 2434 9.0 2435 2436 2437 3.0 2438 20.0 2439 9.0 2440 2441 2442 -3.0 2443 20.0 2444 11.0 2445 2446 2447 3.0 2448 20.0 2449 11.0 2450 2451 2452 2453 2454 VC3 2455 VC5 2456 VC6 2457 2458 3 2459 EG0 2460 big picture of the current speaker + 2461 pips about previous speakers 2462 3 2463 it 2464 static 2465 individual 2466 2467 2468 2469 2470 600000 2471 2472 ENC1 2473 ENC2 2474 ENC3 2475 2476 2477 2478 300000 2479 2480 ENC4 2481 ENC5 2482 2483 2484 2485 2486 2487 2488 2489 participants' individual 2490 videos 2491 2492 VC0 2493 VC1 2494 VC2 2495 2496 2497 2498 loudest segment of the 2499 room 2500 2501 VC3 2502 2503 2504 2505 loudest segment of the 2506 room + pips 2507 2508 VC7 2509 2510 2511 2512 room audio 2513 2514 AC0 2515 2516 2517 2518 room video 2519 2520 VC4 2521 2522 2523 2524 2525 2526 2527 2528 VC3 2529 VC7 2530 SE1 2531 2532 2533 VC0 2534 VC2 2535 VC4 2536 2537 2538 2539 2540 2541 2542 Bob 2543 2544 2545 minute taker 2546 2547 2548 2549 2550 Alice 2551 2552 2553 presenter 2555 2556 2557 2558 2559 Ciccio 2560 2561 2562 chairman 2563 timekeeper 2564 2565 2566 2568 10.7. CLUE message nr. 7: 'ack' 2570 2571 2578 CP2 2579 23 2580 200 2581 Success 2582 13 2583 2585 10.8. CLUE message nr. 8: 'configure' 2586 2587 2594 CP2 2595 24 2596 13 2597 2598 2599 AC0 2600 ENC4 2601 2602 2603 VC7 2604 ENC1 2605 2606 SE5 2607 2608 2609 2610 2612 10.9. CLUE message nr. 9: 'confResponse' 2614 2615 2622 CP1 2623 14 2624 200 2625 Success 2626 24 2627 2629 11. Security Considerations 2631 As a general consideration, we remark that the CLUE framework (and 2632 related protocol) has been conceived at the outset by embracing the 2633 security-by-design paradigm. This entails that a number of 2634 requirements have been identified and properly standardized as 2635 mandatory within the entire set of documents associated with the CLUE 2636 architecture. Requirements include: (i) the use of cryptography and 2637 authentication; (ii) protection of all sensitive fields; (iii) mutual 2638 authentication between CLUE endpoints; (iv) the presence of 2639 authorization mechanisms; (v) the presence of native defence 2640 mechanisms against malicious activities such as eavesdropping, 2641 selective modification, deletion, replay (and related combinations 2642 thereof). Hence, security of the single components of the CLUE 2643 solution cannot be evaluated independently of the integrated view of 2644 the final architecture. 2646 The CLUE protocol is an application-level protocol allowing a Media 2647 Producer and a Media Consumer to negotiate a variegated set of 2648 parameters associated with the establishment of a telepresence 2649 session. This unavoidably exposes a CLUE-enabled telepresence system 2650 to a number of potential threats, most of which are extensively 2651 discussed in the framework document [I-D.ietf-clue-framework]. The 2652 security considerations section of the mentioned document actually 2653 discusses issues associated with the setup and management of a 2654 telepresence session both in the basic case involving two CLUE 2655 endpoints acting, respectively, as MP and MC, and in the more 2656 advanced scenario envisaging the presence of an MCU. 2658 The framework document also mentions that the information carried 2659 within CLUE protocol messages might contain sensitive data, which 2660 SHOULD hence be accessed only by authenticated endpoints. Security 2661 issues associated with the CLUE data model schema are discussed in 2662 [I-D.ietf-clue-data-model-schema]. 2664 There is extra information carried by the CLUE protocol which is not 2665 associated with the CLUE data model schema and which exposes 2666 information that might be of concern. This information is primarily 2667 exchanged during the negotiation phase via the 'options' and 2668 'optionsResponse' messages. In the CLUE Participant state machine 2669 OPTIONS state, both parties agree on the version and on the 2670 extensions to be used in the subsequent CLUE messages exchange phase. 2671 A malicious participant might either try to retrieve a detailed 2672 footprint of a specific CLUE protocol implementation during this 2673 initial setup phase, or force the communicating party to use a non- 2674 up-to-date version of the protocol which they know how to break. 2675 Indeed, exposing all of the supported versions and extensions could 2676 conceivably leak information about the specific implementation of the 2677 protocol. In theory an implementation could choose not to announce 2678 all of the versions it supports if it wants to avoid such leakage, 2679 though at the expenses of interoperability. With respect to the 2680 above considerations, it is noted that the OPTIONS state is only 2681 reached after the CLUE data channel has been successfully set up. 2682 This ensures that only authenticated parties can exchange 'options' 2683 and related 'optionsResponse' messages and hence drastically reduces 2684 the attack surface which is exposed to malicious parties. 2686 The CLUE framework clearly states the requirement to protect CLUE 2687 protocol messages against threats deriving from the presence of a 2688 malicious agent capable to gain access to the CLUE data channel. 2689 Such a requirement is met by the CLUE data channel solution described 2690 in [I-D.ietf-clue-datachannel], which ensures protection from both 2691 message recovery and message tampering. With respect to this last 2692 point, any implementation of the CLUE protocol compliant with the 2693 CLUE specification MUST rely on the exchange of messages which flow 2694 on top of a reliable and ordered SCTP over DTLS transport channel 2695 connecting two CLUE Participants. 2697 12. IANA Considerations 2699 This document registers a new XML namespace, a new XML schema and the 2700 MIME type for the schema. This document also registers the "CLUE" 2701 Application Service tag and the "CLUE" Application Protocol tag and 2702 defines registries for the CLUE messages and response codes. 2704 12.1. URN Sub-Namespace Registration 2706 This section registers a new XML namespace, 2707 ""urn:ietf:params:xml:ns:clue-protocol"". 2709 URI: urn:ietf:params:xml:ns:clue-protocol 2711 Registrant Contact: IESG (iesg@ietf.org). 2713 XML: 2715 BEGIN 2716 2717 2719 2720 2721 CLUE Messages 2722 2723 2724

Namespace for CLUE Messages

2725

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

2726 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2727 with the RFC number for this specification.]] 2728

See 2729 RFCXXXX.

2730 2731 2732 END 2734 12.2. XML Schema registration 2736 This section registers an XML schema per the guidelines in [RFC3688]. 2738 URI: urn:ietf:params:xml:schema:clue-protocol 2740 Registrant Contact: IESG (iesg@ietf.org). 2742 Schema: The XML for this schema can be found as the entirety of 2743 Section 9 of this document. 2745 12.3. MIME Media Type Registration for 'application/clue+xml' 2747 This section registers the ""application/clue+xml"" MIME type. 2749 To: ietf-types@iana.org 2751 Subject: Registration of MIME media type application/clue+xml 2753 MIME media type name: application 2755 MIME subtype name: clue+xml 2757 Required parameters: (none) 2759 Optional parameters: charset 2760 Same as the charset parameter of "application/xml" as specified in 2761 [RFC7303], Section 3.2. 2763 Encoding considerations: Same as the encoding considerations of 2764 "application/xml" as specified in [RFC7303], Section 3.2. 2766 Security considerations: This content type is designed to carry 2767 protocol data related to telepresence session control. Some of the 2768 data could be considered private. This media type does not provide 2769 any protection and thus other mechanisms such as those described in 2770 Section Security are required to protect the data. This media type 2771 does not contain executable content. 2773 Interoperability considerations: None. 2775 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 2776 replace XXXX with the RFC number for this specification.]] 2778 Applications that use this media type: CLUE participants. 2780 Additional Information: Magic Number(s): (none), 2781 File extension(s): .xml, 2782 Macintosh File Type Code(s): TEXT. 2784 Person & email address to contact for further information: Simon 2785 Pietro Romano (spromano@unina.it). 2787 Intended usage: LIMITED USE 2789 Author/Change controller: The IETF 2791 Other information: This media type is a specialization of 2792 application/xml [RFC7303], and many of the considerations described 2793 there also apply to application/clue+xml. 2795 12.4. CLUE Protocol Registry 2797 The document requests that the IANA creates new registries for CLUE 2798 messages and response codes. 2800 12.4.1. CLUE Message Types 2802 The following summarizes the registry for CLUE messages: 2804 Related Registry: CLUE Message Types Registry 2806 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX 2807 with the RFC number for this specification.]] 2808 Registration/Assignment Procedures: Following the policies outlined 2809 in [RFC8126], the IANA policy for assigning new values for the CLUE 2810 message types for the CLUE protocol is Specification Required. 2812 Registrant Contact: IESG (iesg@ietf.org). 2814 The initial Message table is populated using the CLUE messages 2815 described in Section 5 and defined in the XML schema in Section 9. 2817 +-------------------+-----------------------------------+-----------+ 2818 | Message | Description | Reference | 2819 +-------------------+-----------------------------------+-----------+ 2820 | options | Sent by the CI to the CR in the | RFCXXXX | 2821 | | initiation phase to specify the | | 2822 | | roles played by the CI, the | | 2823 | | supported versions and the | | 2824 | | supported extensions. | | 2825 | optionsResponse | Sent by the CI to the CR in reply | RFCXXXX | 2826 | | to an 'options' message to | | 2827 | | finally estabilsh the version and | | 2828 | | the extensions to be used in the | | 2829 | | following CLUE messages exchange. | | 2830 | advertisement | Sent by the MP to the MC to | RFCXXXX | 2831 | | specify the telepresence | | 2832 | | capabilities of the MP expressed | | 2833 | | according to the CLUE framework. | | 2834 | ack | Sent by the MC to the MP to | RFCXXXX | 2835 | | acknowledge the reception of an | | 2836 | | 'advertisement' message. | | 2837 | configure | Sent by the MC to the MP to | RFCXXXX | 2838 | | specify the desired media | | 2839 | | captures among those specified in | | 2840 | | the 'advertisement'. | | 2841 | configureResponse | Sent by the MP to the MC in reply | RFCXXXX | 2842 | | to a CONFIGURE message to | | 2843 | | communicate if the configuration | | 2844 | | request has been successfully | | 2845 | | processed or not. | | 2846 +-------------------+-----------------------------------+-----------+ 2848 IANA-CLUE 2850 12.4.2. CLUE Response Codes 2852 The following summarizes the requested registry for CLUE response 2853 codes: 2855 Related Registry: CLUE Response Code Registry 2856 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX 2857 with the RFC number for this specification.]] 2859 Registration/Assignment Procedures: Following the policies outlined 2860 in [RFC8126], the IANA policy for assigning new values for the 2861 Response codes for CLUE shall be Specification Required. 2863 Registrant Contact: IESG (iesg@ietf.org). 2865 The initial Response-code table is populated using the Response codes 2866 defined in Section 5.7 as follows: 2868 +--------+---------------+------------------------------+-----------+ 2869 | Number | Default | Description | Reference | 2870 | | Response | | | 2871 | | String | | | 2872 +--------+---------------+------------------------------+-----------+ 2873 | 200 | Success | The request has been | RFCXXXX | 2874 | | | successfully processed. | | 2875 | 300 | Low-level | A generic low-level request | RFCXXXX | 2876 | | request | error has occurred. | | 2877 | | error. | | | 2878 | 301 | Bad syntax | The XML syntax of the | RFCXXXX | 2879 | | | message is not correct. | | 2880 | 302 | Invalid value | The message contains an | RFCXXXX | 2881 | | | invalid parameter value. | | 2882 | 303 | Conficting | The message contains values | RFCXXXX | 2883 | | values | that cannot be used | | 2884 | | | together. | | 2885 | 400 | Semantic | Semantic errors in the | RFCXXXX | 2886 | | errors | received CLUE protocol | | 2887 | | | message. | | 2888 | 401 | Version not | The protocol version used in | RFCXXXX | 2889 | | supported | the message is not | | 2890 | | | supported. | | 2891 | 402 | Invalid | Sequence number gap; | RFCXXXX | 2892 | | sequencing | repeated sequence number; | | 2893 | | | sequence number outdated. | | 2894 | 403 | Invalid | The clueId used in the | RFCXXXX | 2895 | | identifier | message is not valid or | | 2896 | | | unknown. | | 2897 | 404 | advertisement | The sequence number of the | RFCXXXX | 2898 | | Expired | advertisement the configure | | 2899 | | | refers to is out of date. | | 2900 | 405 | Subset choice | The subset choice is not | RFCXXXX | 2901 | | not allowed | allowed for the specified | | 2902 | | | Multiple Content Capture. | | 2903 +--------+---------------+------------------------------+-----------+ 2905 13. Acknowledgments 2907 The authors thank all the CLUErs for their precious feedbacks and 2908 support, in particular Paul Kyzivat, Christian Groves and Scarlett 2909 Liuyan. 2911 14. References 2913 14.1. Normative References 2915 [I-D.ietf-clue-data-model-schema] 2916 Presta, R. and S. Romano, "An XML Schema for the CLUE data 2917 model", draft-ietf-clue-data-model-schema-17 (work in 2918 progress), August 2016. 2920 [I-D.ietf-clue-datachannel] 2921 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 2922 clue-datachannel-15 (work in progress), August 2018. 2924 [I-D.ietf-clue-framework] 2925 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 2926 for Telepresence Multi-Streams", draft-ietf-clue- 2927 framework-25 (work in progress), January 2016. 2929 [I-D.ietf-clue-signaling] 2930 Hansen, R., Kyzivat, P., Xiao, L., and C. Groves, "Session 2931 Signaling for Controlling Multiple Streams for 2932 Telepresence (CLUE)", draft-ietf-clue-signaling-13 (work 2933 in progress), November 2017. 2935 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2936 Requirement Levels", BCP 14, RFC 2119, 2937 DOI 10.17487/RFC2119, March 1997, 2938 . 2940 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2941 Jacobson, "RTP: A Transport Protocol for Real-Time 2942 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2943 July 2003, . 2945 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2946 DOI 10.17487/RFC3688, January 2004, 2947 . 2949 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 2950 DOI 10.17487/RFC7303, July 2014, 2951 . 2953 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2954 Writing an IANA Considerations Section in RFCs", BCP 26, 2955 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2956 . 2958 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2959 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2960 May 2017, . 2962 14.2. Informative References 2964 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2965 Communication Layers", STD 3, RFC 1122, 2966 DOI 10.17487/RFC1122, October 1989, 2967 . 2969 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 2970 Session Initiation Protocol (SIP)", RFC 4353, 2971 DOI 10.17487/RFC4353, February 2006, 2972 . 2974 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 2975 DOI 10.17487/RFC5117, January 2008, 2976 . 2978 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 2979 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 2980 March 2011, . 2982 [RFC7262] Romanow, A., Botzko, S., and M. Barnes, "Requirements for 2983 Telepresence Multistreams", RFC 7262, 2984 DOI 10.17487/RFC7262, June 2014, 2985 . 2987 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 2988 DOI 10.17487/RFC7667, November 2015, 2989 . 2991 Authors' Addresses 2993 Roberta Presta 2994 University of Napoli 2995 Via Claudio 21 2996 Napoli 80125 2997 Italy 2999 EMail: roberta.presta@unina.it 3000 Simon Pietro Romano 3001 University of Napoli 3002 Via Claudio 21 3003 Napoli 80125 3004 Italy 3006 EMail: spromano@unina.it