idnits 2.17.1 draft-ietf-clue-protocol-15.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 (April 11, 2018) is 2204 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 1348, but not defined == Missing Reference: '0-9' is mentioned on line 1354, but not defined == Unused Reference: 'RFC7667' is defined on line 2709, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-clue-datachannel-14 ** 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 normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 3 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: October 13, 2018 April 11, 2018 7 Protocol for Controlling Multiple Streams for Telepresence (CLUE) 8 draft-ietf-clue-protocol-15 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 October 13, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . 24 73 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25 74 8.1. Extension example . . . . . . . . . . . . . . . . . . . . 27 75 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 29 76 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 77 10.1. Simple 'advertisement' . . . . . . . . . . . . . . . . . 34 78 10.2. 'advertisement' with Multiple Content Captures . . . . . 42 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 81 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 53 82 12.2. XML Schema registration . . . . . . . . . . . . . . . . 54 83 12.3. MIME Media Type Registration for 'application/clue+xml' 54 84 12.4. CLUE Protocol Registry . . . . . . . . . . . . . . . . . 55 85 12.4.1. CLUE Message Types . . . . . . . . . . . . . . . . . 55 86 12.4.2. CLUE Response Codes . . . . . . . . . . . . . . . . 56 87 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 58 90 14.2. Informative References . . . . . . . . . . . . . . . . . 59 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 93 1. Introduction 95 The CLUE protocol is an application protocol used by two CLUE 96 Participants to enhance the experience of a multimedia telepresence 97 session. The main goals of the CLUE protocol are: 99 1. enabling a Media Provider (MP) to properly announce its current 100 telepresence capabilities to a Media Consumer (MC) in terms of 101 available media captures, groups of encodings, simultaneity 102 constraints and other information defined in 103 [I-D.ietf-clue-framework]; 105 2. enabling an MC to request the desired multimedia streams from the 106 offering MP. 108 CLUE-capable endpoints are connected by means of the CLUE data 109 channel, an SCTP over DTLS channel which is opened and established as 110 described in [I-D.ietf-clue-signaling] and 111 [I-D.ietf-clue-datachannel]. CLUE protocol messages flowing over 112 such a channel are detailed in this document, both syntactically and 113 semantically. 115 In Section 4 we provide a general overview of the CLUE protocol. 116 CLUE protocol messages are detailed in Section 5. The CLUE Protocol 117 state machines are introduced in Section 6. Versioning and 118 extensions are discussed in Section 7 and Section 8, respectively. 119 The XML schema defining the CLUE messages is reported in Section 9. 121 2. Terminology 123 This document refers to the same terminology used in 124 [I-D.ietf-clue-framework] and in [RFC7262]. We briefly recall herein 125 some of the main terms used in the document. The definition of "CLUE 126 Participant" herein proposed is not imported from any of the above 127 documents. 129 Capture Encoding: A specific encoding of a Media Capture, to be sent 130 via RTP [RFC3550]. 132 CLUE Participant (CP): An entity able to use the CLUE protocol 133 within a telepresence session. It can be an endpoint or an MCU 134 able to use the CLUE protocol. 136 CLUE-capable device: A device that supports the CLUE data channel 137 [I-D.ietf-clue-datachannel], the CLUE protocol and the principles 138 of CLUE negotiation, and seeks CLUE-enabled calls. 140 Endpoint: A CLUE-capable device which is the logical point of final 141 termination through receiving, decoding and rendering, and/or 142 initiation through capturing, encoding, and sending of media 143 streams. An endpoint consists of one or more physical devices 144 which source and sink media streams, and exactly one [RFC4353] 145 Participant (which, in turn, includes exactly one SIP User Agent). 146 Endpoints can be anything from multiscreen/multicamera rooms to 147 handheld devices. 149 MCU: a CLUE-capable device that connects two or more endpoints 150 together into one single multimedia conference [RFC5117]. An MCU 151 includes an [RFC4353]-like Mixer, without the [RFC4353] 152 requirement to send media to each participant. 154 Media: Any data that, after suitable encoding, can be conveyed over 155 RTP, including audio, video or timed text. 157 Media Capture: a source of Media, such as from one or more Capture 158 Devices or constructed from other Media streams. 160 Media Consumer (MC): A CLUE Participant (i.e., an Endpoint or an 161 MCU) able to receive Capture Encodings. 163 Media Provider (MP): A CLUE Participant (i.e., an Endpoint or an 164 MCU) able to send Capture Encodings. 166 Stream: a Capture Encoding sent from a Media Provider to a Media 167 Consumer via RTP [RFC3550]. 169 3. Conventions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 4. Overview of the CLUE protocol 179 The CLUE protocol is conceived to enable CLUE telepresence sessions. 180 It is designed in order to address SDP limitations in terms of the 181 description of some information about the multimedia streams that are 182 involved in a real-time multimedia conference. Indeed, by simply 183 using SDP it is not possible to convey information about the features 184 of the flowing multimedia streams that are needed to enable a "being 185 there" rendering experience. Such information is contained in the 186 CLUE framework document [I-D.ietf-clue-framework] and formally 187 defined and described in the CLUE data model document 189 [I-D.ietf-clue-data-model-schema]. The CLUE protocol represents the 190 mechanism for the exchange of telepresence information between CLUE 191 Participants. It mainly provides the messages to enable a Media 192 Provider to advertise its telepresence capabilities and to enable a 193 Media Consumer to select the desired telepresence options. 195 The CLUE protocol, as defined in the following, is a stateful, 196 client-server, XML-based application protocol. CLUE protocol 197 messages flow on a reliable and ordered SCTP over DTLS transport 198 channel connecting two CLUE Participants. Messages carry information 199 taken from the XML-based CLUE data model 200 ([I-D.ietf-clue-data-model-schema]). Three main communication phases 201 can be identified: 203 1. Establishment of the CLUE data channel: in this phase, the CLUE 204 data channel setup takes place. If it completes successfully, 205 the CPs are able to communicate and start the initiation phase. 207 2. Negotiation of the CLUE protocol version and extensions 208 (initiation phase): the CPs connected via the CLUE data channel 209 agree on the version and on the extensions to be used during the 210 telepresence session. Special CLUE messages are used for such a 211 task ('options' and 'optionsResponse'). The version and 212 extensions negotiation can be performed once during the CLUE 213 session and only at this stage. At the end of that basic 214 negotiation, each CP starts its activity as a CLUE MP and/or CLUE 215 MC. 217 3. CLUE telepresence capabilities description and negotiation: in 218 this phase, the MP-MC dialogues take place on the data channel by 219 means of the CLUE protocol messages. 221 As soon as the channel is ready, the CLUE Participants must agree on 222 the protocol version and extensions to be used within the 223 telepresence session. CLUE protocol version numbers are 224 characterized by a major version number (single digit) and a minor 225 version number (single digit), both unsigned integers, separated by a 226 dot. While minor version numbers denote backward compatible changes 227 in the context of a given major version, different major version 228 numbers generally indicate a lack of interoperability between the 229 protocol implementations. In order to correctly establish a CLUE 230 dialogue, the involved CPs MUST have in common a major version number 231 (see Section 7 for further details). The subset of the extensions 232 that are allowed within the CLUE session is also determined in the 233 initiation phase, such subset being the one including only the 234 extensions that are supported by both parties. A mechanism for the 235 negotiation of the CLUE protocol version and extensions is part of 236 the initial phase. According to such a solution, the CP which is the 237 CLUE Channel initiator (CI) issues a proper CLUE message ('options') 238 to the CP which is the Channel Receiver (CR) specifying the supported 239 version and extensions. The CR then answers by selecting the subset 240 of the CI extensions that it is able to support and determines the 241 protocol version to be used. 243 After the negotiation phase is completed, CLUE Participants describe 244 and agree on the media flows to be exchanged. In many cases CPs will 245 seek to both transmit and receive media. Hence in a call between two 246 CPs, A and B, there would be two separate dialogs, as follows: 248 1. the one needed to describe and set up the media streams sent from 249 A to B, i.e., the dialogue between A's Media Provider side and 250 B's Media Consumer side 252 2. the one needed to describe and set up the media streams sent from 253 B to A, i.e., the dialogue between B's Media Provider side and 254 A's Media Consumer side 256 CLUE messages for the media session description and negotiation are 257 designed by considering the MP side as the server side of the 258 protocol, since it produces and provides media streams, and the MC 259 side as the client side of the protocol, since it requests and 260 receives media streams. The messages that are exchanged to set up 261 the telepresence media session are described by focusing on a single 262 MP-MC dialogue. 264 The MP first advertises its available media captures and encoding 265 capabilities to the MC, as well as its simultaneity constraints, 266 according to the information model defined in 267 [I-D.ietf-clue-framework]. The CLUE message conveying the MP's 268 multimedia offer is the 'advertisement' message. Such message 269 leverages the XML data model definitions provided in 270 [I-D.ietf-clue-data-model-schema]. 272 The MC selects the desired streams of the MP by using the 'configure' 273 message, which makes reference to the information carried in the 274 previously received 'advertisement'. 276 Besides 'advertisement' and 'configure', other messages have been 277 conceived in order to provide all the needed mechanisms and 278 operations. Such messages are detailed in the following sections. 280 5. Protocol messages 282 CLUE protocol messages are textual, XML-based messages that enable 283 the configuration of the telepresence session. The formal definition 284 of such messages is provided in the XML Schema provided at the end of 285 this document (Section 9). This section includes non-normative 286 excerpts of the schema to aid in describing it. 288 The XML definitions of the CLUE information provided in 289 [I-D.ietf-clue-data-model-schema] are included within some CLUE 290 protocol messages (namely the 'advertisement' and the 'configure' 291 messages), in order to use the concepts defined in 292 [I-D.ietf-clue-framework]. 294 The CLUE protocol messages are the following: 296 o options 298 o optionsResponse 300 o advertisement 302 o ack 304 o configure 306 o configureResponse 308 While the 'options' and 'optionsResponse' messages are exchanged in 309 the initiation phase between the CPs, the other messages are involved 310 in MP-MC dialogues. 312 Each CLUE message inherits a basic structure depicted in the 313 following excerpt (Figure 1): 315 316 317 318 319 320 322 323 325 326 327 328 329 330 332 Figure 1: Structure of a CLUE message 334 The information contained in each CLUE message is: 336 o clueId: an optional XML element containing the identifier (in the 337 form of a generic string) of the CP within the telepresence 338 system; 340 o sequenceNr: an XML element containing the local message sequence 341 number. The sender must increment the sequence numbers by one for 342 each new message sent, the receiver must remember the most recent 343 sequence number received and send back a 402 error if it receives 344 a message with an unexpected sequence number (e.g., sequence 345 number gap, repeated sequence number, sequence number too small). 346 The initial sequence number can be chosen randomly by each party; 348 o protocol: a mandatory attribute set to "CLUE", identifying the 349 procotol the messages refer to; 351 o v: a mandatory attribute carrying the version of the protocol. 352 The content of the "v" attribute is composed by the major version 353 number followed by a dot and then by the minor version number of 354 the CLUE protocol in use. The major number cannot be "0" and, if 355 it is more than one digit, it cannot start with a "0". Allowed 356 values are of this kind are, e.g., "1.3", "2.0", "20.44" etc. 357 This document describes version 1.0. 359 Each CP is responsible for creating and updating up to three 360 independent streams of sequence numbers in messages it sends: (i) one 361 for the messages sent in the initiation phase, (ii) one for the 362 messages sent as MP (if it is acting as a MP), and (iii) one for the 363 messages sent as MC (if it is acting as a MC). 365 5.1. options 367 The 'options' message is sent by the CLUE Participant which is the 368 Channel Initiator to the CLUE Participant which is the Channel 369 Receiver as soon as the CLUE data channel is ready. Besides the 370 information envisioned in the basic structure, it specifies: 372 o : a mandatory boolean field set to "true" if the CP 373 is able to act as a MP 375 o : a mandatory boolean field set to "true" if the CP 376 is able to act as a MC 378 o : the list of the supported versions 380 o : the list of the supported extensions 382 The XML Schema of such a message is reported below (Figure 2): 384 385 386 387 388 389 390 391 393 395 397 398 399 400 401 403 404 405 406 408 410 411 412 414 415 416 417 419 420 421 422 424 425 426 427 428 429 430 431 432 433 435 Figure 2: Structure of CLUE 'options' message 437 contains the list of the versions that are 438 supported by the CI, each one represented in a child 439 element. The content of each element is a string made by 440 the major version number followed by a dot and then by the minor 441 version number (e.g., 1.3 or 2.4). Exactly one element 442 MUST be provided for each major version supported, containing the 443 maximum minor version number of such a version, since all minor 444 versions are backward compatible. If no is 445 carried within the 'options' message, the CI supports only the 446 version declared in the "v" attribute and all the versions having the 447 same major version number and lower minor version number. For 448 example, if the "v" attribute has a value of "3.4" and there is no 449 tag in the 'options' message, it means the CI 450 supports only major version 3 with all the minor versions comprised 451 between 3.0 and 3.4, with version 3.4 included. If a 452 is provided, at least one tag MUST be 453 included. In this case, the "v" attribute SHOULD be set to he 454 largest minor version of the smallest major version advertised in the 455 list. Indeed, the intention behind the "v" 456 attribute is that some implementation that receives a version number 457 in the "v" field with a major number higher than it understands is 458 supposed to close the connection, since it runs a risk of 459 misinterpreting the contents of messages. The minor version is 460 obviously less useful in this context, since minor versions are 461 defined to be both backwards and forwards compatible, but it is more 462 useful to know the highest minor version supported than some random 463 minor version, as it indicates the full feature set that is 464 supported. The reason why it is less useful is that the value can in 465 any case be parsed out of the list. 467 The element specifies the list of extensions 468 supported by the CI. If there is no in the 469 'options' message, the CI does not support anything other than what 470 is envisioned in the versions it supports. For each extension, an 471 element is provided. An extension is characterized by a 472 name, an XML schema of reference where the extension is defined, and 473 the version of the protocol which the extension refers to. 475 5.2. optionsResponse 477 CLUE response messages ('optionsResponse', 'ack', 478 'configureResponse') derive from a base type, which is defined as 479 follows (Figure 3): 481 482 483 484 485 486 487 488 489 490 492 Figure 3: Structure of CLUE response messages 494 The elements and get populated as 495 detailed in Section 5.7 497 The 'optionsResponse' (Figure 4) is sent by a CR to a CI as a reply 498 to the 'options' message. The 'optionsResponse' contains a mandatory 499 response code and a reason string indicating the processing result of 500 the 'options' message. If the responseCode is between 200 and 299 501 inclusive, the response MUST also include , 502 , and elements; it MAY 503 include them for any other response code. and 504 elements are associated with the supported roles (in 505 terms of, respectively MP and MC), similarly to what the CI does in 506 the 'options' message. The field indicates the highest 507 commonly supported version number. The content of the 508 element MUST be a string made of the major version number followed by 509 a dot and then by the minor version number (e.g., 1.3 or 2.4). 510 Finally, the commonly supported extensions are copied in the 511 field. 513 514 515 516 517 518 520 522 523 525 527 528 529 530 531 533 Figure 4: Structure of CLUE 'optionsResponse' message 535 Upon reception of the 'optionsResponse' the version to be used is 536 provided in the tag of the message. The following CLUE 537 messages MUST use such a version number in the "v" attribute. The 538 allowed extensions in the CLUE dialogue are those indicated in the 539 of the 'optionsResponse' message. 541 5.3. advertisement 543 The 'advertisement' message is used by the MP to advertise the 544 available media captures and related information to the MC. The MP 545 sends an 'advertisement' to the MC as soon as it is ready after the 546 successful completion of the initiation phase, i.e., as soon as the 547 version and the extensions of the CLUE protocol are agreed between 548 the CPs. During a single CLUE session, an MP may send new 549 'advertisement' messages to replace the previous advertisement, if, 550 for instance, its CLUE telepresence media capabilities change mid- 551 call. A new 'advertisement' completely replaces the previous 552 'advertisement'. 554 The 'advertisement' structure is defined in the schema excerpt below 555 (Figure 5). The 'advertisement' contains elements compliant with the 556 CLUE data model that characterize the MP's telepresence offer. 557 Namely, such elements are: the list of the media captures 558 (), of the encoding groups (), of the 559 capture scenes (), of the simultaneous sets 560 (), of the global views (), and of the 561 represented participants (). Each of them is fully described 562 in the CLUE framework document and formally defined in the CLUE data 563 model document. 565 566 567 568 569 570 571 572 573 574 575 577 579 580 582 583 584 585 586 588 Figure 5: Structure of CLUE 'advertisement' message 590 5.4. ack 592 The 'ack' message is sent by a MC to a MP to acknowledge an 593 'advertisement' message. As it can be seen from the message schema 594 provided in the following excerpt (Figure 6), the 'ack' contains a 595 response code and a reason string for describing the processing 596 result of the 'advertisement'. The carries the 597 sequence number of 'advertisement' message the 'ack' refers to. 599 600 601 602 603 604 605 607 608 609 610 611 613 Figure 6: Structure of CLUE 'ack' message 615 5.5. configure 617 The 'configure' message is sent from a MC to a MP to list the 618 advertised captures the MC wants to receive. The MC can send a 619 'configure' after the reception of an 'advertisement' or each time it 620 wants to request other captures that have been previously advertised 621 by the MP. The content of the 'configure' message is shown below 622 (Figure 7). 624 625 626 627 628 629 630 631 633 635 637 638 639 640 641 643 Figure 7: Structure of CLUE 'configure' message 645 The element contains the sequence number of the 646 'advertisement' message the 'configure' refers to. 648 The optional element, when present, contains a success response 649 code, as defined in Section 5.7. It indicates that the 'configure' 650 message also acknowledges with success the referred advertisement 651 ('configure' + 'ack' message), by applying in that way a piggybacking 652 mechanism for simultaneously acknowledging and replying to the 653 'advertisement' message. The element MUST NOT be present if an 654 'ack' message has been already sent back to the MP. 656 The most important content of the 'configure' message is the list of 657 the capture encodings provided in the element (see 658 [I-D.ietf-clue-data-model-schema] for the definition of 659 ). Such an element contains a sequence of capture 660 encodings, representing the streams to be instantiated. 662 5.6. configureResponse 664 The 'configureResponse' message is sent from the MP to the MC to 665 communicate the processing result of requests carried in the 666 previously received 'configure' message. It contains (Figure 8) a 667 response code with a reason string indicating either the success or 668 the failure (along with failure details) of a 'configure' request 669 processing. Following, the field contains the 670 sequence number of the 'configure' message the response refers to. 672 There is no partial execution of commands. As an example, if a MP is 673 able to understand all the selected capture encodings except one, 674 then the whole command fails and nothing is instantiated. 676 677 678 679 680 681 682 684 685 686 687 688 690 Figure 8: Structure of CLUE 'configureResponse' message 692 5.7. Response codes and reason strings 694 Response codes are defined as a sequence of three digits. A well- 695 defined meaning is associated with the first digit. Response codes 696 beginning with "2" are associated with successful responses. 697 Response codes that do not begin with either "2" or "1" indicate an 698 error response, i.e., that an error occurred while processing a CLUE 699 request. In particular, response codes beginning with "3" indicate 700 problems with the XML content of the message ("Bad syntax", "Invalid 701 value", etc.), while response codes beginning with "4" refer to 702 problems related to CLUE protocol semantics ("Invalid sequencing", 703 "Version not supported", etc.). 200, 300 and 400 codes are 704 considered catch-alls. Further response codes can be either defined 705 in future versions of the protocol (by adding them to the related 706 IANA registry), or defined by leveraging the extension mechanism. In 707 both cases, the new response codes MUST be registered with IANA. 708 Such new response codes MUST NOT overwrite the ones here defined and 709 they MUST respect the semantics of the first code digit. 711 This document does not define response codes starting with "1", and 712 such response codes are not allowed to appear in major version 1 of 713 the CLUE protocol. The range from 100 to 199 inclusive is reserved 714 for future major versions of the protocol to define response codes 715 for delayed or incomplete operations if necessary. Response codes 716 starting with "5" through "9" are reserved for future major versions 717 of the protocol to define new classes of response, and are not 718 allowed in major version 1 of the CLUE protocol. Response codes 719 starting with "0" are not allowed. 721 The response codes and strings defined for use with version 1 of the 722 CLUE protocol are listed in Figure 9. The "Description" text 723 contained in the table can be sent in the element of a 724 response message. Implementations can (and are encouraged to) 725 include more specific descriptions of the error condition, if 726 possible. 728 +-----------------+----------------------+--------------------------+ 729 | | | | 730 | Response code | Reason string | Description | 731 | | | | 732 +-----------------+----------------------+--------------------------+ 733 | | | | 734 | 200 | Success | The request has been | 735 | | | successfully processed. | 736 | | | | 737 +-----------------+----------------------+--------------------------+ 738 | | | | 739 | 300 | Low-level request | A generic low-level | 740 | | error. | request error has | 741 | | | occurred. | 742 | | | | 743 +-----------------+----------------------+--------------------------+ 744 | | | | 745 | 301 | Bad syntax | The XML syntax of the | 746 | | | message is not correct. | 747 +-----------------+----------------------+--------------------------+ 748 | | | | 749 | 302 | Invalid value | The message | 750 | | | contains an invalid | 751 | | | parameter value. | 752 +-----------------+----------------------+--------------------------+ 753 | | | | 754 | 303 | Conflicting values | The message | 755 | | | contains values that | 756 | | | cannot be used together.| 757 +-----------------+----------------------+--------------------------+ 758 | | | | 759 | 400 | Semantic errors | Semantic errors in the | 760 | | | received CLUE protocol | 761 | | | message. | 762 | | | | 763 +-----------------+----------------------+--------------------------+ 764 | | | | 765 | 401 | Version not supported| The protocol version | 766 | | | used in the message | 767 | | | is not supported. | 768 | | | | 769 +-----------------+----------------------+--------------------------+ 770 | | | | 771 | 402 | Invalid sequencing | Sequence number gap; | 772 | | | repeated sequence number;| 773 | | | sequence number outdated.| 774 +-----------------+----------------------+--------------------------+ 775 | | | | 776 | 403 | Invalid identifier | The clueId used in | 777 | | | the message is | 778 | | | not valid or unknown. | 779 +-----------------+----------------------+--------------------------+ 780 | | | The sequence number of | 781 | 404 | advertisement | the advertisement the | 782 | | Expired | configure refers to is | 783 | | | out of date. | 784 +-----------------+----------------------+--------------------------+ 785 | | | | 786 | 405 | Subset choice not | The subset choice is not | 787 | | allowed | allowed for the specified| 788 | | | Multiple Content Capture | 789 +-----------------+----------------------+--------------------------+ 791 Figure 9: CLUE response codes 793 6. Protocol state machines 795 The CLUE protocol is an application protocol used between two CPs in 796 order to properly configure a multimedia telepresence session. CLUE 797 protocol messages flow over the CLUE Data Channel, a DTLS/SCTP 798 channel established as depicted in [I-D.ietf-clue-datachannel]. We 799 herein discuss the state machines associated, respectively, with the 800 CLUE Participant (Figure 10), with the MC process (Figure 11) and 801 with the MP process (Figure 12). Endpoints often wish to both send 802 and receive media, i.e., act as both MP and MC. As such there will 803 often be two sets of messages flowing in opposite directions; the 804 state machines of these two flows do not interact with each other. 805 Only the CLUE application logic is considered. The interaction of 806 CLUE protocol and SDP negotiations for the media streams exchanged is 807 treated in [I-D.ietf-clue-signaling]. 809 The main state machines focus on the behavior of the CLUE Participant 810 (CP) acting as a CLUE channel initiator/receiver (CI/CR). 812 The initial state is the IDLE one. When in the IDLE state, the CLUE 813 data channel is not established and no CLUE-controlled media are 814 exchanged between the two considered CLUE-capable devices (if there 815 is an ongoing exchange of media streams, such media streams are not 816 currently CLUE-controlled). 818 When the CLUE data channel set up starts ("start channel"), the CP 819 moves from the IDLE state to the CHANNEL SETUP state. 821 If the CLUE data channel is successfully set up ("channel 822 established"), the CP moves from the CHANNEL SETUP state to the 823 OPTIONS state. Otherwise if "channel error", it moves back to the 824 IDLE state. The same transition happens if the CLUE-enabled 825 telepresence session ends ("session ends"), i.e., when an SDP 826 negotiation for removing the CLUE data channel is performed. 828 When in the OPTIONS state, the CP addresses the initiation phase 829 where both parts agree on the version and on the extensions to be 830 used in the subsequent CLUE messages exchange phase. If the CP is 831 the Channel Initiator (CI), it sends an 'options' message and waits 832 for the 'optionsResponse' message. If the CP is the Channel Receiver 833 (CR), it waits for the 'options' message and, as soon as it arrives, 834 replies with the 'optionsResponse' message. If the negotiation is 835 successfully completed ("OPTIONS phase success"), the CP moves from 836 the OPTIONS state to the ACTIVE state. If the initiation phase fails 837 ("OPTIONS phase failure"), the CP moves from the OPTIONS state to the 838 IDLE state. The initiation phase might fail because of one of the 839 following reasons: 841 1. the CI receives an 'optionsResponse' with an error response code 843 2. the CI does not receive any 'optionsResponse' and a timeout error 844 is raised 846 3. the CR does not receive any 'options' and a timeout error is 847 raised 849 When in the ACTIVE state, the CP starts the envisioned sub-state 850 machines (i.e., the MP state machine and the MC state machine) 851 according to the roles it plays in the telepresence sessions. Such 852 roles have been previously declared in the 'options' and 853 'optionsResponse' messages involved in the initiation phase (see 854 OPTIONS sections Section 5.1 and Section 5.2 for the details). When 855 in the ACTIVE state, the CP delegates the sending and the processing 856 of the CLUE messages to the appropriate MP/MC sub-state machines. If 857 the CP receives a further 'options'/'optionsResponse' message, it 858 MUST ignore the message and stay in the ACTIVE state. 860 +----+ 861 +---------------------->|IDLE|<----------------------------+ 862 | +-+--+ | 863 | | | 864 | | start | 865 | | channel | 866 | v | 867 | channel error/ +--------+ | 868 | session ends | CHANNEL| | 869 +----------------------+ SETUP | | 870 | +--+-----+ | 871 | | | 872 | | channel | 873 | | established | 874 | channel error/ v OPTIONS phase | 875 | session ends +-------+ failure | 876 +-----------------------+OPTIONS+--------------------------+ 877 | +-+-----+ 878 | | 879 | | OPTIONS phase 880 | | success 881 | v 882 | channel error/ +---------+ 883 | session ends | ACTIVE | 884 +----------------------+ | 885 | +----+ +------------------+ 886 | | MP | | send/receive | 887 | +----+ | CLUE messages | 888 | |<-----------------+ 889 | +----+ | 890 | | MC | | 891 | +----+ | 892 | | 893 +---------+ 895 Figure 10: CLUE Participant state machine 897 6.1. Media Provider's state machine 899 As soon as the sub-state machine of the MP (Figure 11) is activated, 900 it is in the ADV state. In the ADV state, the MP prepares the 901 'advertisement' message reflecting its actual telepresence 902 capabilities. 904 After the 'advertisement' has been sent ("advertisement sent"), the 905 MP moves from the ADV state to the WAIT FOR ACK state. If an 'ack' 906 message with a successful response code arrives ("ack received"), the 907 MP moves to the WAIT FOR CONF state. If a NACK arrives (i.e., an 908 'ack' message with an error response code), the MP moves back to the 909 ADV state for preparing a new 'advertisement'. When in the WAIT FOR 910 ACK state, if a 'configure' message with the element set to 911 TRUE arrives ("configure+ack received"), the MP goes directly to the 912 CONF RESPONSE state. 'configure+ack' messages referring to out-of- 913 date (i.e., having a sequence number equal to or less than the 914 highest seen so far) advertisements MUST be ignored, i.e., they do 915 not trigger any state transition. If the telepresence settings of 916 the MP change while in the WAIT FOR ACK state ("changed telepresence 917 settings"), the MP switches from the WAIT FOR ACK state to the ADV 918 state to create a new 'advertisement'. 920 When in the WAIT FOR CONF state, the MP listens to the channel for a 921 'configure' request coming from the MC. When a 'configure' arrives 922 ("configure received"), the MP switches to the CONF RESPONSE state. 923 If the telepresence settings change in the meanwhile ("changed 924 telepresence settings"), the MP moves from the WAIT FOR CONF back to 925 the ADV state to create the new 'advertisement' to be sent to the MC. 927 The MP in the CONF RESPONSE state processes the received 'configure' 928 in order to produce a 'configureResponse' message. If the MP 929 successfully processes the MC's configuration, then it sends a 200 930 'configureResponse' ("success configureResponse sent") and moves to 931 the ESTABLISHED state. If there are errors in the 'configure' 932 processing, then the MP issues a 'configureResponse' carrying an 933 error response code and it goes back to the WAIT FOR CONF state to 934 wait for a new configuration request. Finally, if there are changes 935 in the MP's telepresence settings ("changed telepresence settings"), 936 the MP switches to the ADV state. 938 The MP in the ESTABLISHED state has successfully negotiated the media 939 streams with the MC by means of the CLUE messages. If there are 940 changes in the MP's telepresence settings ("changed telepresence 941 settings"), the MP moves back to the ADV state. In the ESTABLISHED 942 state, the CLUE-controlled media streams of the session are those 943 described in the last successfully processed 'configure' message. 945 +-----+ 946 +------------>| ADV |<-------------------+ 947 | +-+---+ | 948 | advertisement| NACK received | 949 | sent| | 950 | v | 951 changed| +--------+ | 952 telepresence+-------------+WAIT FOR+-----------------+ 953 settings| +----------+ ACK | 954 | |configure +-+------+ 955 | | + ack | 956 | |received |ack received 957 | | v 958 | | +--------+ 959 +-------------+WAIT FOR| 960 | | | CONF | 961 | | +-+------+<-----------------------------+ 962 | | | | 963 | | |configure received | 964 | | v | 965 | +--------->+---------+ error configureResponse sent| 966 +-------------+CONF |-----------------------------+ 967 | +--------->|RESPONSE + 968 | | +---------+ 969 | | | 970 | | |success 971 | | |configureResponse 972 | | |sent 973 | | | 974 | | | 975 | |configure | 976 | |received v 977 | | +-----------+ 978 | +----------+ESTABLISHED| 979 +-------------+-----------+ 981 Figure 11: Media Provider's state machine 983 6.2. Media Consumer's state machine 985 As soon as the sub-state machine of the MC (Figure 12) is activated, 986 it is in the WAIT FOR ADV state. An MC in the WAIT FOR ADV state is 987 waiting for an 'advertisement' coming from the MP. If the 988 'advertisement' arrives ("ADV received"), the MC reaches the ADV 989 PROCESSING state. Otherwise, the MC stays in the WAIT FOR ADV state. 991 In the ADV PROCESSING state, the 'advertisement' is parsed by the MC. 992 If the 'advertisement' is successfully processed, there are two 993 possibilities. In the former case, the MC issues a successful 'ack' 994 message to the MP ("ACK sent") and moves to the CONF state. This 995 typically happens when the MC needs some more time to produce the 996 'configure' message associated with the received 'advertisement'. In 997 the latter case, the MC is able to immediately prepare and send back 998 to the MP a 'configure' message. Such a message will have the 999 field set to "200" ("configure+ack sent") and will allow the MC to 1000 move directly to the WAIT FOR CONF RESPONSE state. 1002 If the ADV processing is unsuccessful (bad syntax, missing XML 1003 elements, etc.), the MC sends a NACK message (i.e., an 'ack' with an 1004 error response code) to the MP and optionally further describes the 1005 problem via a proper reason phrase. In this way ("NACK sent"), the 1006 MC switches back to the WAIT FOR ADV state, waiting for a new 1007 'advertisement'. 1009 When in the CONF state, the MC prepares the 'configure' request to be 1010 issued to the MP on the basis of the previously ack-ed 1011 'advertisement'. When the 'configure' has been sent ("configure 1012 sent"), the MC moves to the WAIT FOR CONF RESPONSE state. If a new 1013 'advertisement' arrives in the meanwhile ("advertisement received"), 1014 the MC goes back to the ADV PROCESSING state. 1016 In the WAIT FOR CONF RESPONSE state, the MC waits for the MP's 1017 response to the issued 'configure' or 'configure+ack'. If a 200 1018 'configureResponse' message is received ("successful 1019 configureResponse received"), it means that the MP and the MC have 1020 successfully agreed on the media streams to be shared. Then, the MC 1021 can move to the ESTABLISHED state. On the other hand, if an error 1022 response is received ("error configureResponse received"), the MC 1023 moves back to the CONF state to prepare a new 'configure' request. 1024 If a new 'advertisement' is received in the WAIT FOR CONF RESPONSE 1025 state, the MC switches to the ADV PROCESSING state. 1027 When the MC is in the ESTABLISHED state, the telepresence session 1028 configuration has been set up at the CLUE application level according 1029 to the MC's preferences. Both the MP and the MC have agreed on (and 1030 are aware of) the CLUE-controlled media streams to be exchanged 1031 within the call. While in the ESTABLISHED state, it might happen 1032 that the MC decides to change something in the call settings. The MC 1033 then issues a new 'configure' ("configure sent") and goes to wait for 1034 the new 'configureResponse' in the WAIT FOR CONF RESPONSE state. On 1035 the other hand, in the ESTABLISHED state, if a new 'advertisement' 1036 arrives from the MP ("advertisement received"), it means that 1037 something has changed on the MP's side. The MC then moves to the ADV 1038 PROCESSING state. 1040 +----------+ 1041 | WAIT FOR | 1042 | ADV | 1043 +----+-----+<--------+ 1044 | | 1045 advertisement| NACK sent| 1046 received| | 1047 v | 1048 +-----------+--------+ 1049 | ADV + 1050 | PROCESSING|<-----------------------+ 1051 +-+-----+---+ | 1052 | | | 1053 configure+ack | | ack | 1054 sent | | sent | 1055 | v | 1056 | +-----+ | 1057 | |CONF | advertisement received | 1058 +----------------------->| +-------------------------+ 1059 |error | +--+--+ | 1060 |configureResponse | | | 1061 |received | |configure | 1062 | | |sent | 1063 | | | | 1064 | v v advertisement | 1065 +------------------+---------------+ received | 1066 +--------->| WAIT FOR +---------------------+ 1067 | | CONF RESPONSE+ | 1068 | +-------+-------+ | 1069 | | | 1070 | | | 1071 | |successful | 1072 | |configureResponse | 1073 | |received | 1074 |configure v | 1075 |sent +-----------+ advertisement received| 1076 +------------+ESTABLISHED+-----------------------+ 1077 +-----------+ 1079 Figure 12: Media Consumer's state machine 1081 7. Versioning 1083 CLUE protocol messages are XML messages compliant to the CLUE 1084 protocol XML schema [I-D.ietf-clue-data-model-schema]. The version 1085 of the protocol corresponds to the version of the schema. Both 1086 client and server have to test the compliance of the received 1087 messages with the XML schema of the CLUE protocol. If the compliance 1088 is not verified, the message cannot be processed further. 1090 Obviously, client and server cannot communicate if they do not share 1091 exactly the same XML schema. Such a schema is associated with the 1092 CLUE URN "urn:ietf:params:xml:ns:clue-protocol". If all CLUE-enabled 1093 devices use that schema there will be no interoperability problems 1094 due to schema issues. 1096 This document defines XML schema version 1.0. The version usage is 1097 similar in philosophy to XMPP ([RFC6120]). A version number has 1098 major and minor components, each a non-negative integer. Major 1099 version changes denote non-interoperable changes. Minor version 1100 changes denote schema changes that are backward compatible by 1101 ignoring unknown XML elements, or other backward compatible changes. 1103 The minor versions of the XML schema MUST be backward compatible, not 1104 only in terms of schema but also semantically and procedurally as 1105 well. This means that they should define further features and 1106 functionality besides those defined in the previous versions, in an 1107 incremental way, without impacting the basic rules defined in the 1108 previous version of the schema. In this way, if a MP is able to 1109 speak, e.g., version 1.5 of the protocol while the MC only 1110 understands version 1.4, the MP should have no problem in reverting 1111 the dialogue back to version 1.4 without exploiting 1.5 features and 1112 functionality. Version 1.4 is the one to be spoken and has to appear 1113 in the "v" attribute of the subsequent CLUE messages. In other 1114 words, in this example, the MP MUST use version 1.4 and downgrade to 1115 the lower version. This said, and coherently with the general IETF 1116 "protocol robustness principle" stating that "an implementation must 1117 be conservative in its sending behavior, and liberal in its receiving 1118 behavior" [RFC1122], CLUE Participants MUST ignore unknown elements 1119 or attributes that are not envisioned in the negotiated protocol 1120 version and related extensions. 1122 8. Extensions 1124 Although the standard version of the CLUE protocol XML schema is 1125 designed to thoroughly cope with the requirements emerging from the 1126 application domain, new needs might arise and extensions can be 1127 designed. Extensions specify information and behaviors that are not 1128 described in a certain version of the protocol and specified in the 1129 related RFC document. Such information and behaviors can be 1130 optionally used in a CLUE dialogue and MUST be negotiated in the CLUE 1131 initiation phase. They can relate to: 1133 1. new information, to be carried in the existing messages. For 1134 example, more fields may be added within an existing message; 1136 2. new messages. This is the case if there is no proper message for 1137 a certain task, so a brand new CLUE message needs to be defined. 1139 As to the first type of extensions, it is possible to distinguish 1140 between protocol-specific and data model information. Indeed, CLUE 1141 messages are envelopes carrying both: 1143 o (i) XML elements defined within the CLUE protocol XML schema 1144 itself (protocol-specific information) 1146 o (ii) other XML elements compliant to the CLUE data model schema 1147 (data model information) 1149 When new protocol-specific information is needed somewhere in the 1150 protocol messages, it can be added in place of the elements and 1151 elements envisioned by the protocol schema. The 1152 policy currently defined in the protocol schema for handling 1153 and elements is: 1155 o elementFormDefault="qualified" 1157 o attributeFormDefault="unqualified" 1159 The new information must be qualified by namespaces other than 1160 "urn:ietf:params:xml:ns:clue-protocol" (the protocol URN) and 1161 "urn:ietf:params:xml:ns:clue-info" (the data model URN). Elements or 1162 attributes from unknown namespaces MUST be ignored. 1164 The other matter concerns data model information. Data model 1165 information is defined by the XML schema associated with the URN 1166 "urn:ietf:params:xml:ns:clue-info". Also for the XML elements 1167 defined in such a schema there are extensibility issues. Those 1168 issues are overcome by using and placeholders. 1169 New information within data model elements can be added in place of 1170 and schema elements, as long as they are 1171 properly namespace qualified. 1173 On the other hand (second type of extensions), "extra" CLUE protocol 1174 messages, i.e., messages not envisioned in the latest standard 1175 version of the schema, can be needed. In that case, the messages and 1176 the associated behavior should be defined in external documents that 1177 both communication parties must be aware of. 1179 As reported in Figure 13, the values of the fields of the 1180 element (either new information or new messages) take the following 1181 values: 1183 o a name; 1184 o an external XML Schema defining the XML information and/or the XML 1185 messages representing the extension; 1187 o the major standard version of the protocol that the extension 1188 refers to. 1190 1191 1192 1193 1194 1195 1196 1197 1198 1200 Figure 13: The element 1202 The above described element is carried within the 1203 'options' and 'optionsResponse' messages to represent the extensions 1204 supported both by the CI and the CR. 1206 Extensions MUST be defined in a separate XML schema file and MUST be 1207 provided with a companion document describing their semantics and 1208 use. 1210 8.1. Extension example 1212 An example of extension might be a "new" capture attribute (i.e., a 1213 capture attribute which is not envisioned in the current standard 1214 defining the CLUE data model in [I-D.ietf-clue-data-model-schema]) 1215 needed to further describe a video capture. 1217 The CLUE data model document ([I-D.ietf-clue-data-model-schema]) 1218 envisions the possibility of adding this kind of "extra" information 1219 in the description of a video capture by keeping the compatibility 1220 with the CLUE data model schema. This is made possible thanks to the 1221 presence of the element in the XML definition of the video 1222 capture, allowing for the introduction of a new XML field in the XML 1223 description. For the sake of convenience, the XML definition of a 1224 video capture taken from [I-D.ietf-clue-data-model-schema] is 1225 reported in Figure 14 below. 1227 1228 1229 1230 1231 1232 1234 1235 1236 1237 1238 1240 Figure 14: XML definition of a CLUE video capture 1242 According to such a definition, a video capture might have, after the 1243 set of the generic media capture attributes, a set of new attributes 1244 defined elsewhere, i.e., in an XML schema defining an extension. The 1245 XML schema defining the extension might look like the following 1246 (Figure 15): 1248 1249 1256 1262 1263 1264 1265 1266 1267 1268 1269 1271 1273 1274 1276 Figure 15: XML schema defining an extension 1278 By using the extension above, a video capture can be further 1279 described in the advertisement using the element 1280 containing two extra information ( and 1281 ) besides using the attributes envisioned for a 1282 generic media capture. As stated in this document, both participants 1283 must be aware of the extension schema and related semantics to use 1284 such an extension and must negotiate it via the 'options' and 1285 'optionsResponse' mechanism. 1287 9. XML Schema 1289 NOTE TO THE RFC-Editor: Please replace "data-model-schema-17.xsd" 1290 with the right schema location for the CLUE data model schema 1291 document (which is still to be defined at the time of this writing) 1292 in this section prior to publication as an RFC. 1294 In this section, the XML schema defining the CLUE messages is 1295 provided (Figure 16). 1297 1298 1306 1307 1309 1310 1311 1312 1313 1314 1315 1317 1318 1319 1320 1321 1322 1323 1325 1326 1327 1328 1329 1330 1331 1332 1333 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1366 1368 1370 1371 1372 1373 1374 1375 1376 1377 1378 1380 1381 1382 1383 1384 1385 1386 1387 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1411 1413 1414 1416 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1432 1433 1434 1436 1439 1440 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1469 1471 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1486 1487 1488 1489 1490 1491 1493 Figure 16: Schema defining CLUE messages 1495 10. Examples 1497 In this section we provide examples of 'advertisement' messages 1498 representing the telepresence environment described in 1499 [I-D.ietf-clue-data-model-schema], Section "Sample XML file" and 1500 Section "MCC example" respectively. 1502 10.1. Simple 'advertisement' 1504 Figure 17 presents a simple 'advertisement' message. The associated 1505 Media Provider's telepresence capabilities are described in 1506 [I-D.ietf-clue-data-model-schema], Section "Sample XML file". 1508 1509 1512 Napoli CLUE Endpoint 1513 34 1514 1515 1519 CS1 1520 1521 1522 1523 0.0 1524 0.0 1525 10.0 1526 1527 1528 0.0 1529 1.0 1530 10.0 1531 1532 1534 1535 true 1536 EG1 1537 main audio from the room 1538 1539 1 1540 it 1541 static 1542 room 1543 1544 alice 1545 bob 1546 ciccio 1547 1548 1549 1552 CS1 1553 1554 1555 1556 -2.0 1557 0.0 1558 10.0 1559 1560 1561 1562 1563 -3.0 1564 20.0 1565 9.0 1566 1567 1568 -1.0 1569 20.0 1570 9.0 1571 1572 1573 -3.0 1574 20.0 1575 11.0 1576 1577 1578 -1.0 1579 20.0 1580 11.0 1581 1583 1584 1585 true 1586 EG0 1587 left camera video capture 1588 1589 1 1590 it 1591 static 1592 individual 1593 1594 ciccio 1595 1596 1597 1600 CS1 1601 1602 1603 1604 0.0 1605 0.0 1606 10.0 1607 1608 1609 1610 1611 -1.0 1612 20.0 1613 9.0 1614 1615 1616 1.0 1617 20.0 1618 9.0 1619 1620 1621 -1.0 1622 20.0 1623 11.0 1624 1625 1626 1.0 1627 20.0 1628 11.0 1629 1630 1632 1633 true 1634 EG0 1635 central camera video capture 1636 1637 1 1638 it 1639 static 1640 individual 1641 1642 alice 1643 1644 1645 1648 CS1 1649 1650 1651 1652 2.0 1653 0.0 1654 10.0 1655 1656 1657 1658 1659 1.0 1660 20.0 1661 9.0 1662 1663 1664 3.0 1665 20.0 1666 9.0 1667 1668 1669 1.0 1670 20.0 1671 11.0 1672 1673 1674 3.0 1675 20.0 1676 11.0 1677 1678 1679 1680 true 1681 EG0 1682 right camera video capture 1683 1684 1 1685 it 1686 static 1687 individual 1688 1689 bob 1690 1691 1692 1695 CS1 1696 1697 1698 1699 -3.0 1700 20.0 1701 9.0 1702 1703 1704 3.0 1705 20.0 1706 9.0 1707 1708 1709 -3.0 1710 20.0 1711 11.0 1712 1713 1714 3.0 1715 20.0 1716 11.0 1717 1718 1719 1720 1721 SE1 1722 1723 SoundLevel:0 1724 EG0 1725 loudest room segment 1726 2 1727 it 1728 static 1729 individual 1730 1731 1734 CS1 1735 1736 1737 1738 0.0 1739 0.0 1740 10.0 1741 1742 1743 1744 1745 -3.0 1746 20.0 1747 7.0 1748 1749 1750 3.0 1751 20.0 1752 7.0 1753 1754 1755 -3.0 1756 20.0 1757 13.0 1758 1759 1760 3.0 1761 20.0 1762 13.0 1763 1764 1765 1766 true 1767 EG0 1768 zoomed out view of all people in the 1769 room 1770 2 1771 it 1772 static 1773 room 1774 1775 alice 1776 bob 1777 ciccio 1778 1779 1780 1781 1782 1783 600000 1784 1785 ENC1 1786 ENC2 1787 ENC3 1788 1789 1790 1791 300000 1792 1793 ENC4 1794 ENC5 1795 1796 1797 1798 1799 1800 1801 1802 1803 VC0 1804 VC1 1805 VC2 1806 1807 1808 1809 1810 VC3 1811 1812 1813 1814 1815 VC4 1816 1817 1818 1819 1820 AC0 1821 1822 1823 1825 1826 1827 1828 1829 VC3 1830 SE1 1831 1832 1833 VC0 1834 VC2 1835 VC4 1836 1837 1838 1839 1840 1841 1842 Bob 1843 1844 1845 minute taker 1846 1847 1848 1849 1850 Alice 1851 1852 1853 presenter 1854 1855 1856 1857 1858 Ciccio 1859 1860 1861 chairman 1862 timekeeper 1863 1864 1865 1867 Figure 17: 'advertisement' message example 1869 10.2. 'advertisement' with Multiple Content Captures 1871 Figure 18 presents a simple 'advertisement' message containing a 1872 Multiple Content Capture (MCC). The associated Media Provider's 1873 telepresence capabilities are described in 1874 [I-D.ietf-clue-data-model-schema], Section "MCC example". 1876 1877 1880 Napoli CLUE Endpoint 1881 34 1882 1883 1887 CS1 1888 1889 1890 1891 0.0 1892 0.0 1893 10.0 1894 1895 1896 0.0 1897 1.0 1898 10.0 1899 1900 1901 1902 true 1903 EG1 1904 main audio from the room 1905 1906 1 1907 it 1908 static 1909 room 1910 1911 alice 1912 bob 1913 ciccio 1914 1915 1916 1919 CS1 1920 1921 1922 1923 0.5 1924 1.0 1925 0.5 1926 1927 1928 0.5 1929 0.0 1930 0.5 1931 1932 1933 1934 true 1935 EG0 1936 left camera video capture 1937 1938 1 1939 it 1940 static 1941 individual 1942 1943 ciccio 1944 1945 1946 1949 CS1 1950 1951 1952 1953 0.0 1954 0.0 1955 10.0 1956 1957 1958 1959 1960 -1.0 1961 20.0 1962 9.0 1963 1964 1965 1.0 1966 20.0 1967 9.0 1968 1969 1970 -1.0 1971 20.0 1972 11.0 1973 1974 1975 1.0 1976 20.0 1977 11.0 1978 1979 1980 1981 true 1982 EG0 1983 central camera video capture 1984 1985 1 1986 it 1987 static 1988 individual 1989 1990 alice 1991 1992 1993 1996 CS1 1997 1998 1999 2000 2.0 2001 0.0 2002 10.0 2003 2004 2005 2006 2007 1.0 2008 20.0 2009 9.0 2010 2011 2012 3.0 2013 20.0 2014 9.0 2015 2016 2017 1.0 2018 20.0 2019 11.0 2020 2021 2022 3.0 2023 20.0 2024 11.0 2025 2026 2027 2028 true 2029 EG0 2030 right camera video capture 2031 2032 1 2033 it 2034 static 2035 individual 2036 2037 bob 2038 2039 2040 2043 CS1 2044 2045 2046 2047 -3.0 2048 20.0 2049 9.0 2050 2051 2052 3.0 2053 20.0 2054 9.0 2055 2056 2057 -3.0 2058 20.0 2059 11.0 2060 2061 2062 3.0 2063 20.0 2064 11.0 2065 2066 2067 2068 2069 SE1 2070 2071 SoundLevel:0 2072 EG0 2073 loudest room segment 2074 2 2075 it 2076 static 2077 individual 2078 2079 2082 CS1 2083 2084 2085 2086 0.0 2087 0.0 2088 10.0 2089 2090 2091 2092 2093 -3.0 2094 20.0 2095 7.0 2096 2097 2098 3.0 2099 20.0 2100 7.0 2101 2102 2103 -3.0 2104 20.0 2105 13.0 2106 2107 2108 3.0 2109 20.0 2110 13.0 2111 2112 2113 2114 true 2115 EG0 2116 2117 zoomed out view of all people in the room 2118 2119 2 2120 it 2121 static 2122 room 2123 2124 alice 2125 bob 2126 ciccio 2127 2128 2129 2132 CS1 2133 2134 2135 2136 -3.0 2137 20.0 2138 9.0 2139 2140 2141 3.0 2142 20.0 2143 9.0 2144 2145 2146 -3.0 2147 20.0 2148 11.0 2149 2150 2151 3.0 2152 20.0 2153 11.0 2154 2155 2157 2158 2159 SE1 2160 2161 SoundLevel:1 2162 penultimate loudest room segment 2163 2164 it 2165 static 2166 individual 2167 2168 2171 CS1 2172 2173 2174 2175 -3.0 2176 20.0 2177 9.0 2178 2179 2180 3.0 2181 20.0 2182 9.0 2183 2184 2185 -3.0 2186 20.0 2187 11.0 2188 2189 2190 3.0 2191 20.0 2192 11.0 2193 2194 2195 2196 2197 SE1 2198 2199 SoundLevel:2 2200 last but two loudest room segment 2201 2202 it 2203 static 2204 individual 2206 2207 2210 CS1 2211 2212 2213 2214 -3.0 2215 20.0 2216 9.0 2217 2218 2219 3.0 2220 20.0 2221 9.0 2222 2223 2224 -3.0 2225 20.0 2226 11.0 2227 2228 2229 3.0 2230 20.0 2231 11.0 2232 2233 2234 2235 2236 VC3 2237 VC5 2238 VC6 2239 2240 3 2241 EG0 2242 big picture of the current speaker + 2243 pips about previous speakers 2244 3 2245 it 2246 static 2247 individual 2248 2249 2250 2251 2252 600000 2253 2254 ENC1 2255 ENC2 2256 ENC3 2257 2258 2259 2260 300000 2261 2262 ENC4 2263 ENC5 2264 2265 2266 2267 2268 2269 2270 2271 participants' individual 2272 videos 2273 2274 VC0 2275 VC1 2276 VC2 2277 2278 2279 2280 loudest segment of the 2281 room 2282 2283 VC3 2284 2285 2286 2287 loudest segment of the 2288 room + pips 2289 2290 VC7 2291 2292 2293 2294 room audio 2295 2296 AC0 2297 2298 2299 2300 room video 2301 2302 VC4 2303 2304 2305 2306 2307 2308 2309 2310 VC3 2311 VC7 2312 SE1 2313 2314 2315 VC0 2316 VC2 2317 VC4 2318 2319 2320 2321 2322 2323 2324 Bob 2325 2326 2327 minute taker 2328 2329 2330 2331 2332 Alice 2333 2334 2335 presenter 2336 2337 2338 2339 2340 Ciccio 2341 2342 2343 chairman 2344 timekeeper 2345 2346 2347 2348 Figure 18: An example of 'advertisement' message with MCC 2350 11. Security Considerations 2352 As a general consideration, we remark that the CLUE framework (and 2353 related protocol) has been conceived at the outset by embracing the 2354 security-by-design paradigm. This entails that a number of 2355 requirements have been identified and properly standardized as 2356 mandatory within the entire set of documents associated with the CLUE 2357 architecture. Requirements include: (i) the use of cryptography and 2358 authentication; (ii) protection of all sensitive fields; (iii) mutual 2359 authentication between CLUE endpoints; (iv) the presence of 2360 authorization mechanisms; (v) the presence of native defence 2361 mechanisms against malicious activities such as eavesdropping, 2362 selective modification, deletion, replay (and related combinations 2363 thereof). Hence, security of the single components of the CLUE 2364 solution cannot be evaluated independently of the integrated view of 2365 the final architecture. 2367 The CLUE protocol is an application-level protocol allowing a Media 2368 Producer and a Media Consumer to negotiate a variegated set of 2369 parameters associated with the establishment of a telepresence 2370 session. This unavoidably exposes a CLUE-enabled telepresence system 2371 to a number of potential threats, most of which are extensively 2372 discussed in the framework document [I-D.ietf-clue-framework]. The 2373 security considerations section of the mentioned document actually 2374 discusses issues associated with the setup and management of a 2375 telepresence session both in the basic case involving two CLUE 2376 endpoints acting, respectively, as MP and MC, and in the more 2377 advanced scenario envisaging the presence of an MCU. 2379 The framework document also mentions that the information carried 2380 within CLUE protocol messages might contain sensitive data, which 2381 SHOULD hence be accessed only by authenticated endpoints. Security 2382 issues associated with the CLUE data model schema are discussed in 2383 [I-D.ietf-clue-data-model-schema]. 2385 There is extra information carried by the CLUE protocol which is not 2386 associated with the CLUE data model schema and which exposes 2387 information that might be of concern. This information is primarily 2388 exchanged during the negotiation phase via the 'options' and 2389 'optionsResponse' messages. In the CLUE Participant state machine 2390 OPTIONS state, both parties agree on the version and on the 2391 extensions to be used in the subsequent CLUE messages exchange phase. 2392 A malicious participant might either try to retrieve a detailed 2393 footprint of a specific CLUE protocol implementation during this 2394 initial setup phase, or force the communicating party to use a non- 2395 up-to-date version of the protocol which they know how to break. 2397 Indeed, exposing all of the supported versions and extensions could 2398 conceivably leak information about the specific implementation of the 2399 protocol. In theory an implementation could choose not to announce 2400 all of the versions it supports if it wants to avoid such leakage, 2401 though at the expenses of interoperability. With respect to the 2402 above considerations, it is noted that the OPTIONS state is only 2403 reached after the CLUE data channel has been successfully set up. 2404 This ensures that only authenticated parties can exchange 'options' 2405 and related 'optionsResponse' messages and hence drastically reduces 2406 the attack surface which is exposed to malicious parties. 2408 The CLUE framework clearly states the requirement to protect CLUE 2409 protocol messages against threats deriving from the presence of a 2410 malicious agent capable to gain access to the CLUE data channel. 2411 Such a requirement is met by the CLUE data channel solution described 2412 in [I-D.ietf-clue-datachannel], which ensures protection from both 2413 message recovery and message tampering. With respect to this last 2414 point, any implementation of the CLUE protocol compliant with the 2415 CLUE specification MUST rely on the exchange of messages which flow 2416 on top of a reliable and ordered SCTP over DTLS transport channel 2417 connecting two CLUE Participants. 2419 12. IANA Considerations 2421 This document registers a new XML namespace, a new XML schema and the 2422 MIME type for the schema. This document also registers the "CLUE" 2423 Application Service tag and the "CLUE" Application Protocol tag and 2424 defines registries for the CLUE messages and response codes. 2426 12.1. URN Sub-Namespace Registration 2428 This section registers a new XML namespace, 2429 ""urn:ietf:params:xml:ns:clue-protocol"". 2431 URI: urn:ietf:params:xml:ns:clue-protocol 2433 Registrant Contact: IESG (iesg@ietf.org). 2435 XML: 2437 BEGIN 2438 2439 2441 2442 2443 CLUE Messages 2444 2445 2446

