idnits 2.17.1 draft-levin-xcon-cccp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2299. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 45 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 30, 2005) is 6692 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) -- Looks like a reference, but probably isn't: 'TBD' on line 336 == Unused Reference: '3' is defined on line 2232, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2239, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '3' -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-11) exists of draft-ietf-xcon-framework-01 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group O. Levin 3 Internet-Draft Microsoft Corporation 4 Expires: July 3, 2006 R. Even 5 Polycom 6 P. Hagendorf 7 RADVISION 8 December 30, 2005 10 Centralized Conference Control Protocol 11 draft-levin-xcon-cccp-04 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 3, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document defines a Centralized Conferencing Control Protocol 45 (CCCP) as a part of the XCON Working Group protocols suite. CCCP 46 uses a client-server model for creation, querying, and manipulation 47 of XCON entities, conference objects and sub-objects. An XCON 48 entity, which implements a CCCP server, provides a means for 49 authorized CCCP clients (e.g. conference participants) to affect the 50 behavior of a conference in the XCON system. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Transaction Model . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Multiple Primitives in a Single Operation . . . . . . . . 6 60 4.3. Response Codes and Failures . . . . . . . . . . . . . . . 6 61 5. Using the Data Model . . . . . . . . . . . . . . . . . . . . . 6 62 6. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Remote Procedure vs. Data Manipulation . . . . . . . . . . 7 64 6.2. CCCP Transactions vs. SOAP . . . . . . . . . . . . . . . . 8 65 7. Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. System Primitives . . . . . . . . . . . . . . . . . . . . 9 67 7.1.1. Cancel . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1.3. getTemplates . . . . . . . . . . . . . . . . . . . . . 11 70 7.1.4. getActiveConferences . . . . . . . . . . . . . . . . . 11 71 7.2. Conference Primitives . . . . . . . . . . . . . . . . . . 11 72 7.2.1. addConference . . . . . . . . . . . . . . . . . . . . 11 73 7.2.2. modifyConference . . . . . . . . . . . . . . . . . . . 13 74 7.2.3. deleteConference . . . . . . . . . . . . . . . . . . . 14 75 7.2.4. getConference . . . . . . . . . . . . . . . . . . . . 15 76 7.3. User Primitives . . . . . . . . . . . . . . . . . . . . . 16 77 7.3.1. addUser . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.3.2. modifyUser . . . . . . . . . . . . . . . . . . . . . . 17 79 7.3.3. modifyUserRoles . . . . . . . . . . . . . . . . . . . 18 80 7.3.4. deleteUser . . . . . . . . . . . . . . . . . . . . . . 19 81 7.3.5. getUser . . . . . . . . . . . . . . . . . . . . . . . 20 82 7.4. Endpoint Primitives . . . . . . . . . . . . . . . . . . . 21 83 7.4.1. addEndpoint . . . . . . . . . . . . . . . . . . . . . 21 84 7.4.2. modifyEndpoint . . . . . . . . . . . . . . . . . . . . 22 85 7.4.3. deleteEndpoint . . . . . . . . . . . . . . . . . . . . 23 86 7.4.4. getEndpoint . . . . . . . . . . . . . . . . . . . . . 24 87 7.5. Endpoint Media Primitives . . . . . . . . . . . . . . . . 25 88 7.5.1. addEndpointMedia . . . . . . . . . . . . . . . . . . . 26 89 7.5.2. modifyEndpointMedia . . . . . . . . . . . . . . . . . 26 90 7.5.3. deleteEndpointMedia . . . . . . . . . . . . . . . . . 27 91 7.5.4. getEndpointMedia . . . . . . . . . . . . . . . . . . . 28 92 7.6. Sidebar Primitives . . . . . . . . . . . . . . . . . . . . 29 93 7.6.1. addSidebar . . . . . . . . . . . . . . . . . . . . . . 29 94 7.6.2. modifySidebar . . . . . . . . . . . . . . . . . . . . 30 95 7.6.3. deleteSidebar . . . . . . . . . . . . . . . . . . . . 30 96 7.6.4. addUserToSidebar . . . . . . . . . . . . . . . . . . . 30 97 7.6.5. deleteUserFromSidebar . . . . . . . . . . . . . . . . 30 98 7.6.6. moveUserBetweenSidebars . . . . . . . . . . . . . . . 30 99 7.7. Stimulus Primitives . . . . . . . . . . . . . . . . . . . 30 100 8. The XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 30 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 102 9.1. URN Sub-Namespace Registration for 103 urn:ietf:params:xml:ns:cccp . . . . . . . . . . . . . . . 49 104 9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 50 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 106 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 108 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 109 12.2. Informative References . . . . . . . . . . . . . . . . . . 51 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 111 Intellectual Property and Copyright Statements . . . . . . . . . . 53 113 1. Introduction 115 The SIPPING Conference Framework [6] describes a general centralized 116 conferencing architecture. The XCON Framework [7] defines how this 117 architecture can be realized by an XCON compliant system. This 118 document defines a Centralized Conferencing Control Protocol (CCCP) 119 as a conference control protocol in the XCON protocols suite 120 described in XCON Framework [7] 122 CCCP uses a client-server model for creation, querying, and 123 manipulation of XCON entities, conference objects and sub-objects. 124 By implementing a CCCP server, an XCON entity provides a means for 125 authorized CCCP clients (e.g. conference participants) to affect the 126 behavior of a conference in the XCON system. CCCP is a semantic- 127 oriented protocol, which uses the XML types defined in the SIPPING 128 Conference Package [2] for the representation of the conference 129 object and its sub-objects . In future, the CCCP can be extended to 130 include manipulations on additional conferencing objects being 131 represented by XML schemas such as policies and templates. 133 2. Terminology 135 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 136 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 137 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 138 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 139 compliant implementations. 141 3. Transport 143 The protocol design assumes that CCCP runs on a reliable transport 144 protocol. 146 CCCP is agnostic to the details of the transport protocol being used 147 beneath and does not rely on any information being conveyed on the 148 transport level. This model allows for using different transport 149 protocols based on the system requirements and also for multiplexing 150 otherwise independent CCCP communications over a common transport 151 channel. 153 4. The Protocol 155 4.1. Transaction Model 157 CCCP is a client-server protocol. The protocol defines two 158 operations: request and response. 160 A client issues requests to a server. The server MUST reply with a 161 single final response. Two final responses are defined: "failure" 162 and "success". 164 Before issuing the final response, the server MAY reply with multiple 165 provisional responses. Currently a single provisional response 166 "pending" is defined. 168 Editor's Note: Timeouts TBD. 170 A CCCP request carries the following attributes: 172 +------------+------------------------------------------------------+ 173 | Attribute | Description | 174 +------------+------------------------------------------------------+ 175 | requestId | A unique string generated by the CCCP client across | 176 | | all its requests. | 177 | from | A transport URI which identifies the CCCP client. | 178 | to | A transport URI which identifies the CCCP server. | 179 | originator | A trusted ID of the originator of the request. | 180 +------------+------------------------------------------------------+ 182 Table 1 184 The combination of the 'requestId', 'to', and 'from' attributes in 185 the request constitutes the CCCP transaction ID. 187 A CCCP response carries the following attributes: 189 +------------+------------------------------------------------------+ 190 | Attribute | Description | 191 +------------+------------------------------------------------------+ 192 | requestId | The original request ID generated by the client and | 193 | | echoed as is by the server. | 194 | from | A transport URI which identifies the CCCP server. | 195 | to | A transport URI which identifies the CCCP client. | 196 | code | The general response code: success, pending, or | 197 | | failure. | 198 | reason | The general CCCP failure reason. | 199 | timeout | The updated timeout used with pending responses | 200 | | (details TBD). | 201 | retryAfter | The suggested delay used with serverBusy responses. | 202 +------------+------------------------------------------------------+ 204 Table 2 206 4.2. Multiple Primitives in a Single Operation 208 A CCCP operation (i.e. a request and a corresponding response) MAY 209 contain multiple primitives. The CCCP MUST process the received 210 primitives one-by-one in the order they appear in the request body. 211 If the request contains multiple primitives, the corresponding 212 response operation MUST contain the response primitive for each and 213 in the same order as in the request. 215 Multiple primitives within the same request MUST be executed as an 216 atomic operation. This means that if one primitive fails, the state 217 of the object MUST be rolled back to its state before processing the 218 request. 220 If a CCCP server is not willing to process a multi-primitive request, 221 it MUST fail the transaction with the response code "notSupported". 223 4.3. Response Codes and Failures 225 CCCP defines the following reasons for failure of a request operation 227 +------------------+------------------------------------------------+ 228 | Failure | Description | 229 +------------------+------------------------------------------------+ 230 | serverBusy | Optional retryAfter can be included in the | 231 | | response. | 232 | timeout | Operation took too long and was aborted by the | 233 | | server | 234 | unauthorized | Client is not authorized to perform the | 235 | | operation. | 236 | requestMalformed | The XML document in the request is either not | 237 | | well-formed or not compliant with the schema. | 238 | requestTooLarge | Result of the request operation length check. | 239 | requestCancelled | The pending request was canceled by CCCP. | 240 | notSupported | One of the primitives or their combination is | 241 | | not supported by the server. | 242 | otherFailure | Result of any other server fault condition. | 243 +------------------+------------------------------------------------+ 245 Table 3 247 Most CCCP primitives define their own optional response codes. This 248 allows communicating the detailed primitive result in addition to the 249 CCCP general response code. 251 5. Using the Data Model 252 The CCCP operations are applied to the data objects expressed in 253 terms of SIPPING Conference Package [2] XML types whenever possible. 254 The considerations listed below MUST be taken into account when using 255 the schema with CCCP. 257 The information included in the request expresses the desired data 258 object state to be achieved after the operation is successfully 259 completed. By definition, the CCCP primitives allow for inclusion of 260 any information that can be expressed in terms of the conference-type 261 and its sub-types. 263 Attributes 'state' and 'version' of the conference-type and its sub- 264 types are never used with CCCP. The information in the response is 265 provided as a feedback to the request only and typically does not 266 carry the full state of the object. 268 For each primitive request, the CCCP explicitly defines (see Section 269 6) what information (i.e. attributes and elements) MUST be provided 270 by the client and what information (when provided by the client) MUST 271 NOT be ignored by the server. The rest of the information included 272 by the client MAY be treated as optional by the server. 274 For each primitive response, the CCCP explicitly defines (see Section 275 6) what information (i.e. attributes and elements) if included by the 276 server MUST NOT be ignored by the client. The rest of the 277 information included by the client MAY be treated as optional by the 278 server. If neither mandatory information nor new data is generated, 279 the server MAY return minimum schema compliant construct, such as an 280 element with empty body and the attributes identifying the 281 corresponding request only. On the other hand, the CCCP server MAY 282 include any rich dynamically generated information to the client (for 283 example, to be displayed to a user or be logged in by the system) in 284 the response. The client MAY ignore any information received in the 285 response, unless stated otherwise in Section 6. 287 6. Design Rationale 289 6.1. Remote Procedure vs. Data Manipulation 291 The first step in the decision process was to compare between a data 292 manipulation approach and a remote procedure call approach. 294 The advantages of the data manipulation approach are: 295 o Mostly appropriate for simple lightweight clients using built on a 296 stimulus-response model 298 o The data model is the protocol -- any existing generic data 299 manipulation protocol will work 300 o Adding functionality does not require changes to the protocol, 301 only to the data model. The server implementation needs to track 302 these changes of course and implement the corresponding new 303 functionality. 305 The advantages for the remote procedure call approach are: 306 o Mostly appropriate for conferencing-aware client applications that 307 are built to automate the experience and/or hide conferencing 308 complexity from the end user 309 o Makes compound operations and conference specific operations 310 explicit and thus much easier and faster for conferencing server 311 implementation 312 o Allows for inclusion of data manipulation primitives when desired, 313 e.g. for manipulating templates. In other words, a hybrid 314 approach is easily built where it makes sense. 316 We came to a conclusion that there is a place for both approaches to 317 co-exist in the industry. The decision of which to use in each case 318 will be based on the client side requirements. 320 We also came to a conclusion that it is not necessary to define a new 321 conference-specific protocol in order to meet the lightweight client 322 requirements for a stimulus-response approach. Instead one of the 323 existing standard data manipulation protocols can be used for this 324 purpose. This approach will require standardizing the user interface 325 in terms of a standard conferencing XML schema(s). 327 On the other hand, smart conference-aware conferencing clients cannot 328 operate using abstract stimulus-response approach only. In order to 329 achieve both efficient and flexible conference control, a truly 330 application-specific, i.e. a conferencing control protocol, is 331 needed. The CCCP is defined with this need in mind. 333 6.2. CCCP Transactions vs. SOAP 335 It is not difficult to map the CCCP primitives and functionality into 336 a SOAP compliant protocol as shown in [TBD]. Apart from the pure 337 syntax differences, the two protocols differ in the way they report 338 the final result of a requested operation. 340 According to the SOAP specification, each transaction is comprised of 341 a request and a single corresponding response (which are transported 342 over the underlying HTTP transaction). This definition means that an 343 application that uses SOAP needs to define its own conventions for 344 handling requests that can not be completed immediately. Typically 345 this is being achieved by introducing an additional notification 346 channel in the direction opposite to the request. It is important to 347 note that this channel must not be mistaken with the conference state 348 notification channel defined in [conf package]. 350 The conference control notification channel should be provided to the 351 client originating the request only and would not necessarily reflect 352 any changes in the conference state. For example, in case a request 353 transaction is completed with the "in progress" response and later a 354 server fails to execute the request, the notification sent to the 355 client will not convey any change in the conference state, but rather 356 needs to convey the request ID and the failure reason. 358 CCCP is different at that sense from the SOAP architecture. CCCP 359 does not use any dedicated notification channel. Instead CCCP has 360 the notion of possible multiple pending responses always followed by 361 the final (either success or failure) response. This approach 362 simplifies the conferencing application and also makes CCCP truly 363 independent from the underlying transport protocol. 365 It is important to note that a CCCP client is expected to support the 366 Conference State event package as the means for maintaining the most 367 current synchronized conference state. The client should not use the 368 CCCP responses for updating the local copy of the conference state 369 document. 371 7. Primitives 373 This section describes the defined CCCP primitives and includes valid 374 XML document examples for each. The corresponding CCCP XML schema is 375 provided in Section 7. 377 7.1. System Primitives 379 7.1.1. Cancel 381 Cancel a pending request. 383 This primitive can be issued by a client to cancel a pending 384 transaction. The primitive is an independent transaction on its own. 385 The body of the primitive MUST carry the requestId of one of the 386 pending requests. 388 397 398 5 399 400 402 Note that a valid response can contain an empty body. 404 414 415 417 7.1.2. Ping 419 Ping a CCCP Server. 421 430 431 433 A successful response is shown below. 435 445 446 448 7.1.3. getTemplates 450 Get the list of templates supported by the system. XML TBD. 452 7.1.4. getActiveConferences 454 Get the list of conference identifiers for active conference objects 455 in the system. 457 XML TBD. 459 7.2. Conference Primitives 461 7.2.1. addConference 463 Create a conference. 465 The 'conferenceEntity' value in the request is a client's suggestion 466 only. The CCCP server MAY replace the suggested value with a 467 different 'conferenceEntity' value in the corresponding response. 469 478 479 482 483 Design Review 484 485 486 tel:+1-8666119036 487 FFD bridge 488 489 490 491 492 https://company.com/ConfServer 493 494 495 496 497 audio 498 499 500 501 502 503 505 The CCCP server MAY replace the suggested 'conferenceEntity' with a 506 different value in the corresponding response. In the case of a 507 successful response, the CCCP client MUST use the new value and 508 SHOULD use all the new parameters allocated by the server to the 509 conference. 511 521 522 525 526 Design Review 527 528 529 tel:+1-8666119036 530 FFD bridge 531 532 533 534 535 https://company.com/ConfServer 536 537 538 539 540 audio 541 542 543 544 545 546 548 7.2.2. modifyConference 550 Modify conference parameters. 552 561 562 565 566 Spec Review 567 568 569 570 572 582 583 585 7.2.3. deleteConference 587 Remove conference from the system. 589 598 599 601 602 604 614 615 617 7.2.4. getConference 619 Retrieve the conference information. 621 630 631 633 634 635 645 646 649 650 Design Review 651 652 653 tel:+1-8666119036 654 FFD bridge 655 656 657 658 659 https://company.com/ConfServer 660 661 662 663 664 audio 665 666 667 668 669 670 672 7.3. User Primitives 674 7.3.1. addUser 676 The client MUST provide the 'userEntity' value in the request. 678 687 688 690 692 Bob Hoskins 693 694 presenter 695 696 697 698 700 710 711 713 7.3.2. modifyUser 715 Modify the user information. 717 726 727 729 731 Bob Hoskins III 732 733 734 tel:2562566 735 the description 736 optional tbd values 737 738 739 740 presenter 741 742 743 744 746 756 757 759 7.3.3. modifyUserRoles 761 This is a dedicated primitive to change user's roles. The same 762 effect can be achieved by using the modifyUser primitive. Note that 763 a CCCP server can choose to implement both approaches simultaneously 764 to be invoked by different clients. 766 Editor's Note: The dedicated primitive is defined to demonstrate that 767 both approaches are possible with CCCP. 769 778 779 782 784 presenter 785 786 787 789 799 800 802 7.3.4. deleteUser 804 Remove the user from the conference roster. 806 815 816 819 820 822 832 833 835 7.3.5. getUser 837 Retrieve the information about a conference participant. 839 848 849 852 854 856 866 867 868 870 Bob Hoskins III 871 872 873 tel:2562566 874 the description 875 optional tbd values 876 877 878 879 presenter 880 881 882 883 885 7.4. Endpoint Primitives 887 7.4.1. addEndpoint 889 Bring the specified user into a conference by establishing a call 890 (signaling and media) with him/her/it. 892 The endpoint 'entity' value MAY be replaced or augmented by the CCCP 893 server. The 'media-id' value MAY be replaced or augmented by the 894 CCCP server. If the server returns this information in the response, 895 the client MUST use the values provided by the server. 897 906 907 910 912 Bob's Laptop 913 dialed-out 914 915 main audio 916 audio 917 918 919 920 922 932 933 935 7.4.2. modifyEndpoint 937 Modify the call description or/and its behaivior. 939 948 949 952 954 Bob's Laptop 955 956 957 959 969 970 972 7.4.3. deleteEndpoint 974 Disconnect the call. 976 985 986 990 991 993 1003 1004 1006 7.4.4. getEndpoint 1008 Retrieve the information about the call. 1010 1019 1020 1024 1025 1027 1037 1038 1041 1043 Bob's Laptop 1044 dialed-out 1045 1046 main audio 1047 audio 1048 1049 1050 1051 1053 7.5. Endpoint Media Primitives 1054 7.5.1. addEndpointMedia 1056 Add the specified media stream to the call. 1058 The 'media-id' value MAY be replaced or augmented by the CCCP server. 1059 The CCCP client MUST use the new value if returned by the server in 1060 the response. 1062 1071 1072 1076 1078 main audio 1079 audio 1080 1081 1082 1084 1094 1095 1097 7.5.2. modifyEndpointMedia 1099 Modify the media behavior. This primitive can be used to mute and 1100 un-mute the call. 1102 1111 1112 1116 1118 audio 1119 recvonly 1120 1121 1122 1124 1134 1135 1137 7.5.3. deleteEndpointMedia 1139 Remove the specified media stream from the call. 1141 1150 1151 1156 1157 1159 1169 1170 1172 7.5.4. getEndpointMedia 1174 Retrieve the information about the specified stream in the call. 1176 1185 1186 1191 1192 1194 1204 1205 1209 1211 audio 1212 recvonly 1213 1214 1215 1217 7.6. Sidebar Primitives 1219 7.6.1. addSidebar 1221 Create a sidebar in the conference. 1223 XML TBD. 1225 7.6.2. modifySidebar 1227 Modify the sidebar parameters in the conference. 1229 XML TBD. 1231 7.6.3. deleteSidebar 1233 Remove the sidebar from the conference. 1235 XML TBD. 1237 7.6.4. addUserToSidebar 1239 Add the specified conference participant to the sidebar. 1241 XML TBD. 1243 7.6.5. deleteUserFromSidebar 1245 Remove the specified conference participant from the sidebar. 1247 XML TBD. 1249 7.6.6. moveUserBetweenSidebars 1251 Move the the specified conference participant from sidebar A to 1252 sidebar B. 1254 XML TBD. 1256 7.7. Stimulus Primitives 1258 This operation is used to convey opaque to the CCCP logic requests 1259 from a CCCP client to a CCCP server to be processed by applications 1260 above CCCP. 1262 XML TBD. 1264 8. The XML Schema 1266 1267 1277 1281 1285 1289 1293 1296 1298 1301 1303 1306 1307 1308 1309 1311 1313 1315 1317 1319 1321 1323 1325 1327 1329 1331 1333 1335 1337 1339 1341 1343 1345 1347 1350 1351 1352 1354 1357 1358 1361 1363 1367 1369 1370 1372 1375 1376 1377 1378 1380 1382 1384 1386 1388 1390 1392 1394 1396 1398 1400 1402 1404 1406 1408 1410 1412 1414 1416 1419 1420 1421 1423 1426 1428 1431 1433 1436 1438 1440 1442 1444 1446 1448 1449 1450 1453 1454 1455 1456 1457 1458 1459 1461 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1477 1480 1481 1482 1484 1486 1489 1490 1491 1492 1494 1496 1499 1500 1501 1502 1503 1505 1507 1511 1512 1513 1514 1515 1516 1518 1520 1523 1524 1525 1526 1528 1529 1531 1533 1536 1537 1538 1540 1542 1543 1545 1546 1548 1551 1552 1553 1554 1555 1556 1558 1561 1562 1563 1565 1566 1567 1569 1573 1574 1575 1577 1579 1580 1581 1583 1586 1587 1588 1589 1591 1592 1593 1595 1598 1599 1600 1601 1602 1603 1605 1606 1607 1609 1610 1612 1615 1616 1617 1618 1619 1620 1622 1625 1626 1627 1629 1631 1632 1633 1635 1638 1639 1640 1641 1642 1643 1645 1646 1647 1649 1650 1652 1656 1657 1658 1659 1660 1661 1663 1666 1667 1668 1670 1672 1673 1674 1676 1679 1680 1681 1682 1683 1684 1686 1687 1688 1691 1692 1694 1697 1698 1699 1700 1701 1702 1703 1706 1707 1708 1710 1711 1713 1714 1715 1717 1720 1721 1722 1724 1725 1727 1728 1730 1731 1733 1736 1737 1738 1739 1740 1741 1742 1744 1747 1748 1749 1752 1753 1755 1756 1757 1759 1762 1763 1764 1766 1767 1768 1769 1771 1772 1773 1775 1776 1778 1781 1782 1783 1785 1787 1788 1789 1791 1794 1795 1796 1798 1799 1800 1801 1803 1804 1805 1807 1809 1811 1814 1815 1816 1817 1818 1819 1820 1822 1825 1826 1827 1829 1831 1832 1833 1835 1838 1839 1840 1842 1843 1844 1845 1847 1849 1850 1852 1853 1855 1858 1859 1860 1861 1862 1863 1864 1866 1869 1870 1871 1873 1874 1875 1876 1878 1879 1880 1881 1883 1886 1887 1888 1890 1891 1892 1893 1895 1896 1897 1899 1900 1901 1904 1905 1906 1908 1910 1911 1912 1914 1917 1918 1919 1920 1921 1922 1923 1924 1926 1929 1930 1931 1933 1934 1935 1936 1938 1939 1940 1942 1943 1944 1947 1948 1949 1951 1953 1954 1955 1957 1960 1961 1962 1963 1964 1965 1966 1967 1969 1972 1973 1974 1976 1977 1978 1979 1981 1982 1983 1986 1987 1989 1993 1994 1995 1997 1998 2000 2001 2002 2004 2007 2008 2009 2011 2012 2013 2014 2016 2017 2018 2021 2022 2024 2027 2028 2029 2030 2031 2032 2033 2034 2035 2037 2040 2041 2042 2044 2047 2048 2049 2051 2054 2055 2056 2057 2058 2059 2060 2061 2062 2064 2067 2068 2069 2071 2072 2073 2074 2076 2077 2078 2080 2081 2083 2086 2087 2088 2090 2092 2093 2094 2096 2099 2100 2101 2103 2104 2105 2106 2108 2109 2110 2112 2113 2115 2118 2119 2120 2123 2125 2126 2127 2129 2130 2132 2135 2136 2137 2139 2140 2141 2143 2144 2145 2146 2148 2151 2152 2153 2154 2155 2156 2157 2158 2159 2161 Figure 39 2163 9. IANA Considerations 2165 This document registers a new XML namespace and a new XML schema. 2167 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cccp 2169 This section registers a new XML namespace, as per the guidelines in 2170 RFC 3688 [5]. 2172 URI: The URI for this namespace is urn:ietf:params:xml:ns:cccp 2173 Registrant Contact: IETF XCON Working Group , as 2174 designated by the IESG 2175 XML: 2177 BEGIN 2178 2179 2181 2182 2183 2185 Centralized Conference Information Namespace 2187 2189

