idnits 2.17.1 draft-levin-xcon-cccp-01.txt: -(772): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1162. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1169. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1175. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 75 instances of too long lines in the document, the longest one being 172 characters in excess of 72. ** There are 598 instances of lines with control characters in the document. 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 2004) is 7072 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '5' is mentioned on line 125, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-08 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-03 == Outdated reference: A later version (-02) exists of draft-barnes-xcon-framework-01 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 7 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: June 1, 2005 December 2004 6 Centralized Conference Data Model 7 draft-levin-xcon-cccp-01 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 1, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This document is a part of a suite of protocols being developed in 43 the XCON Working Group and defines a client-server Centralized 44 Conferencing Control Protocol (CCCP) for query, creation, and 45 manipulation of both the XCON system information (e.g. supported 46 templates) and a particular conference information during the 47 conference lifetime cycle (e.g. reservation and state). An XCON 48 server, which implements a CCCP server, provides the 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. General . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Transaction Model and Operations . . . . . . . . . . . . . . . 4 58 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.1 System Primitives . . . . . . . . . . . . . . . . . . . . 5 61 6.1.1 getTemplates . . . . . . . . . . . . . . . . . . . . . 5 62 6.1.2 getReservedConferences . . . . . . . . . . . . . . . . 6 63 6.1.3 getActiveConferences . . . . . . . . . . . . . . . . . 6 64 6.2 Conference Primitives . . . . . . . . . . . . . . . . . . 6 65 6.2.1 addConference . . . . . . . . . . . . . . . . . . . . 6 66 6.2.2 getConference . . . . . . . . . . . . . . . . . . . . 6 67 6.2.3 deleteConference . . . . . . . . . . . . . . . . . . . 6 68 6.3 User Primitives . . . . . . . . . . . . . . . . . . . . . 6 69 6.3.1 addUser . . . . . . . . . . . . . . . . . . . . . . . 6 70 6.3.2 getUser . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.3.3 deleteUser . . . . . . . . . . . . . . . . . . . . . . 7 72 6.4 Endpoint Primitives . . . . . . . . . . . . . . . . . . . 7 73 6.4.1 addEndpoint . . . . . . . . . . . . . . . . . . . . . 7 74 6.4.2 getEndpoint . . . . . . . . . . . . . . . . . . . . . 7 75 6.4.3 deleteEndpoint . . . . . . . . . . . . . . . . . . . . 7 76 6.5 Media Primitives . . . . . . . . . . . . . . . . . . . . . 7 77 6.5.1 addMedia . . . . . . . . . . . . . . . . . . . . . . . 7 78 6.5.2 getMedia . . . . . . . . . . . . . . . . . . . . . . . 7 79 6.5.3 deleteMedia . . . . . . . . . . . . . . . . . . . . . 7 80 6.5.4 modifyMediaStatus . . . . . . . . . . . . . . . . . . 8 81 6.6 Stimulus Primitives . . . . . . . . . . . . . . . . . . . 8 82 7. The XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 8.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 8.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 87 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 91 12.2 Informative References . . . . . . . . . . . . . . . . . . . 24 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 93 Intellectual Property and Copyright Statements . . . . . . . . 26 95 1. Introduction 97 General centralized conferencing architecture is described in the 98 SIPPING Conference Framework [3]. The XCON Framework [4] defines how 99 this architecture can be realized by an XCON compliant system. The 100 XCON framework defines the concepts of the conference policy and the 101 conference information as the top data objects for representing a 102 conference. 104 This document is a part of a suite of protocols being developed in 105 the XCON Working Group and defines a client-server Centralized 106 Conferencing Control Protocol (CCCP) for query, creation, and 107 manipulation of both the XCON system information (e.g. supported 108 templates) and a particular conference information during the 109 conference lifetime cycle (e.g. reservation and state). An XCON 110 server, which implements a CCCP server, provides the means for 111 authorized CCCP clients (e.g. conference participants) to affect the 112 behavior of a conference in the XCON system. 114 2. Terminology 116 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 117 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 118 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 119 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 120 compliant implementations. 122 3. General 124 CCCP can be used to modify any of the conference information objects 125 defined in the XCON Framework document [5]. These include the 126 conference template, reservation, and state. Whenever reasonable, 127 same CCCP primitives are used to access conference information during 128 different stages of the conference life cycle. In order to 129 distinguish between reservation and possible multiple instances of 130 the same conference different URIs are used for each. 132 Editor's Note: URI conventions or parameters TBD in the XCON 133 Framework [4]. 135 CCCP uses the conference information schema type and its sub-types 136 (as defined in the SIPPING Conference Package [2]) for construction 137 of the CCCP data objects. It is expected that additional sub-types 138 will be introduced by XCON in order to express extended conferencing 139 information relevant to XCON-compliant systems. 141 4. Transaction Model and Operations 143 CCCP MUST run over a reliable transport protocol. 145 CCCP is agnostic to the details of the transport protocol being used 146 beneath and does not rely on any information being conveyed on the 147 transport level only. 149 CCCP is a transaction client-server protocol. Two types of 150 operations are defined with CCCP : request and response. 152 A client issues requests to a server. The server MAY reply with 153 multiple provisional responses before replying with the final 154 response. Currently a single provisional response "pending" is 155 defined. 157 Editor's Note: Timeout behavior TBD. 159 The server MUST reply with a single final response. Two final 160 responses are defined: "failure" and "success". 162 Each CCCP response and each CCCP request carries the following 163 attributes: 'requestId', 'from', 'to', and optionally 'aaId'. 165 The combination of the 'requestId', 'from' and 'to' attributes in the 166 request and in the response constitutes the CCCP transaction ID: 168 requestId: A string generated by the CCCP client and unique for each 169 CCCP request generated by the client. 170 from: A URI which identifies the CCCP client. 171 to: A URI which identifies the CCCP server. 173 Note that 'to' is mandatory but is not used in order to uniquely 174 identify a particular transaction. 176 The 'aaId' attribute holds a secured identity of the issuer of the 177 CCCP request. Its value is being used by the CCCP server for 178 authorization purposes. 180 Multiple primitives can be included in a single CCCP operation (i.e. 181 in a request and a corresponding response). The primitives within 182 the request operation MUST be performed by the CCCP server one-by-one 183 in the order they appear in the request body. The corresponding 184 response operation MUST include the response primitive for each of 185 the issued primitives in the exact same order. Note, that for this 186 reason, the primitives inside the operation bodies are not numbered. 188 Multiple primitives within the same request MUST be executed as an 189 atomic operation. It means that if one primitive fails, the state of 190 the object MUST be rolled back to its previous state, i.e. before 191 the request had been processed. 193 5. Data Model 195 The CCCP operations can be issued on the conference template, 196 conference reservation, and any of the conference instance data 197 objects. All these data objects are expressed in terms of 198 conference-info-type defined in SIPPING Conference Package [2]. 199 Consequently, CCCP requests are expressed using the same 200 conference-info type and its sub-types whenever it makes sense. The 201 information included in the request expresses the desired data object 202 state to be achieved after the operation is successfully completed. 204 The considerations listed below MUST be taken into account when using 205 the schema with CCCP. 207 Attributes 'state' and 'version' of the conference-info-type and its 208 sub-types are never used with CCCP. 210 The primitives' definition allows for inclusion of any element 211 defined by the conference-info-type and its sub-types. Note that it 212 is optional to include these elements by both the client and the 213 server and their processing is optional by the receiving side, unless 214 explicitly stated otherwise in the normative description of the CCCP 215 primitives in Section 6. 217 For example, when adding or creating objects (e.g. a conference, a 218 user, an endpoint, a media, etc.) the client MUST include only the 219 information that is required for the object creation. The client 220 MUST assume that the Server MAY return new dynamically generated 221 information in a successful response. 223 On the other hand, the Server MAY return minimum information in the 224 response or even an empty element corresponding to a successful 225 request. CCCP allows the inclusion of richer information that can be 226 displayed to a user or be logged in by the system, but doesn't 227 mandate to always include this information in the response. 229 6. Primitives 231 6.1 System Primitives 233 6.1.1 getTemplates 235 Get the list of template identifiers supported by the system. 237 XML TBD. 239 6.1.2 getReservedConferences 241 Get the list of reservation identifiers allocated by the system. 243 XML TBD. 245 6.1.3 getActiveConferences 247 Get the list of conference identifiers of active instances running in 248 the system. 250 XML TBD. 252 6.2 Conference Primitives 254 6.2.1 addConference 256 Create a conference. The conference can be a new template, new 257 reservation, or a new ad-hoc instance. 259 For XML definition see Section 7. 261 The 'conferenceEntity' value in the request is a client's suggestion 262 only. The CCCP server can replace the suggested value with a 263 different 'conferenceEntity' value in the corresponding response. 265 6.2.2 getConference 267 For XML definition see Section 7. 269 6.2.3 deleteConference 271 For XML definition see Section 7. 273 6.3 User Primitives 275 6.3.1 addUser 277 For XML definition see Section 7. 279 The Client MUST provide the 'userEntity' value in the request. If 280 the client doesn't care (and/or) doesn't know the 'endpointEntity' 281 value, it must populate it with the value equal to the 'userEntity'. 282 The client MUST expect to receive in the successful response a real 283 value of the 'endpointEntity'. 285 6.3.2 getUser 287 For XML definition see Section 7. 289 6.3.3 deleteUser 291 For XML definition see Section 7. 293 6.4 Endpoint Primitives 295 6.4.1 addEndpoint 297 For XML definition see Section 7. 299 The Client MUST provide a valid 'endpointEntity' value in the 300 request. 302 6.4.2 getEndpoint 304 For XML definition see Section 7. 306 6.4.3 deleteEndpoint 308 For XML definition see Section 7. 310 6.5 Media Primitives 312 6.5.1 addMedia 314 The 'mediaId' value in the request is ignored by the CCCP server. 315 The CCCP server MUST replace the value with the real 'media-id' value 316 in the corresponding response. 318 6.5.2 getMedia 320 This operation is used to get the description of a media stream of a 321 participant in the conference. 323 For XML definition see Section 7. 325 6.5.3 deleteMedia 327 This operation is used to remove a media stream from a participant in 328 the conference. 330 For XML definition see Section 7. 332 6.5.4 modifyMediaStatus 334 This operation can be used for muting and un-muting media streams. 336 For XML definition see Section 7. 338 6.6 Stimulus Primitives 340 This operation is used to convey opaque pre-defined requests from a 341 CCCP client to a CCCP server. 343 XML TBD. 345 7. The XML 347 348 349 352 354 357 358 361 362 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 425 426 427 428 429 430 431 432 435 436 437 438 439 442 443 444 445 446 447 450 451 452 453 454 455 456 459 460 461 462 463 464 465 466 469 470 471 472 473 474 475 476 479 480 481 482 483 484 485 486 489 490 491 492 493 494 495 496 499 500 501 502 503 504 505 506 509 510 511 512 513 514 515 516 519 520 521 522 523 524 525 526 529 530 531 532 533 534 535 536 537 540 541 542 543 544 545 546 547 548 551 552 553 554 555 556 557 558 561 562 563 564 565 566 567 568 569 572 573 574 575 576 577 578 579 582 583 584 585 586 587 588 589 590 593 594 595 596 597 598 599 600 601 604 605 606 607 608 609 610 611 612 615 616 617 618 619 620 621 622 625 627 628 629 630 631 632 633 634 637 638 639 640 641 642 643 644 647 648 649 650 651 652 653 654 655 658 659 660 661 662 663 664 665 666 669 670 671 672 673 674 675 676 677 680 681 682 683 684 685 686 687 690 692 693 694 695 696 697 698 699 702 703 704 705 706 707 708 709 712 713 714 715 716 717 718 719 720 723 724 725 726 727 728 729 730 731 734 735 736 737 738 739 740 741 742 745 746 747 748 749 750 751 752 753 756 757 758 759 760 761 762 763 765 8. Example 767 In order to illustrate the CCCP syntax, the example below shows all 768 possible primitives issued in a single request and the corresponding 769 answers are included in a single response. In this case all the 770 primitives are executed as a single atomic operation. 772 Editor�s Note: In the next version of this document the example will 773 be split into separate operations with clear semantics for each. 775 8.1 Request 777 778 779 780 783 784 Agenda: This month's goals 785 786 787 tel:+18005671234 788 TTI Bridge 789 790 791 792 793 http://sharepoint/salesgroup/ 794 web-page 795 796 797 798 799 any 800 52 801 802 803 participant 804 50 805 806 807 808 809 audio 810 811 812 video 813 814 815 816 817 819 820 821 823 824 825 827 828 829 830 Bob Hoskins 831 834 835 Bob's Laptop 836 dialed-out 838 841 842 main audio 843 audio 844 845 846 847 849 850 851 853 854 855 857 858 859 861 Bob's Laptop 862 dialed-out 864 867 868 main audio 869 audio 870 871 872 874 875 876 878 879 880 882 883 884 885 main audio 886 audio 887 888 890 891 892 894 895 896 898 901 902 903 Bob Hoskins 904 906 909 910 911 recvonly 912 914 916 8.2 Response 918 919 920 921 924 925 Agenda: This month's goals 926 927 928 tel:+18005671234 929 TTI Bridge 930 931 932 933 934 http://sharepoint/salesgroup/ 935 web-page 936 937 938 939 940 any 941 52 942 943 944 participant 945 50 946 947 948 949 950 audio 951 952 953 video 954 955 956 957 958 960 961 962 965 966 Agenda: This month's goals 967 968 969 tel:+18005671234 970 TTI Bridge 971 972 973 974 975 http://sharepoint/salesgroup/ 976 web-page 977 978 979 980 981 any 982 52 983 984 985 participant 986 50 987 988 989 990 991 audio 992 993 994 video 995 996 997 998 999 1001 1002 1004 1006 1007 1008 1009 1011 1012 1013 1014 Bob Hoskins 1015 1018 1019 Bob's Laptop 1020 dialed-out 1022 1025 1026 main audio 1027 audio 1028 1029 1030 1031 1033 1034 1035 1036 1038 1039 1040 1041 1043 1044 1045 1046 Bob's Laptop 1047 dialed-out 1049 1052 1053 main audio 1055 audio 1056 1057 1058 1060 1061 1062 1063 1065 1066 1067 1068 main audio 1069 audio 1070 1071 1073 1074 1075 1076 main audio 1077 audio 1078 1079 1081 1082 1083 1084 main audio 1085 audio 1086 1087 1089 1092 1093 1094 Bob Hoskins 1095 1097 1100 1101 1102 recvonly 1103 1105 1107 9. IANA Considerations 1109 TBD. 1111 10. Security Considerations 1113 TBD. 1115 11. Acknowledgements 1117 The author would like to thank Gur Kimchi for his earlier work that 1118 served as the starting point for this specification. 1120 12. References 1122 12.1 Normative References 1124 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1125 Levels", BCP 14, RFC 2119, March 1997. 1127 [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1128 Package for Conference State", 1129 draft-ietf-sipping-conference-package-08 (work in progress), 1130 December 2004. 1132 12.2 Informative References 1134 [3] Rosenberg, J., "A Framework for Conferencing with the Session 1135 Initiation Protocol", 1136 draft-ietf-sipping-conferencing-framework-03 (work in progress), 1137 October 2004. 1139 [4] Barnes, M. and C. Boulton, "A Framework and Data Model for 1140 Centralized Conferencingg", draft-barnes-xcon-framework-01 (work 1141 in progress), December 2004. 1143 Author's Address 1145 Orit Levin 1146 Microsoft Corporation 1147 One Microsoft Way 1148 Redmond, WA 98052 1149 USA 1151 EMail: oritl@microsoft.com 1153 Intellectual Property Statement 1155 The IETF takes no position regarding the validity or scope of any 1156 Intellectual Property Rights or other rights that might be claimed to 1157 pertain to the implementation or use of the technology described in 1158 this document or the extent to which any license under such rights 1159 might or might not be available; nor does it represent that it has 1160 made any independent effort to identify any such rights. Information 1161 on the procedures with respect to rights in RFC documents can be 1162 found in BCP 78 and BCP 79. 1164 Copies of IPR disclosures made to the IETF Secretariat and any 1165 assurances of licenses to be made available, or the result of an 1166 attempt made to obtain a general license or permission for the use of 1167 such proprietary rights by implementers or users of this 1168 specification can be obtained from the IETF on-line IPR repository at 1169 http://www.ietf.org/ipr. 1171 The IETF invites any interested party to bring to its attention any 1172 copyrights, patents or patent applications, or other proprietary 1173 rights that may cover technology that may be required to implement 1174 this standard. Please address the information to the IETF at 1175 ietf-ipr@ietf.org. 1177 Disclaimer of Validity 1179 This document and the information contained herein are provided on an 1180 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1181 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1182 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1183 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1184 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1185 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1187 Copyright Statement 1189 Copyright (C) The Internet Society (2004). This document is subject 1190 to the rights, licenses and restrictions contained in BCP 78, and 1191 except as set forth therein, the authors retain all their rights. 1193 Acknowledgment 1195 Funding for the RFC Editor function is currently provided by the 1196 Internet Society.