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