Namespace for CLUE Messages

2447

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

2448 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2449 with the RFC number for this specification.]] 2450

See 2451 RFCXXXX.

2452 2453 2454 END 2456 12.2. XML Schema registration 2458 This section registers an XML schema per the guidelines in [RFC3688]. 2460 URI: urn:ietf:params:xml:schema:clue-protocol 2462 Registrant Contact: IESG (iesg@ietf.org). 2464 Schema: The XML for this schema can be found as the entirety of 2465 Section 9 of this document. 2467 12.3. MIME Media Type Registration for 'application/clue+xml' 2469 This section registers the ""application/clue+xml"" MIME type. 2471 To: ietf-types@iana.org 2473 Subject: Registration of MIME media type application/clue+xml 2475 MIME media type name: application 2477 MIME subtype name: clue+xml 2479 Required parameters: (none) 2481 Optional parameters: charset 2482 Same as the charset parameter of "application/xml" as specified in 2483 [RFC7303], Section 3.2. 2485 Encoding considerations: Same as the encoding considerations of 2486 "application/xml" as specified in [RFC7303], Section 3.2. 2488 Security considerations: This content type is designed to carry 2489 protocol data related to telepresence session control. Some of the 2490 data could be considered private. This media type does not provide 2491 any protection and thus other mechanisms such as those described in 2492 Section Security are required to protect the data. This media type 2493 does not contain executable content. 2495 Interoperability considerations: None. 2497 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 2498 replace XXXX with the RFC number for this specification.]] 2500 Applications that use this media type: CLUE participants. 2502 Additional Information: Magic Number(s): (none), 2503 File extension(s): .xml, 2504 Macintosh File Type Code(s): TEXT. 2506 Person & email address to contact for further information: Simon 2507 Pietro Romano (spromano@unina.it). 2509 Intended usage: LIMITED USE 2511 Author/Change controller: The IETF 2513 Other information: This media type is a specialization of 2514 application/xml [RFC7303], and many of the considerations described 2515 there also apply to application/clue+xml. 2517 12.4. CLUE Protocol Registry 2519 The document requests that the IANA creates new registries for CLUE 2520 messages and response codes. 2522 12.4.1. CLUE Message Types 2524 The following summarizes the registry for CLUE messages: 2526 Related Registry: CLUE Message Types Registry 2528 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX 2529 with the RFC number for this specification.]] 2530 Registration/Assignment Procedures: Following the policies outlined 2531 in [RFC5226], the IANA policy for assigning new values for the CLUE 2532 message types for the CLUE protocol is Specification Required. 2534 Registrant Contact: IESG (iesg@ietf.org). 2536 The initial Message table is populated using the CLUE messages 2537 described in Section 5 and defined in the XML schema in Section 9. 2539 +-------------------+-----------------------------------+-----------+ 2540 | Message | Description | Reference | 2541 +-------------------+-----------------------------------+-----------+ 2542 | options | Sent by the CI to the CR in the | RFCXXXX | 2543 | | initiation phase to specify the | | 2544 | | roles played by the CI, the | | 2545 | | supported versions and the | | 2546 | | supported extensions. | | 2547 | optionsResponse | Sent by the CI to the CR in reply | RFCXXXX | 2548 | | to an 'options' message to | | 2549 | | finally estabilsh the version and | | 2550 | | the extensions to be used in the | | 2551 | | following CLUE messages exchange. | | 2552 | advertisement | Sent by the MP to the MC to | RFCXXXX | 2553 | | specify the telepresence | | 2554 | | capabilities of the MP expressed | | 2555 | | according to the CLUE framework. | | 2556 | ack | Sent by the MC to the MP to | RFCXXXX | 2557 | | acknowledge the reception of an | | 2558 | | 'advertisement' message. | | 2559 | configure | Sent by the MC to the MP to | RFCXXXX | 2560 | | specify the desired media | | 2561 | | captures among those specified in | | 2562 | | the 'advertisement'. | | 2563 | configureResponse | Sent by the MP to the MC in reply | RFCXXXX | 2564 | | to a CONFIGURE message to | | 2565 | | communicate if the configuration | | 2566 | | request has been successfully | | 2567 | | processed or not. | | 2568 +-------------------+-----------------------------------+-----------+ 2570 IANA-CLUE 2572 12.4.2. CLUE Response Codes 2574 The following summarizes the requested registry for CLUE response 2575 codes: 2577 Related Registry: CLUE Response Code Registry 2578 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX 2579 with the RFC number for this specification.]] 2581 Registration/Assignment Procedures: Following the policies outlined 2582 in [RFC5226], the IANA policy for assigning new values for the 2583 Response codes for CLUE shall be Specification Required. 2585 Registrant Contact: IESG (iesg@ietf.org). 2587 The initial Response-code table is populated using the Response codes 2588 defined in Section 5.7 as follows: 2590 +--------+---------------+------------------------------+-----------+ 2591 | Number | Default | Description | Reference | 2592 | | Response | | | 2593 | | String | | | 2594 +--------+---------------+------------------------------+-----------+ 2595 | 200 | Success | The request has been | RFCXXXX | 2596 | | | successfully processed. | | 2597 | 300 | Low-level | A generic low-level request | RFCXXXX | 2598 | | request | error has occurred. | | 2599 | | error. | | | 2600 | 301 | Bad syntax | The XML syntax of the | RFCXXXX | 2601 | | | message is not correct. | | 2602 | 302 | Invalid value | The message contains an | RFCXXXX | 2603 | | | invalid parameter value. | | 2604 | 303 | Conficting | The message contains values | RFCXXXX | 2605 | | values | that cannot be used | | 2606 | | | together. | | 2607 | 400 | Semantic | Semantic errors in the | RFCXXXX | 2608 | | errors | received CLUE protocol | | 2609 | | | message. | | 2610 | 401 | Version not | The protocol version used in | RFCXXXX | 2611 | | supported | the message is not | | 2612 | | | supported. | | 2613 | 402 | Invalid | Sequence number gap; | RFCXXXX | 2614 | | sequencing | repeated sequence number; | | 2615 | | | sequence number outdated. | | 2616 | 403 | Invalid | The clueId used in the | RFCXXXX | 2617 | | identifier | message is not valid or | | 2618 | | | unknown. | | 2619 | 404 | advertisement | The sequence number of the | RFCXXXX | 2620 | | Expired | advertisement the configure | | 2621 | | | refers to is out of date. | | 2622 | 405 | Subset choice | The subset choice is not | RFCXXXX | 2623 | | not allowed | allowed for the specified | | 2624 | | | Multiple Content Capture. | | 2625 +--------+---------------+------------------------------+-----------+ 2627 13. Acknowledgments 2629 The authors thank all the CLUErs for their precious feedbacks and 2630 support, in particular Paul Kyzivat, Christian Groves and Scarlett 2631 Liuyan. 2633 14. References 2635 14.1. Normative References 2637 [I-D.ietf-clue-data-model-schema] 2638 Presta, R. and S. Romano, "An XML Schema for the CLUE data 2639 model", draft-ietf-clue-data-model-schema-17 (work in 2640 progress), August 2016. 2642 [I-D.ietf-clue-datachannel] 2643 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 2644 clue-datachannel-14 (work in progress), August 2016. 2646 [I-D.ietf-clue-framework] 2647 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 2648 for Telepresence Multi-Streams", draft-ietf-clue- 2649 framework-25 (work in progress), January 2016. 2651 [I-D.ietf-clue-signaling] 2652 Hansen, R., Kyzivat, P., Xiao, L., and C. Groves, "Session 2653 Signaling for Controlling Multiple Streams for 2654 Telepresence (CLUE)", draft-ietf-clue-signaling-13 (work 2655 in progress), November 2017. 2657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2658 Requirement Levels", BCP 14, RFC 2119, 2659 DOI 10.17487/RFC2119, March 1997, 2660 . 2662 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2663 Jacobson, "RTP: A Transport Protocol for Real-Time 2664 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2665 July 2003, . 2667 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2668 DOI 10.17487/RFC3688, January 2004, 2669 . 2671 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2672 IANA Considerations Section in RFCs", RFC 5226, 2673 DOI 10.17487/RFC5226, May 2008, 2674 . 2676 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 2677 DOI 10.17487/RFC7303, July 2014, 2678 . 2680 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2681 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2682 May 2017, . 2684 14.2. Informative References 2686 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2687 Communication Layers", STD 3, RFC 1122, 2688 DOI 10.17487/RFC1122, October 1989, 2689 . 2691 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 2692 Session Initiation Protocol (SIP)", RFC 4353, 2693 DOI 10.17487/RFC4353, February 2006, 2694 . 2696 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 2697 DOI 10.17487/RFC5117, January 2008, 2698 . 2700 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 2701 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 2702 March 2011, . 2704 [RFC7262] Romanow, A., Botzko, S., and M. Barnes, "Requirements for 2705 Telepresence Multistreams", RFC 7262, 2706 DOI 10.17487/RFC7262, June 2014, 2707 . 2709 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 2710 DOI 10.17487/RFC7667, November 2015, 2711 . 2713 Authors' Addresses 2715 Roberta Presta 2716 University of Napoli 2717 Via Claudio 21 2718 Napoli 80125 2719 Italy 2721 EMail: roberta.presta@unina.it 2722 Simon Pietro Romano 2723 University of Napoli 2724 Via Claudio 21 2725 Napoli 80125 2726 Italy 2728 EMail: spromano@unina.it