idnits 2.17.1 draft-levin-xcon-cccp-03.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 2210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2187. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2200. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 24, 2005) is 6730 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) == Unused Reference: '3' is defined on line 2130, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2137, 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: 3 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON O. Levin 3 Internet-Draft Microsoft Corporation 4 Expires: April 27, 2006 R. Even 5 Polycom 6 P. Hagendorf 7 RADVISION 8 October 24, 2005 10 Centralized Conference Control Protocol (CCCP) 11 draft-levin-xcon-cccp-03 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 April 27, 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 . . . . . . . . 5 60 4.3. Response Codes and Failures . . . . . . . . . . . . . . . 6 61 5. Using the Data Model . . . . . . . . . . . . . . . . . . . . . 6 62 6. Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. System Primitives . . . . . . . . . . . . . . . . . . . . 7 64 6.1.1. Cancel . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.1.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1.3. getTemplates . . . . . . . . . . . . . . . . . . . . . 8 67 6.1.4. getActiveConferences . . . . . . . . . . . . . . . . . 9 68 6.2. Conference Primitives . . . . . . . . . . . . . . . . . . 9 69 6.2.1. addConference . . . . . . . . . . . . . . . . . . . . 9 70 6.2.2. modifyConference . . . . . . . . . . . . . . . . . . . 11 71 6.2.3. deleteConference . . . . . . . . . . . . . . . . . . . 12 72 6.2.4. getConference . . . . . . . . . . . . . . . . . . . . 13 73 6.3. User Primitives . . . . . . . . . . . . . . . . . . . . . 14 74 6.3.1. addUser . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.3.2. modifyUser . . . . . . . . . . . . . . . . . . . . . . 15 76 6.3.3. modifyUserRoles . . . . . . . . . . . . . . . . . . . 16 77 6.3.4. deleteUser . . . . . . . . . . . . . . . . . . . . . . 17 78 6.3.5. getUser . . . . . . . . . . . . . . . . . . . . . . . 18 79 6.4. Endpoint Primitives . . . . . . . . . . . . . . . . . . . 19 80 6.4.1. addEndpoint . . . . . . . . . . . . . . . . . . . . . 19 81 6.4.2. modifyEndpoint . . . . . . . . . . . . . . . . . . . . 20 82 6.4.3. deleteEndpoint . . . . . . . . . . . . . . . . . . . . 21 83 6.4.4. getEndpoint . . . . . . . . . . . . . . . . . . . . . 22 84 6.5. Endpoint Media Primitives . . . . . . . . . . . . . . . . 24 85 6.5.1. addEndpointMedia . . . . . . . . . . . . . . . . . . . 24 86 6.5.2. modifyEndpointMedia . . . . . . . . . . . . . . . . . 25 87 6.5.3. deleteEndpointMedia . . . . . . . . . . . . . . . . . 25 88 6.5.4. getEndpointMedia . . . . . . . . . . . . . . . . . . . 26 89 6.6. Sidebar Primitives . . . . . . . . . . . . . . . . . . . . 27 90 6.6.1. addSidebar . . . . . . . . . . . . . . . . . . . . . . 27 91 6.6.2. modifySidebar . . . . . . . . . . . . . . . . . . . . 28 92 6.6.3. deleteSidebar . . . . . . . . . . . . . . . . . . . . 28 93 6.6.4. addUserToSidebar . . . . . . . . . . . . . . . . . . . 28 94 6.6.5. deleteUserFromSidebar . . . . . . . . . . . . . . . . 28 95 6.6.6. moveUserBetweenSidebars . . . . . . . . . . . . . . . 28 97 6.7. Stimulus Primitives . . . . . . . . . . . . . . . . . . . 28 98 7. The XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 28 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 100 8.1. URN Sub-Namespace Registration for 101 urn:ietf:params:xml:ns:cccp . . . . . . . . . . . . . . . 47 102 8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 48 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 104 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 106 11.1. Normative References . . . . . . . . . . . . . . . . . . . 49 107 11.2. Informative References . . . . . . . . . . . . . . . . . . 49 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 109 Intellectual Property and Copyright Statements . . . . . . . . . . 51 111 1. Introduction 113 The SIPPING Conference Framework [6] describes a general centralized 114 conferencing architecture. The XCON Framework [7] defines how this 115 architecture can be realized by an XCON compliant system. This 116 document defines a Centralized Conferencing Control Protocol (CCCP) 117 as a conference control protocol in the XCON protocols suite 118 described in XCON Framework [7]. 120 CCCP uses a client-server model for creation, querying, and 121 manipulation of XCON entities, conference objects and sub-objects. 122 By implementing a CCCP server, an XCON entity provides a means for 123 authorized CCCP clients (e.g. conference participants) to affect the 124 behavior of a conference in the XCON system. CCCP is a semantic- 125 oriented protocol, which uses the XML types defined in the SIPPING 126 Conference Package [2] for the representation of the conference 127 object and its sub-objects . In future, the CCCP can be extended to 128 include manipulations on additional conferencing objects being 129 represented by XML schemas such as policies and templates. 131 2. Terminology 133 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 134 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 135 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 136 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 137 compliant implementations. 139 3. Transport 141 The protocol design assumes that CCCP runs on a reliable transport 142 protocol. 144 CCCP is agnostic to the details of the transport protocol being used 145 beneath and does not rely on any information being conveyed on the 146 transport level. This model allows for using different transport 147 protocols based on the system requirements and also for multiplexing 148 otherwise independent CCCP communications over a common transport 149 channel. 151 4. The Protocol 153 4.1. Transaction Model 155 CCCP is a client-server protocol. The protocol defines two 156 operations: request and response. 158 A client issues requests to a server. The server MUST reply with a 159 single final response. Two final responses are defined: "failure" 160 and "success". 162 Before issuing the final response, the server MAY reply with multiple 163 provisional responses. Currently a single provisional response 164 "pending" is defined. 166 Editor's Note: Timeouts TBD. 168 A CCCP request carries the following attributes: 170 requestId: A unique string generated by the CCCP client across all 171 its requests. 172 from: A transport URI which identifies the CCCP client. 173 to: A transport URI which identifies the CCCP server. 174 originator: A trusted ID of the originator of the request. 176 The combination of the 'requestId', 'to', and 'from' attributes in 177 the request constitutes the CCCP transaction ID. 179 A CCCP response carries the following attributes: 181 requestId: The original request ID generated by the client and 182 echoed as is by the server. 183 from: A transport URI which identifies the CCCP server. 184 to: A transport URI which identifies the CCCP client. 185 code: The general response code: success, pending, or failure. 186 reason: The general CCCP failure reason. 187 timeout: The updated timeout used with pending responses (details 188 TBD). 189 retryAfter: The suggested delay used with serverBusy responses. 191 4.2. Multiple Primitives in a Single Operation 193 A CCCP operation (i.e. a request and a corresponding response) MAY 194 contain multiple primitives. The CCCP MUST process the received 195 primitives one-by-one in the order they appear in the request body. 196 If the request contains multiple primitives, the corresponding 197 response operation MUST contain the response primitive for each and 198 in the same order as in the request. 200 Multiple primitives within the same request MUST be executed as an 201 atomic operation. This means that if one primitive fails, the state 202 of the object MUST be rolled back to its state before processing the 203 request. 205 If a CCCP server is not willing to process a multi-primitive request, 206 it MUST fail the transaction with the response code "notSupported". 208 4.3. Response Codes and Failures 210 CCCP defines the following reasons for failure of a request operation 211 : 213 serverBusy: Optional retryAfter can be included in the response. 214 timeout: Operation took too long and was aborted by the server. 215 unauthorized: Client is not authorized to perform the operation. 216 requestMalformed: The XML document in the request is either not 217 well-formed or not compliant with the schema. 218 requestTooLarge: Result of the request operation length check. 219 requestCancelled: The pending request was canceled by CCCP. 220 notSupported: One of the primitives or their combination is not 221 supported by the server. 222 otherFailure: Result of any other server fault condition. 224 Most CCCP primitives define their own optional response codes. This 225 allows communicating the detailed primitive result in addition to the 226 CCCP general response code. 228 5. Using the Data Model 230 The CCCP operations are applied to the data objects expressed in 231 terms of SIPPING Conference Package [2] XML types whenever possible. 232 The considerations listed below MUST be taken into account when using 233 the schema with CCCP. 235 The information included in the request expresses the desired data 236 object state to be achieved after the operation is successfully 237 completed. By definition, the CCCP primitives allow for inclusion of 238 any information that can be expressed in terms of the conference-type 239 and its sub-types. 241 Attributes 'state' and 'version' of the conference-type and its sub- 242 types are never used with CCCP. The information in the response is 243 provided as a feedback to the request only and typically doesn't 244 carry the full state of the object. 246 For each primitive request, the CCCP explicitly defines (see 247 Section 6) what information (i.e. attributes and elements) MUST be 248 provided by the client and what information (when provided by the 249 client) MUST NOT be ignored by the server. The rest of the 250 information included by the client MAY be treated as optional by the 251 server. 253 For each primitive response, the CCCP explicitly defines (see 254 Section 6) what information (i.e. attributes and elements) if 255 included by the server MUST NOT be ignored by the client. The rest 256 of the information included by the client MAY be treated as optional 257 by the server. If neither mandatory information nor new data is 258 generated, the server MAY return minimum schema compliant construct, 259 such as an element with empty body and the attributes identifying the 260 corresponding request only. On the other hand, the CCCP server MAY 261 include any rich dynamically generated information to the client (for 262 example, to be displayed to a user or be logged in by the system) in 263 the response. The client MAY ignore any information received in the 264 response, unless stated otherwise in Section 6. 266 6. Primitives 268 This section describes the defined CCCP primitives and includes valid 269 XML document examples for each. The corresponding CCCP XML schema is 270 provided in Section 7. 272 6.1. System Primitives 274 6.1.1. Cancel 276 Cancel a pending request. 278 This primitive can be issued by a client to cancel a pending 279 transaction. The primitive is an independent transaction on its own. 280 The body of the primitive MUST carry the requestId of one of the 281 pending requests. 283 292 293 5 294 295 297 Note that a valid response can contain an empty body. 299 309 310 312 6.1.2. Ping 314 Ping a CCCP Server. 316 325 326 328 A successful response is shown below. 330 340 341 343 6.1.3. getTemplates 345 Get the list of templates supported by the system. 347 XML TBD. 349 6.1.4. getActiveConferences 351 Get the list of conference identifiers for active conference objects 352 in the system. 354 XML TBD. 356 6.2. Conference Primitives 358 6.2.1. addConference 360 Create a conference. 362 The 'conferenceEntity' value in the request is a client's suggestion 363 only. The CCCP server MAY replace the suggested value with a 364 different 'conferenceEntity' value in the corresponding response. 366 375 376 379 380 Design Review 381 382 383 tel:+1-8666119036 384 FFD bridge 385 386 387 388 389 https://company.com/ConfServer 390 391 392 393 394 audio 395 396 397 398 399 400 402 The CCCP server MAY replace the suggested 'conferenceEntity' with a 403 different value in the corresponding response. In the case of a 404 successful response, the CCCP client MUST use the new value and 405 SHOULD use all the new parameters allocated by the server to the 406 conference. 408 418 419 422 423 Design Review 424 425 426 tel:+1-8666119036 427 FFD bridge 428 429 430 431 432 https://company.com/ConfServer 433 434 435 436 437 audio 438 439 440 441 442 444 446 6.2.2. modifyConference 448 Modify conference parameters. 450 459 460 463 464 Spec Review 465 466 467 468 470 480 481 483 6.2.3. deleteConference 485 Remove conference from the system. 487 496 497 499 500 502 512 513 515 6.2.4. getConference 517 Retrieve the conference information. 519 528 529 531 532 533 543 544 547 548 Design Review 549 550 551 tel:+1-8666119036 552 FFD bridge 553 554 555 556 557 https://company.com/ConfServer 558 559 560 561 562 audio 563 564 565 566 567 568 570 6.3. User Primitives 572 6.3.1. addUser 574 The client MUST provide the 'userEntity' value in the request. 576 585 586 588 590 Bob Hoskins 591 592 presenter 593 594 595 596 598 608 609 611 6.3.2. modifyUser 613 Modify the user information. 615 624 625 627 629 Bob Hoskins III 630 631 632 tel:2562566 633 the description 634 optional tbd values 635 636 637 638 presenter 639 640 641 642 644 654 655 657 6.3.3. modifyUserRoles 659 This is a dedicated primitive to change user's roles. The same 660 effect can be achieved by using the modifyUser primitive. Note that 661 a CCCP server can choose to implement both approaches simultaneously 662 to be invoked by different clients. 664 Editor's Note: The dedicated primitive is defined to demonstrate that 665 both approaches are possible with CCCP. 667 676 677 680 682 presenter 683 684 685 687 697 698 700 6.3.4. deleteUser 702 Remove the user from the conference roster. 704 713 714 717 718 720 730 731 733 6.3.5. getUser 735 Retrieve the information about a conference participant. 737 746 747 750 752 754 764 765 766 768 Bob Hoskins III 769 770 771 tel:2562566 772 the description 773 optional tbd values 774 775 776 777 presenter 778 779 780 781 783 6.4. Endpoint Primitives 785 6.4.1. addEndpoint 787 Bring the specified user into a conference by establishing a call 788 (signaling and media) with him/her/it. 790 The endpoint 'entity' value MAY be replaced or augmented by the CCCP 791 server. The 'media-id' value MAY be replaced or augmented by the 792 CCCP server. If the server returns this information in the response, 793 the client MUST use the values provided by the server. 795 804 805 808 810 Bob's Laptop 811 dialed-out 812 813 main audio 814 audio 815 816 817 818 820 830 831 833 6.4.2. modifyEndpoint 835 Modify the call description or/and its behaivior. 837 846 847 850 852 Bob's Laptop 853 854 855 857 867 868 870 6.4.3. deleteEndpoint 872 Disconnect the call. 874 883 884 888 889 891 901 902 904 6.4.4. getEndpoint 906 Retrieve the information about the call. 908 918 919 923 924 926 936 937 940 942 Bob's Laptop 943 dialed-out 944 945 main audio 946 audio 947 948 949 950 952 6.5. Endpoint Media Primitives 954 6.5.1. addEndpointMedia 956 Add the specified media stream to the call. 958 The 'media-id' value MAY be replaced or augmented by the CCCP server. 959 The CCCP client MUST use the new value if returned by the server in 960 the response. 962 971 972 976 978 main audio 979 audio 980 981 982 984 994 995 997 6.5.2. modifyEndpointMedia 999 Modify the media behavior. This primitive can be used to mute and 1000 un-mute the call. 1002 1011 1012 1016 1018 audio 1019 recvonly 1020 1021 1022 1024 1034 1035 1037 6.5.3. deleteEndpointMedia 1039 Remove the specified media stream from the call. 1041 1050 1051 1056 1057 1059 1069 1070 1072 6.5.4. getEndpointMedia 1074 Retrieve the information about the specified stream in the call. 1076 1085 1086 1091 1092 1094 1104 1105 1109 1111 audio 1112 recvonly 1113 1114 1115 1117 6.6. Sidebar Primitives 1119 6.6.1. addSidebar 1121 Create a sidebar in the conference. 1123 XML TBD. 1125 6.6.2. modifySidebar 1127 Modify the sidebar parameters in the conference. 1129 XML TBD. 1131 6.6.3. deleteSidebar 1133 Remove the sidebar from the conference. 1135 XML TBD. 1137 6.6.4. addUserToSidebar 1139 Add the specified conference participant to the sidebar. 1141 XML TBD. 1143 6.6.5. deleteUserFromSidebar 1145 Remove the specified conference participant from the sidebar. 1147 XML TBD. 1149 6.6.6. moveUserBetweenSidebars 1151 Move the the specified conference participant from sidebar A to 1152 sidebar B. 1154 XML TBD. 1156 6.7. Stimulus Primitives 1158 This operation is used to convey opaque to the CCCP logic requests 1159 from a CCCP client to a CCCP server to be processed by applications 1160 above CCCP. 1162 XML TBD. 1164 7. The XML Schema 1166 1167 1177 1181 1185 1189 1193 1196 1198 1201 1203 1206 1207 1208 1209 1211 1213 1215 1217 1219 1221 1223 1225 1227 1229 1231 1233 1235 1237 1239 1241 1243 1245 1247 1250 1251 1252 1254 1257 1258 1261 1263 1267 1269 1270 1272 1275 1276 1277 1278 1280 1282 1284 1286 1288 1290 1292 1294 1296 1298 1300 1302 1304 1306 1308 1310 1312 1314 1316 1319 1320 1321 1323 1326 1328 1331 1333 1336 1338 1340 1342 1344 1346 1348 1349 1350 1353 1354 1355 1356 1357 1358 1359 1361 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1377 1380 1381 1382 1384 1386 1389 1390 1391 1392 1394 1396 1399 1400 1401 1402 1403 1405 1407 1411 1412 1413 1414 1415 1416 1418 1420 1423 1424 1425 1426 1428 1429 1431 1433 1436 1437 1438 1440 1442 1443 1445 1446 1448 1451 1452 1453 1454 1455 1456 1458 1461 1462 1463 1465 1466 1467 1469 1473 1474 1475 1477 1479 1480 1481 1483 1486 1487 1488 1489 1491 1492 1493 1495 1498 1499 1500 1501 1502 1503 1505 1506 1507 1509 1510 1512 1515 1516 1517 1518 1519 1520 1522 1525 1526 1527 1529 1531 1532 1533 1535 1538 1539 1540 1541 1542 1543 1545 1546 1547 1549 1550 1552 1556 1557 1558 1559 1560 1561 1563 1566 1567 1568 1570 1572 1573 1574 1576 1579 1580 1581 1582 1583 1584 1586 1587 1588 1591 1592 1594 1597 1598 1599 1600 1601 1602 1603 1606 1607 1608 1610 1611 1613 1614 1615 1617 1620 1621 1622 1624 1625 1627 1628 1630 1631 1633 1636 1637 1638 1639 1640 1641 1642 1644 1647 1648 1649 1652 1653 1655 1656 1657 1659 1662 1663 1664 1666 1667 1668 1669 1671 1672 1673 1675 1676 1678 1681 1682 1683 1685 1687 1688 1689 1691 1694 1695 1696 1698 1699 1700 1701 1703 1704 1705 1707 1709 1711 1714 1715 1716 1717 1718 1719 1720 1722 1725 1726 1727 1729 1731 1732 1733 1735 1738 1739 1740 1742 1743 1744 1745 1747 1749 1750 1752 1753 1755 1758 1759 1760 1761 1762 1763 1764 1766 1769 1770 1771 1773 1774 1775 1776 1778 1779 1780 1781 1783 1786 1787 1788 1790 1791 1792 1793 1795 1796 1797 1799 1800 1801 1804 1805 1806 1808 1810 1811 1812 1814 1817 1818 1819 1820 1821 1822 1823 1824 1826 1829 1830 1831 1833 1834 1835 1836 1838 1839 1840 1842 1843 1844 1847 1848 1849 1851 1853 1854 1855 1857 1860 1861 1862 1863 1864 1865 1866 1867 1869 1872 1873 1874 1876 1877 1878 1879 1881 1882 1883 1886 1887 1889 1893 1894 1895 1897 1898 1900 1901 1902 1904 1907 1908 1909 1911 1912 1913 1914 1916 1917 1918 1921 1922 1924 1927 1928 1929 1930 1931 1932 1933 1934 1935 1937 1940 1941 1942 1944 1947 1948 1949 1951 1954 1955 1956 1957 1958 1959 1960 1961 1962 1964 1967 1968 1969 1971 1972 1973 1974 1976 1977 1978 1980 1981 1983 1986 1987 1988 1990 1992 1993 1994 1996 1999 2000 2001 2003 2004 2005 2006 2008 2009 2010 2012 2013 2015 2018 2019 2020 2023 2025 2026 2027 2029 2030 2032 2035 2036 2037 2039 2040 2041 2043 2044 2045 2046 2048 2051 2052 2053 2054 2055 2056 2057 2058 2060 2062 8. IANA Considerations 2064 This document registers a new XML namespace and a new XML schema. 2066 8.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cccp 2068 This section registers a new XML namespace, as per the guidelines in 2069 RFC 3688 [5]. 2071 URI: The URI for this namespace is urn:ietf:params:xml:ns:cccp 2072 Registrant Contact: IETF XCON Working Group , as 2073 designated by the IESG 2074 XML: 2076 BEGIN 2077 2078 2080 2081 2082 2084 Centralized Conference Information Namespace 2086 2088

