idnits 2.17.1 draft-presta-clue-protocol-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 97 instances of too long lines in the document, the longest one being 60 characters in excess of 72. ** The abstract seems to contain references ([I-D.kyzivat-clue-signaling], [I-D.ietf-clue-framework], [I-D.ietf-clue-telepresence-requirements]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 613: '... ascpect MUST be explicitely adverti...' RFC 2119 keyword, line 654: '...om unknown namespaces MUST be ignored....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 457 has weird spacing: '...receive sen...' == Line 551 has weird spacing: '...receive rece...' -- The document date (October 8, 2013) is 3851 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBC' is mentioned on line 734, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-clue-data-model-schema-00 == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-11 -- No information found for draft-ietf-clue-telepresence-requirements - is the name correct? == Outdated reference: A later version (-08) exists of draft-kyzivat-clue-signaling-05 Summary: 5 errors (**), 0 flaws (~~), 7 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: Informational University of Napoli 5 Expires: April 11, 2014 October 8, 2013 7 CLUE protocol 8 draft-presta-clue-protocol-02 10 Abstract 12 The CLUE protocol is an application protocol conceived for the 13 description and negotiation of a CLUE telepresence session. The 14 design of the CLUE protocol takes into account the requirements and 15 the framework defined, respectively, in [I-D.ietf-clue-framework] and 16 [I-D.ietf-clue-telepresence-requirements]. The companion document 17 [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as 18 well as on the SIP/SDP session establishment phase. We herein focus 19 on the application level perspective. Message details, together with 20 the behavior of both the Media Provider and the Media Consumer are 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 http://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 April 11, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 (http://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. Overview of the CLUE protocol messages . . . . . . . . . . . . 3 60 3.1. ADVERTISEMENT . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.4. RE-ADV . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.5. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4. Protocol state machines . . . . . . . . . . . . . . . . . . . 10 66 5. Media Consumer's state machine . . . . . . . . . . . . . . . . 11 67 6. Media Provider's state machine . . . . . . . . . . . . . . . . 13 68 7. About CLUE protocol XML schema versioning . . . . . . . . . . 15 69 8. Extensibility issues . . . . . . . . . . . . . . . . . . . . . 16 70 8.1. Aspect 1 - new information within existing messages . . . 16 71 8.2. Aspect 2 - new messages . . . . . . . . . . . . . . . . . 17 72 9. Managing protocol version negotiation and extensions: the 73 OPTIONS request . . . . . . . . . . . . . . . . . . . . . . . 17 74 9.1. An example using OPTIONS . . . . . . . . . . . . . . . . . 19 75 10. XML Schema of CLUE protocol messages . . . . . . . . . . . . . 20 76 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 12. Handling channel errors . . . . . . . . . . . . . . . . . . . 24 78 13. Diff with the -01 version . . . . . . . . . . . . . . . . . . 24 79 14. Diff with -00 version . . . . . . . . . . . . . . . . . . . . 25 80 15. Informative References . . . . . . . . . . . . . . . . . . . . 25 82 1. Introduction 84 The CLUE protocol is an application protocol used by a Media Provider 85 (MP) and a Media Consumer (MC) to establish a CLUE multimedia 86 telepresence session. The main goals of the CLUE protocol are: 88 1. enabling a MP to fully announce its current telepresence 89 capabilities to the MC in terms of available media captures, 90 encodings, and simultaneity constraints; 92 2. enabling a MC to request the desired multimedia streams from the 93 offering MP. 95 CLUE protocol messages flow upon a DTLS/SCTP/UDP channel established 96 as depicted in [I-D.kyzivat-clue-signaling]. While 97 [I-D.kyzivat-clue-signaling] focuses on protocol signaling details 98 and on its interaction with the SIP/SDP session establishment phase, 99 we herein investigate the protocol in action and try to define the 100 behavior of both the MP and the MC at the CLUE application level. We 101 assume the DTLS/SCTP/UDP channel is established and discuss how the 102 CLUE dialogue between the MP and the MC can be exploited to 103 successfully setup the telepresence session according to the 104 principles and concepts pointed out in in [I-D.ietf-clue-framework]. 106 In Section 3 we provide an overview of the CLUE protocol and describe 107 CLUE messages along with their features and functionality. MC's and 108 MP's state machines are introduced in Section 4 and further described 109 in Section 5 and Section 6 respectively. Versioning, extensions and 110 options management mechanisms are discussed in Section 7, Section 8 111 and Section 9, respectively. The XML schema defining the CLUE 112 messages is reported in Section 10. 114 2. Terminology 116 This document refers to the same terminology used in 117 [I-D.ietf-clue-framework] and in [I-D.kyzivat-clue-signaling]. 119 3. Overview of the CLUE protocol messages 121 The CLUE protocol, as defined in the following, is a stateful, 122 client-server, XML-based application protocol. The server side of 123 the protocol is represented by a Media Provider, which produces media 124 streams, while the client side is represented by the Media Consumer, 125 which requests media streams. 127 The MP first advertises the media captures and associated encodings 128 to the MC, as well as possible simultaneity constraints. The 129 description of such telepresence features is made according to the 130 information defined in the CLUE framework and data model 131 ([I-D.ietf-clue-framework] and [I-D.ietf-clue-data-model-schema]). 132 The CLUE message conveing the MP's multimedia offer is the 133 ADVERTISEMENT message. Such message leverages the XML definitions 134 provided in [I-D.ietf-clue-data-model-schema] for the description of 135 media captures, encodings, and simultaneity constraints features. 137 The MC selects the desired streams coming from the MP by using the 138 CONFIGURE message, which makes reference to the information carried 139 in the ADVERTISEMENT previously received by the MP. 141 In the following, a bird's-eye view of the CLUE protocol messages is 142 provided. For each message it is indicated who sends it, who 143 receives it, a brief description of the information it carries, and 144 how/when it is used. Besides ADVERTISEMENT and CONFIGURE, new 145 messages have been conceived in order to provide all the mechanisms 146 and operations envisaged in [I-D.kyzivat-clue-signaling]. 148 o ADVERTISEMENT (ADV) 150 o CONFIGURE (CONF) 152 o RESPONSE 154 o RE-ADV 156 o OPTIONS 158 3.1. ADVERTISEMENT 159 +---------- ---+-----------------------------------------------------+ 160 | | | 161 | FROM | MP | 162 | | | 163 +--------------+-----------------------------------------------------+ 164 | | | 165 | TO | MC | 166 | | | 167 +--------------+-----------------------------------------------------+ 168 | | | 169 | TYPE | Notification | 170 | | | 171 +--------------+-----------------------------------------------------+ 172 | | | 173 | DESCRIPTION | This message is used by the MP to advertise the | 174 | | available media captures and related information | 175 | | to the MC. | 176 | | The ADV contains elements compliant with the | 177 | | CLUE data model and other information like the | 178 | | CLUE protocol version and a sequence number. | 179 | | | 180 +--------------+-----------------------------------------------------+ 181 | | | 182 | USAGE | The MP sends this message as soon as the | 183 | | CLUE channel is ready. The MP sends an ADV to the | 184 | | MC each time there is a modification of the MP's | 185 | | telepresence capabilities. | 186 | | The ADV message is also sent back to the MC | 187 | | when the MP receives a RE-ADV request. | 188 +--------------+-----------------------------------------------------+ 190 The ADV message is considered a notification since, during the 191 session, it can be sent from the MP also on a per-event basis, i.e. 192 when the CLUE capabilities of the MP change with respect to the last 193 issued ADV. It is still to be discussed if a "delta" mechanism for 194 advertising only the changes with respect to the previous 195 notification should be adopted. Similar approaches have been 196 proposed for partial notifications in centralized conferencing 197 frameworks ([RFC6502]), leveraging the XML diff codification 198 mechanism defined in [RFC5261]. 200 3.2. CONFIGURE 201 +--------------+-----------------------------------------------------+ 202 | | | 203 | FROM | MC | 204 | | | 205 +--------------+-----------------------------------------------------+ 206 | | | 207 | TO | MP | 208 | | | 209 +--------------+-----------------------------------------------------+ 210 | | | 211 | TYPE | Request | 212 | | | 213 +--------------+-----------------------------------------------------+ 214 | | | 215 | DESCRIPTION | This message allows a MC to ask for the | 216 | | desired (advertised) capture. It contains capture | 217 | | encodings and other information like the CLUE | 218 | | protocol version and a sequence number. | 219 | | | 220 +--------------+-----------------------------------------------------+ 221 | | | 222 | USAGE | The MC can send a CONF after the reception of | 223 | | an ADV or each time it wants to request other | 224 | | advertised captures from the MP. | 225 +--------------+-----------------------------------------------------+ 227 3.3. RESPONSE 228 +--------------+-----------------------------------------------------+ 229 | | | 230 | FROM | MP | 231 | | | 232 +--------------+-----------------------------------------------------+ 233 | | | 234 | TO | MC | 235 | | | 236 +--------------+-----------------------------------------------------+ 237 | | | 238 | TYPE | Response | 239 | | | 240 +--------------+-----------------------------------------------------+ 241 | | | 242 | DESCRIPTION | This message allows a MP to answer to a CONF | 243 | | message. Besides the protocol version and a | 244 | | sequence number, it contains a response code with | 245 | | a response string indicating either the success | 246 | | or the failure (along with failure details) of | 247 | | a CONF request elaboration. Example response | 248 | | codes and strings are provided in the following | 249 | | table. | 250 | | | 251 +--------------+-----------------------------------------------------+ 252 | | | 253 | USAGE | The MP sends this message in response to a CONF | 254 | | message. | 255 +--------------+-----------------------------------------------------+ 257 Response codes can be designed by adhering to the HTTP semantics, as 258 shown below. 260 +-----------------+----------------------+--------------------------+ 261 | | | | 262 | Response code | Response string | Description | 263 | | | | 264 +-----------------+----------------------+--------------------------+ 265 | | | | 266 | 410 | Bad syntax | The XML syntax of the | 267 | | | CONF message is not | 268 | | | correct. | 269 +-----------------+----------------------+--------------------------+ 270 | | | | 271 | 411 | Invalid value | The CONF message | 272 | | | contains an invalid | 273 | | | parameter value. | 274 +-----------------+----------------------+--------------------------+ 275 | | | | 276 | 412 | Invalid identifier | The identifier used for | 277 | | | requesting a capture is | 278 | | | not valid or unknown. | 279 +-----------------+----------------------+--------------------------+ 280 | | | | 281 | 413 | Conflicting values | The CONF message | 282 | | | contains values that | 283 | | | cannot be used together.| 284 +-----------------+----------------------+--------------------------+ 285 | | | | 286 | 420 | Invalid sequencing | The sequence number of | 287 | | | the CONF message is out | 288 | | | of date or corresponds | 289 | | | to an obsoleted ADV. | 290 +-----------------+----------------------+--------------------------+ 291 | | | | 292 | 510 | Version not supported| The CLUE protocol | 293 | | | version of the CONF | 294 | | | message is not supported| 295 | | | by the MP. | 296 +-----------------+----------------------+--------------------------+ 297 | | | | 298 | 511 | Option not supported | The option requested in | 299 | | | the CONF message is not | 300 | | | supported by the MP. | 301 +-----------------+----------------------+--------------------------+ 303 ... TBC. 305 +---------------+------------------------+ 306 | | | 307 | Response code | Rescription | 308 | family | | 309 +---------------+------------------------+ 310 | | | 311 | 1XX | Temporary info | 312 | | | 313 +---------------+------------------------+ 314 | | | 315 | 2XX | Success | 316 | | | 317 +---------------+------------------------+ 318 | | | 319 | 3XX | Redirection | 320 | | | 321 +---------------+------------------------+ 322 | | | 323 | 4XX | Client error | 324 | | | 325 +---------------+------------------------+ 326 | | | 327 | 5XX | Server error | 328 | | | 329 +---------------+------------------------+ 331 3.4. RE-ADV 332 +---------- ---+-----------------------------------------------------+ 333 | | | 334 | FROM | MC | 335 | | | 336 +--------------+-----------------------------------------------------+ 337 | | | 338 | TO | MP | 339 | | | 340 +--------------+-----------------------------------------------------+ 341 | | | 342 | TYPE | Request | 343 | | | 344 +--------------+-----------------------------------------------------+ 345 | | | 346 | DESCRIPTION | This message allows a MC to request a MP to | 347 | | issue a new copy of the ADV. This message can | 348 | | contain a reason string indicating the motivation | 349 | | for the request (e.g., refresh, missing elements | 350 | | in the received ADV, wrong syntax in the received | 351 | | ADV, invalid capture area, invalid line of | 352 | | capture point, etc). | 353 | | | 354 +--------------+-----------------------------------------------------+ 355 | | | 356 | USAGE | The MC sends this message to the MP when the | 357 | | timeout for the ADV is fired, or when the ADV is | 358 | | not compliant with the CLUE specifications (this | 359 | | can be useful for interoperability testing | 360 | | purposes) | 361 | | | 362 +--------------+-----------------------------------------------------+ 364 3.5. OPTIONS 366 ToDo. See Section 9. 368 4. Protocol state machines 370 The CLUE protocol is an application protocol used between a Media 371 Provider (MP) and a Media Consumer (MC) in order to establish a 372 multimedia telepresence session. CLUE protocol messages flow upon a 373 DTLS/SCTP channel established as depicted in 374 [I-D.kyzivat-clue-signaling]. Over such a channel there are 375 typically two CLUE streams between the channel terminations flowing 376 in opposite directions. In other words, typically, both channel 377 terminations act simultaneously as a MP and as a MC. We herein 378 discuss the state machines associated, respectively, with the MC 379 process and with the MP process. 381 5. Media Consumer's state machine 383 An MC in the IDLE state is waiting for an ADV coming from the MP. If 384 the timeout expires ("timeout"), the MC switches to the TIMEOUT 385 state. 387 In the TIMEOUT state, if the number of trials is below the retry 388 threshold, the MC sends a RE-ADV/refresh message to the MP ("send RE- 389 ADV"), switching back to the IDLE state. Otherwise, the MC moves to 390 the TERMINATED state. 392 When the ADV has been received ("receive ADV"), the MC goes into the 393 ADV RECEIVED state. The ADV is then parsed. If something goes wrong 394 with the ADV (bad syntax, missing XML elements, etc.), the MC sends a 395 RE-ADV message to the MP specifying the encountered problem via a 396 proper reason phrase. In this way, the MC switches back to the IDLE 397 state, waiting for a new copy of the ADV. If the ADV is successfully 398 processed, the MC issues a CONF message towards the MP ("send CONF") 399 and switches to the TRYING state. 401 While in the TRYING state, the MC is waiting for a RESPONSE message 402 (to the issued CONF) from the MP. If the timeout expires 403 ("timeout"), the MC moves to the TIMEOUT state and sends a RE-ADV in 404 order to solicit a new ADV from the MP. If a RESPONSE with an error 405 code is received ("receive 4xx, 5xx not supported"), then the MC 406 moves back to the ADV-RCVD state and produces a new CONF message to 407 be sent to the MP. If a successful RESPONSE arrives ("receive 200 408 OK"), the MC gets into the IN CALL state. If a new ADV arrives in 409 the meanwhile, it is ignored. Indeed, as soon as the timeout 410 expires, the MC switches to the TIMEOUT state and then sends a RE-ADV 411 to the MP. 413 When the MC is in the IN CALL state, it means that the telepresence 414 session has been set up according to the MC's preferences. Both the 415 MP and the MC have agreed on (and are aware of) the media streams to 416 be exchanged within the call. If the MC decides to change something 417 in the call settings, it issues a new CONF ("send CONF") and moves 418 back to the TRYING state. If a new ADV arrives from the MP ("receive 419 ADV"), it means that something has changed on the MP's side. The MC 420 then moves to the ADV-RCV state and prepares a new CONF taking into 421 account the received updates. When the underlying channel is closed, 422 the MC moves into the TERMINATED state. 424 The TERMINATED state is reachable from each of the aforementioned 425 states whenever the underlying channel is closed. The corresponding 426 transitions have not been reported for the sake of simplicity. This 427 termination condition is a temporary solution. 429 +-----+ 430 +--------+-------------timeout------>+----+--+ | 431 | IDLE +<----+ |TIMEOUT| | 432 +---+----+<----+--------send---------+-------+ | 433 | | RE-ADV(refresh) ^ | 434 | | | | 435 | | | | 436 receive send | | 437 ADV RE-ADV | | 438 +---receive-------+ | (missing elements, | | 439 | error RESP | | invalid area,...) | | 440 | v v | | | 441 +---------------++---------+ | | | 442 +---------------->+ ADV +----+ timeout | 443 | +----->| RECEIVED|<-----+ | | 444 | | +---+-----+ | | | 445 receive | | | | | 446 ADV | | | | | 447 | | | | | | 448 | receive send receive | | 449 | ADV CONF error RESP, | | 450 | | | retry not expired | | 451 | | v | | | 452 +-----------------+--------+-------+------------------------+ | 453 +---+------+ TRYING +-------+ | 454 | | +---+----+<----+ | 455 | | | | | 456 | | | | | 457 receive| | receive send retry 458 error RESP,| 200 OK CONF expires 459 retry | | | | | 460 expired| | | | | 461 | | | | | 462 | | v | | 463 | | +------+ | | 464 | +-------+ IN | | | 465 | | CALL +------+ | 466 | +--+---+ | 467 | | | 468 | | | 469 | | | 470 | | | 471 | connection | 472 | closed | 473 | | | 474 | | | 475 | | | 476 | | | 477 | | | 478 | v | 479 | +----------+<---------------------------------+ 480 +----------->+TERMINATED| 481 +----------+ 483 6. Media Provider's state machine 485 In the IDLE state, the MP is preparing the ADV message reflecting the 486 actual telepresence capabilities. After the ADV has been sent, the 487 MP moves to the WAIT FOR CONF state. 489 When in the WAIT FOR CONF state, the MP is listening to the channel 490 for a CONF coming from the MC. If a RE-ADV is received, the MP goes 491 back to the IDLE state and issues an ADV again. If telepresence 492 settings change in the meanwhile, it moves back to the IDLE state 493 too, and prepares a new ADV to be sent to the MC. If a CONF arrives, 494 the MP switches to the CONF RECEIVED state. If nothing happens and 495 the timeout expires, than the MC falls into the TIMEOUT state. 497 In the TIMEOUT state, if the number of trials does not exceed the 498 retry threshold, the MC comes back to the IDLE state for sending a 499 new ADV. Otherwise, it goes to the TERMINATED state. 501 The MP in the CONF RECEIVED state is processing the received CONF in 502 order to produce a RESPONSE message. If the MP is fine with the MC's 503 configuration, then it sends back a 200 OK successful RESPONSE and 504 moves to the IN CALL state. If there are errors duting CONF 505 processing, then the MC returns a RESPONSE carrying an error response 506 code. Finally, if there are changes in the telepresence settings, it 507 goes back to the IDLE state to issue an updated ADV. 509 When in the IN CALL state, the MP has successfully set up the 510 telepresence session according to the MC's specifications. If a new 511 CONF arrives, it switches to the CONF RECEIVED state to analyze the 512 new request. If a RE-ADV arrives, or some modifications are applied 513 to the telepresence options, then it moves to the IDLE state to issue 514 the ADV. When the channel is terminated, the MP falls into the 515 TERMINATED state. 517 The TERMINATED state is reachable from each of the aforementioned 518 states whenever the underlying channel is closed. The corresponding 519 transitions have not been reported for the sake of simplicity. This 520 termination condition is a temporary solution. 522 +------------------->+-----+-+<----------------------------+ 523 | +--------------->| IDLE |<-------------retry----------+---------+ 524 | | +------->+---+---+<----+ not | | 525 | | | | | expired | | 526 | | | | | | | 527 | | change send receive | ++------+ 528 | | telepresence ADV RE-ADV | |TIMEOUT| 529 | | settings | | | ++--+---+ 530 | | | | | | ^ | 531 | | | v | | | | 532 | | | +-------------+---+ | | | 533 | | +----+ WAIT FOR +------------timeout--------+---------+ | 534 | | | CONF | | | 535 change +-------+-----+<--+ | | 536 telepresence | | | | 537 settings | | | | 538 | | receive CONF error, | | 539 | | CONF retry not expired, | | 540 | | | send error RESP | | 541 | | | | | | 542 | | | | | | 543 | | v | | | 544 | | +-----------+---+ | | 545 +---+-------------+| CONF | | | 546 | +----->| RECEIVED |----CONF error, | | 547 | | +-----+-----+ retry expired | | 548 | | | | | | 549 | | | | | | 550 | | | | | | 551 receive receive send | | | 552 RE-ADV CONF 200 OK | | retry| 553 | | | | | expired 554 | | | | | | 555 | | | | | | 556 | | v | | | 557 | | +----------+ change | | 558 | +-------+ IN CALL +--------telepresence-------+ | 559 +---------------+----+-----+ settings | 560 | | | 561 | | | 562 | | | 563 | | | 564 connection | | 565 closed | | 566 | | | 567 | | | 568 v | | 569 +------------+<-----+-----------------------------+ 570 | TERMINATED | | 571 +------------+<-----+ 573 7. About CLUE protocol XML schema versioning 575 CLUE protocol messages are XML messages compliant to the CLUE 576 protocol XML schema. The version of the protocol corresponds to the 577 version of the schema. Both client and server have to test the 578 compliance of the received messages with the XML schema of the CLUE 579 protocol. If the compliance is not verified, the message cannot be 580 processed. 582 Obviously, client and server can not communicate if they do not share 583 exactly the same XML schema. Such a schema is the one included in 584 the yet to come RFC, and associated with the CLUE URN 585 "urn:ietf:params:xml:ns:clue-message". If all CLUE-enabled devices 586 use that schema there will be no interoperability problems due to 587 schema issues. 589 The version of the XML schema contained in the standard document 590 deriving from this draft will be 1.0. The subsequet versions of the 591 XML schema should be backward compatible. This means that they 592 should define further features and functionality besides those 593 defined in the previous versions, in an incremental way, without 594 impacting the basic rules defined in the previous version of the 595 schema. In this way, if a MP is able to speak, e.g., version 5.0 of 596 the protocol while the MC only understands version 4.0, the MP should 597 have no problem in reverting the dialogue to version 4.0 without 598 exploiting 5.0 features and functionality. 600 It is expected that, before the CLUE protocol XML schema reaches a 601 steady state, prototypes developed by different organizations will 602 conduct interoperability testing. In that case, in order to 603 interoperate, they have to be compliant to the current version of the 604 XML schema, i.e., the one copied in the most up-to-date version of 605 the draft defining the CLUE protocol. The versions of the non- 606 standard XML schema will be numbered as 0.01, 0.02, and so on. 607 During the standard development phase, the versions of the XML schema 608 will probably not be backward compatible so it is left to prototype 609 implementers the responsibility of keeping their products up to date. 611 Even though strongly discouraged, if a future version of the protocol 612 is designed which breaks the backward compatibility constraint, this 613 ascpect MUST be explicitely advertised in the corresponding new RFC 614 document. In such a case, it would up to developers to update their 615 systems accordingly. 617 8. Extensibility issues 619 Although the standard version of the CLUE protocol XML schema will be 620 designed to thoroughly cope with the requirements emerging from the 621 application domain, new needs might arise in the future. Such needs 622 may relate to two main aspects of the protocol: 624 the information carried in the existing messages (for example, we 625 may want to add more fields within an existing message); 627 the meaning of the messages. This is the case if there is no 628 proper message for a certain task, so a brand new CLUE message 629 needs to be defined. 631 8.1. Aspect 1 - new information within existing messages 633 CLUE messages are envelopes carrying two types of information: 635 XML elements defined within the CLUE protocol XML schema itself 636 (protocol-specific information) 638 other XML elements compliant to the CLUE data model schema (data 639 model information) 641 When new protocol-specific information is needed somewhere in the 642 protocol messages, it can be added in place of the elements and 643 elements envisioned by the protocol schema. The 644 policy currently defined in the protocol schema for handling 645 and elements is: 647 elementFormDefault="qualified" 649 attributeFormDefault="unqualified" 651 In that case, the new information must be qualified by namespaces 652 other than "urn:ietf:params:xml:ns:clue-message" (the protocol URN) 653 and "urn:ietf:params:xml:ns:clue-info" (the data model URN). 654 Elements or attributes from unknown namespaces MUST be ignored. 656 The other matter concerns data model information. Data model 657 information is defined by the XML schema associated with the URN 658 "urn:ietf:params:xml:ns:clue-info". Also for the XML elements 659 defined in such a schema there are extensibility issues. Those 660 issues are overcome by using and placeholders. 661 Similarly to what said before, new information within data model 662 elements can be added in place of and schema 663 elements, as long as they are properly namespace qualified. If brand 664 new data model elements are needed, then there are three options: 666 1. writing down a new version of the data model schema, with the new 667 elements added after the existing ones. This is a possible 668 solution. However, we must state that telepresence applications 669 are forced to check the version attribute of the schema they use. 671 2. putting all the new elements inside a brand new schema to be 672 linked to a new URN that the most up to date telepresence system 673 must be aware of. 675 3. designing a wildcard envelope for future data model elements. 677 8.2. Aspect 2 - new messages 679 New CLUE protocol messages, not envisioned in the standard version of 680 the schema, are needed. Also in that case we have three chances: 682 writing down a new version of the protocol schema, with the new 683 messages added after the existing ones. The same considerations 684 of the first option above hold here. 686 putting all the new messages inside a brand new schema to be 687 linked to a new URN that the most up to date telepresence system 688 must be aware of. [Editors' note: we strongly dislike this 689 option!!] 691 designing a wildcard envelope for future messages. This is an 692 approach used also within the CCMP protocol (Centralized 693 Conferencing Manipulation Protocol, [RFC6503]). In that case, a 694 mechanism for the extension negotiation is also envisioned. 696 9. Managing protocol version negotiation and extensions: the OPTIONS 697 request 699 In this section we provide a mechanism for handling protocol 700 extension matters as those pointed out in the previous section, as 701 well as version negotiation issues. 703 We propose a new request message issued by the MC to the MP as soon 704 as the CLUE channel is instatiated: the OPTIONS request. This 705 message carries: 707 the CLUE protocol version spoken by the MC 709 the data model extensions supported by the MC 711 the protocol extensions supported by the MC 713 When the MP receives the OPTIONS message, it reads the CLUE protocol 714 version of the MC (the highest protocol version of the MC). If the 715 MC's version is higher than the MP's one, then the MP responds to the 716 MC by using in the RESPONSE message its version. The MC has to 717 downgrade the CLUE dialogue to the version specified by the MP in the 718 subsequent CLUE messages. If the MC's version is equal to (case i) 719 or lower than (case ii) the MP version, then the MP will use in the 720 RESPONSE message the same version as the one in hthe OPTIONS message 721 and all subsequent CLUE messages must carry that version number. In 722 the (ii) case, it is the MP who has to to downgrade the CLUE dialogue 723 in order to be understood by the MC. 725 A data model extension is a set of XML definitions related to the 726 description of telepresence capabilities that is contained in an XML 727 schema and which is different from the normative CLUE data model 728 schema. Such XML definitions can represent further entities not 729 envisioned in the CLUE framework at the time of writing of the data 730 model draft. The entities defined in a data model extension can 731 appear in place of the and elements included in 732 the data model document. A data model extension is then represented 733 by a reference to the defining XML schema. The schema reference is 734 represented by a URI defining the schema location. [TBC] If a data 735 model extension is supported by both a MP and a MC, it means that 736 both are aware of the associated XML schema and of the meanings of 737 the elements defined within it. 739 A protocol extension is a set of XML definitions related to the CLUE 740 protocol that is contained in an XML schema which is different from 741 the normative CLUE protocol schema. Such definitions can represent: 742 (i) information to be carried within the existing messages in place 743 of and elements; (ii) new messages designed for 744 the CLUE telepresence control. Such XML definitions refer to 745 information not envisioned during the CLUE protocol design phase. A 746 protocol extension is then represented by a reference to the defining 747 XML schema. If a protocol extension is supported by both a MP and a 748 MC, it means that both are aware of the associated XML schema and of 749 the meanings of the elements defined within it. 751 When the MP receives the MC's OPTIONS message, it selects the data 752 model extensions and the protocol extensions that it is able to 753 support, and then provides them into the RESPONSE message back to the 754 MC. Only the extensions included in the RESPONSE message can be used 755 during the telepresence session. 757 The XML schema definition of the OPTIONS message is provided in the 758 following. 760 761 762 763 764 765 766 767 769 770 771 772 774 775 777 778 779 780 782 783 785 786 787 788 789 790 792 9.1. An example using OPTIONS 794 An example of OPTIONS dialogue is provided in the following. 796 +------+ +------+ 797 | MP | | MC | 798 | | | | 799 +--+---+ +--+---+ 800 | | 801 | OPTIONS 3.0 | 802 | dm-ext: s1, s2, s3 | 803 | pr-ext: s4, s5 | 804 |<--------------------+| 805 | | 806 | RESPONSE 1.0 | 807 | dm-ext: s1 | 808 | pr-ext: - | 809 |+-------------------->| 810 | | 811 | | 812 | ADV 1.0 | 813 |+-------------------->| 814 | | 815 | CONFIGURE 1.0 | 816 |<--------------------+| 817 | | 818 | | 819 v v 821 When the CLUE channel is ready, the MC issues an OPTIONS request to 822 the MP. The MC uses the 3.0 version of the CLUE protocol, and 823 supports schemas s1, s2, s3 as data model extensions and schemas s4, 824 s5 as protocol extensions. 826 The MP speaks the 1.0 version of the CLUE protocol and supports only 827 the first data model extension among those indicated by the MC. It 828 then issues a v. 1.0 RESPONSE to the MC copying only the supported 829 option. The MC is able to understand that it can use only the 1.0 830 version of the protocol and the s1 extension. 832 10. XML Schema of CLUE protocol messages 834 In this section we paste the XML schema defining the ADVERTISEMENT, 835 CONFIGURE and RESPONSE messages contained in 836 [I-D.kyzivat-clue-signaling]. At the time of writing, it assumes 837 that encodings are described in SDP as m-lines with a text 838 identifier, and that the identifier has the same value as the 839 encodingIDs embedded in the . However, that 840 assumption is still under discussion in the context of the CLUE-SDP 841 coupling issues. 843 844 854 855 858 859 860 861 862 863 865 866 867 868 869 870 871 873 874 875 876 877 878 879 880 881 882 883 885 886 887 888 889 890 891 892 894 895 896 897 899 900 902 903 904 905 907 908 910 911 912 913 914 915 917 918 919 920 921 922 923 924 925 926 928 929 930 931 932 933 934 935 936 937 939 940 941 942 944 945 946 947 948 949 950 951 952 953 954 956 957 958 959 960 961 962 963 965 967 969 971 972 974 976 977 978 979 981 982 983 984 985 986 987 988 989 991 993 994 995 996 998 999 1000 1001 1002 1003 1004 1005 1007 1009 11. Examples 1011 TBD 1013 12. Handling channel errors 1015 TBD 1017 13. Diff with the -01 version 1019 XML Schema moved here from [I-D.kyzivat-clue-signaling] 1021 advNumber introduced to couple a configure with an advertisement 1022 message 1024 added introductory text 1026 added a version and extension negotiation proposal 1028 14. Diff with -00 version 1030 MC and MP state diagrams have been updated for discussion in 1031 http://www.ietf.org/mail-archive/web/clue/current/msg02650.html 1033 Consideration about protocol extension and versioning have been 1034 added to foster discussion. 1036 15. Informative References 1038 [I-D.ietf-clue-data-model-schema] Presta, R. and S. Romano, 1039 "An XML Schema for the 1040 CLUE data model", draft- 1041 ietf-clue-data-model- 1042 schema-00 (work in 1043 progress), July 2013. 1045 [I-D.ietf-clue-framework] Duckworth, M., Pepperell, 1046 A., and S. Wenger, 1047 "Framework for 1048 Telepresence Multi- 1049 Streams", draft-ietf-clue- 1050 framework-11 (work in 1051 progress), July 2013. 1053 [I-D.ietf-clue-telepresence-requirements] Romanow, A., Botzko, S., 1054 and M. Barnes, 1055 "Requirements for 1056 Telepresence Multi- 1057 Streams", draft-ietf-clue- 1058 telepresence-requirements- 1059 05 (work in progress), 1060 August 2013. 1062 [I-D.kyzivat-clue-signaling] Kyzivat, P., Xiao, L., 1063 Groves, C., and R. Hansen, 1064 "CLUE Signaling", draft- 1065 kyzivat-clue-signaling-05 1066 (work in progress), 1067 September 2013. 1069 [RFC5261] Urpalainen, J., "An 1070 Extensible Markup Language 1071 (XML) Patch Operations 1072 Framework Utilizing XML 1073 Path Language (XPath) 1074 Selectors", RFC 5261, 1075 September 2008. 1077 [RFC6502] Camarillo, G., Srinivasan, 1078 S., Even, R., and J. 1079 Urpalainen, "Conference 1080 Event Package Data Format 1081 Extension for Centralized 1082 Conferencing (XCON)", 1083 RFC 6502, March 2012. 1085 [RFC6503] Barnes, M., Boulton, C., 1086 Romano, S., and H. 1087 Schulzrinne, "Centralized 1088 Conferencing Manipulation 1089 Protocol", RFC 6503, 1090 March 2012. 1092 Authors' Addresses 1094 Roberta Presta 1095 University of Napoli 1096 Via Claudio 21 1097 Napoli 80125 1098 Italy 1100 EMail: roberta.presta@unina.it 1102 Simon Pietro Romano 1103 University of Napoli 1104 Via Claudio 21 1105 Napoli 80125 1106 Italy 1108 EMail: spromano@unina.it