Namespace for Centralized Conference Control Protocol

2190

urn:ietf:params:xml:ns:cccp

2191

See RFCXXXX.

2192 2193 2194 END 2196 9.2. XML Schema Registration 2198 This specification registers a schema, as per the guidelines in RFC 2199 3688 [5]. 2201 URI: please assign 2202 Registrant Contact: IETF XCON Working Group , as 2203 designated by the IESG 2204 XML: The XML can be found as the sole content of Section 7 2206 10. Security Considerations 2208 Manipulation of conference state and policy information through the 2209 conference control protocol require a strong means for 2210 authentication, conference information protection, and applying 2211 comprehensive authorization rules by a focus. Users of this 2212 specification MUST use encrypted transport means and comply with the 2213 security considerations discussed in the XCON Framework [7] and the 2214 SIP Event Package for Conference State [2] . 2216 11. Acknowledgements 2217 The author would like to thank Gur Kimchi for his earlier work that 2218 served as the starting point for this specification. 2220 12. References 2222 12.1. Normative References 2224 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2225 Levels", BCP 14, RFC 2119, March 1997. 2227 [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2228 Package for Conference State", 2229 draft-ietf-sipping-conference-package-12 (work in progress), 2230 July 2005. 2232 [3] Levin, O., "Extensions to the Session Initiation Protocol (SIP) 2233 Event Package for Conference State", 2234 draft-levin-xcon-conference-package-ext-00 (work in progress), 2235 October 2005. 2237 12.2. Informative References 2239 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2240 Notification", RFC 3265, June 2002. 2242 [5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2243 January 2004. 2245 [6] Rosenberg, J., "A Framework for Conferencing with the Session 2246 Initiation Protocol", 2247 draft-ietf-sipping-conferencing-framework-05 (work in progress), 2248 May 2005. 2250 [7] Barnes, M., "A Framework and Data Model for Centralized 2251 Conferencing", draft-ietf-xcon-framework-01 (work in progress), 2252 July 2005. 2254 Authors' Addresses 2256 Orit Levin 2257 Microsoft Corporation 2258 One Microsoft Way 2259 Redmond, WA 98052, USA 2261 Email: oritl@microsoft.com 2263 Roni Even 2264 Polycom 2265 94 Derech Em Hamoshavot 2266 Petach Tikva, 49130, Israel 2268 Email: roni.even@polycom.co.il 2270 Pierre Hagendorf 2271 RADVISION 2272 24, Raul Wallenberg St. 2273 Tel-Aviv, 69719, Israel 2275 Email: pierre@radvision.com 2277 Intellectual Property Statement 2279 The IETF takes no position regarding the validity or scope of any 2280 Intellectual Property Rights or other rights that might be claimed to 2281 pertain to the implementation or use of the technology described in 2282 this document or the extent to which any license under such rights 2283 might or might not be available; nor does it represent that it has 2284 made any independent effort to identify any such rights. Information 2285 on the procedures with respect to rights in RFC documents can be 2286 found in BCP 78 and BCP 79. 2288 Copies of IPR disclosures made to the IETF Secretariat and any 2289 assurances of licenses to be made available, or the result of an 2290 attempt made to obtain a general license or permission for the use of 2291 such proprietary rights by implementers or users of this 2292 specification can be obtained from the IETF on-line IPR repository at 2293 http://www.ietf.org/ipr. 2295 The IETF invites any interested party to bring to its attention any 2296 copyrights, patents or patent applications, or other proprietary 2297 rights that may cover technology that may be required to implement 2298 this standard. Please address the information to the IETF at 2299 ietf-ipr@ietf.org. 2301 Disclaimer of Validity 2303 This document and the information contained herein are provided on an 2304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2311 Copyright Statement 2313 Copyright (C) The Internet Society (2005). This document is subject 2314 to the rights, licenses and restrictions contained in BCP 78, and 2315 except as set forth therein, the authors retain all their rights. 2317 Acknowledgment 2319 Funding for the RFC Editor function is currently provided by the 2320 Internet Society.