Namespace for Centralized Conference Control Protocol

2089

urn:ietf:params:xml:ns:cccp

2090

See RFCXXXX.

2091 2092 2093 END 2095 8.2. XML Schema Registration 2097 This specification registers a schema, as per the guidelines in RFC 2098 3688 [5]. 2099 URI: please assign 2100 Registrant Contact: IETF XCON Working Group , as 2101 designated by the IESG 2102 XML: The XML can be found as the sole content of Section 7 2104 9. Security Considerations 2106 Manipulation of conference state and policy information through the 2107 conference control protocol require a strong means for 2108 authentication, conference information protection, and applying 2109 comprehensive authorization rules by a focus. Users of this 2110 specification MUST use encrypted transport means and comply with the 2111 security considerations discussed in the XCON Framework [7] and the 2112 SIP Event Package for Conference State [2] . 2114 10. Acknowledgements 2116 The author would like to thank Gur Kimchi for his earlier work that 2117 served as the starting point for this specification. 2119 11. References 2120 11.1. Normative References 2122 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2123 Levels", BCP 14, RFC 2119, March 1997. 2125 [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2126 Package for Conference State", 2127 draft-ietf-sipping-conference-package-12 (work in progress), 2128 July 2005. 2130 [3] Levin, O., "Extensions to the Session Initiation Protocol (SIP) 2131 Event Package for Conference State", 2132 draft-levin-xcon-conference-package-ext-00 (work in progress), 2133 October 2005. 2135 11.2. Informative References 2137 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2138 Notification", RFC 3265, June 2002. 2140 [5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2141 January 2004. 2143 [6] Rosenberg, J., "A Framework for Conferencing with the Session 2144 Initiation Protocol", 2145 draft-ietf-sipping-conferencing-framework-05 (work in progress), 2146 May 2005. 2148 [7] Barnes, M., "A Framework and Data Model for Centralized 2149 Conferencing", draft-ietf-xcon-framework-01 (work in progress), 2150 July 2005. 2152 Authors' Addresses 2154 Orit Levin 2155 Microsoft Corporation 2156 One Microsoft Way 2157 Redmond, WA 98052 2158 USA 2160 Email: oritl@microsoft.com 2162 Roni Even 2163 Polycom 2164 94 Derech Em Hamoshavot 2165 Petach Tikva, 49130 2166 Israel 2168 Email: roni.even@polycom.co.il 2170 Pierre Hagendorf 2171 RADVISION 2172 24, Raul Wallenberg St. 2173 Tel-Aviv, 69719 2174 Israel 2176 Email: pierre@radvision.com 2178 Intellectual Property Statement 2180 The IETF takes no position regarding the validity or scope of any 2181 Intellectual Property Rights or other rights that might be claimed to 2182 pertain to the implementation or use of the technology described in 2183 this document or the extent to which any license under such rights 2184 might or might not be available; nor does it represent that it has 2185 made any independent effort to identify any such rights. Information 2186 on the procedures with respect to rights in RFC documents can be 2187 found in BCP 78 and BCP 79. 2189 Copies of IPR disclosures made to the IETF Secretariat and any 2190 assurances of licenses to be made available, or the result of an 2191 attempt made to obtain a general license or permission for the use of 2192 such proprietary rights by implementers or users of this 2193 specification can be obtained from the IETF on-line IPR repository at 2194 http://www.ietf.org/ipr. 2196 The IETF invites any interested party to bring to its attention any 2197 copyrights, patents or patent applications, or other proprietary 2198 rights that may cover technology that may be required to implement 2199 this standard. Please address the information to the IETF at 2200 ietf-ipr@ietf.org. 2202 Disclaimer of Validity 2204 This document and the information contained herein are provided on an 2205 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2206 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2207 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2208 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2209 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2210 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2212 Copyright Statement 2214 Copyright (C) The Internet Society (2005). This document is subject 2215 to the rights, licenses and restrictions contained in BCP 78, and 2216 except as set forth therein, the authors retain all their rights. 2218 Acknowledgment 2220 Funding for the RFC Editor function is currently provided by the 2221 Internet Society.