idnits 2.17.1 draft-levin-xcon-cccp-02.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1248. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 78 instances of too long lines in the document, the longest one being 174 characters in excess of 72. ** There are 631 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 (February 20, 2005) is 7005 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 128, 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 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XCON O. Levin 2 Internet-Draft Microsoft Corporation 3 Expires: August 24, 2005 R. Even 4 Polycom 5 P. Hagendorf 6 RADVISION 7 February 20, 2005 9 Centralized Conference Data Model 10 draft-levin-xcon-cccp-02 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 24, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document is a part of a suite of protocols being developed in 46 the XCON Working Group and defines a client-server Centralized 47 Conferencing Control Protocol (CCCP) for query, creation, and 48 manipulation of both the XCON system information (e.g. supported 49 templates) and a particular conference information during the 50 conference lifetime cycle (e.g. reservation and state). An XCON 51 server, which implements a CCCP server, provides the means for 52 authorized CCCP clients (e.g. conference participants) to affect the 53 behavior of a conference in the XCON system. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. General . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Transaction Model and Operations . . . . . . . . . . . . . . . 5 61 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.1 System Primitives . . . . . . . . . . . . . . . . . . . . 7 64 6.1.1 getTemplates . . . . . . . . . . . . . . . . . . . . . 7 65 6.1.2 getReservedConferences . . . . . . . . . . . . . . . . 7 66 6.1.3 getActiveConferences . . . . . . . . . . . . . . . . . 7 67 6.2 Conference Primitives . . . . . . . . . . . . . . . . . . 7 68 6.2.1 addConference . . . . . . . . . . . . . . . . . . . . 7 69 6.2.2 getConference . . . . . . . . . . . . . . . . . . . . 7 70 6.2.3 deleteConference . . . . . . . . . . . . . . . . . . . 7 71 6.3 User Primitives . . . . . . . . . . . . . . . . . . . . . 7 72 6.3.1 addUser . . . . . . . . . . . . . . . . . . . . . . . 7 73 6.3.2 getUser . . . . . . . . . . . . . . . . . . . . . . . 8 74 6.3.3 deleteUser . . . . . . . . . . . . . . . . . . . . . . 8 75 6.4 Endpoint Primitives . . . . . . . . . . . . . . . . . . . 8 76 6.4.1 addEndpoint . . . . . . . . . . . . . . . . . . . . . 8 77 6.4.2 getEndpoint . . . . . . . . . . . . . . . . . . . . . 8 78 6.4.3 deleteEndpoint . . . . . . . . . . . . . . . . . . . . 8 79 6.5 Media Primitives . . . . . . . . . . . . . . . . . . . . . 8 80 6.5.1 addMedia . . . . . . . . . . . . . . . . . . . . . . . 8 81 6.5.2 getMedia . . . . . . . . . . . . . . . . . . . . . . . 8 82 6.5.3 deleteMedia . . . . . . . . . . . . . . . . . . . . . 9 83 6.5.4 modifyMediaStatus . . . . . . . . . . . . . . . . . . 9 84 6.6 Stimulus Primitives . . . . . . . . . . . . . . . . . . . 9 85 7. The XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 8.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 8.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 90 10. Security Considerations . . . . . . . . . . . . . . . . . . 26 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 12.1 Normative References . . . . . . . . . . . . . . . . . . . 26 94 12.2 Informative References . . . . . . . . . . . . . . . . . . 27 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 96 Intellectual Property and Copyright Statements . . . . . . . . 28 98 1. Introduction 100 General centralized conferencing architecture is described in the 101 SIPPING Conference Framework [3]. The XCON Framework [4] defines how 102 this architecture can be realized by an XCON compliant system. The 103 XCON framework defines the concepts of the conference policy and the 104 conference information as the top data objects for representing a 105 conference. 107 This document is a part of a suite of protocols being developed in 108 the XCON Working Group and defines a client-server Centralized 109 Conferencing Control Protocol (CCCP) for query, creation, and 110 manipulation of both the XCON system information (e.g. supported 111 templates) and a particular conference information during the 112 conference lifetime cycle (e.g. reservation and state). An XCON 113 server, which implements a CCCP server, provides the means for 114 authorized CCCP clients (e.g. conference participants) to affect the 115 behavior of a conference in the XCON system. 117 2. Terminology 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 121 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 122 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 123 compliant implementations. 125 3. General 127 CCCP can be used to modify any of the conference information objects 128 defined in the XCON Framework document [5]. These include the 129 conference template, reservation, and state. Whenever reasonable, 130 same CCCP primitives are used to access conference information during 131 different stages of the conference life cycle. In order to 132 distinguish between reservation and possible multiple instances of 133 the same conference different URIs are used for each. 135 Editor's Note: URI conventions or parameters TBD in the XCON 136 Framework [4]. 138 CCCP uses the conference information schema type and its sub-types 139 (as defined in the SIPPING Conference Package [2]) for construction 140 of the CCCP data objects. It is expected that additional sub-types 141 will be introduced by XCON in order to express extended conferencing 142 information relevant to XCON-compliant systems. 144 4. Transaction Model and Operations 146 CCCP MUST run over a reliable transport protocol. 148 CCCP is agnostic to the details of the transport protocol being used 149 beneath and does not rely on any information being conveyed on the 150 transport level. 152 CCCP is a transaction client-server protocol. Two types of 153 operations are defined with CCCP : request and response. 155 A client issues requests to a server. The server MAY reply with 156 multiple provisional responses before replying with the final 157 response. Currently a single provisional response "pending" is 158 defined. 160 Editor's Note: Timeout behavior TBD. 162 The server MUST reply with a single final response. Two final 163 responses are defined: "failure" and "success". 165 The following reasons for failure are defined: 167 serverBusy with optional retryAfter 168 timeout performing operation 169 unauthorized 170 requestMalformed 171 requestTooLarge 173 Each CCCP response and each CCCP request carries the following 174 attributes: 'requestId', 'from', and 'to'. 176 The combination of the 'requestId', 'from' and 'to' attributes in the 177 request and in the response constitutes the CCCP transaction ID: 179 requestId: A string generated by the CCCP client and unique for each 180 CCCP request generated by the client. 181 from: A URI which identifies the CCCP client. 182 to: A URI which identifies the CCCP server. 184 Note that 'to' is mandatory but is not used in order to uniquely 185 identify a particular transaction. 187 Multiple primitives can be included in a single CCCP operation (i.e. 188 in a request and a corresponding response). The primitives within 189 the request operation MUST be performed by the CCCP server one-by-one 190 in the order they appear in the request body. The corresponding 191 response operation MUST include the response primitive for each of 192 the issued primitives in the exact same order. Note, that for this 193 reason, the primitives inside the operation bodies are not numbered. 195 Multiple primitives within the same request MUST be executed as an 196 atomic operation. It means that if one primitive fails, the state of 197 the object MUST be rolled back to its previous state, i.e. before 198 the request had been processed. 200 5. Data Model 202 The CCCP operations can be issued on the conference template, 203 conference reservation, and any of the conference instance data 204 objects. All these data objects are expressed in terms of 205 conference-info-type defined in SIPPING Conference Package [2]. 206 Consequently, CCCP requests are expressed using the same 207 conference-info type and its sub-types whenever it makes sense. The 208 information included in the request expresses the desired data object 209 state to be achieved after the operation is successfully completed. 211 The considerations listed below MUST be taken into account when using 212 the schema with CCCP. 214 Attributes 'state' and 'version' of the conference-info-type and its 215 sub-types are never used with CCCP. 217 The primitives' definition allows for inclusion of any element 218 defined by the conference-info-type and its sub-types. Note that it 219 is optional to include these elements by both the client and the 220 server and their processing is optional by the receiving side, unless 221 explicitly stated otherwise in the normative description of the CCCP 222 primitives in Section 6. 224 For example, when adding or creating objects (e.g. a conference, a 225 user, an endpoint, a media, etc.) the client MUST include only the 226 information that is required for the object creation. The client 227 MUST assume that the Server MAY return new dynamically generated 228 information in a successful response. 230 On the other hand, the Server MAY return minimum information in the 231 response or even an empty element corresponding to a successful 232 request. CCCP allows the inclusion of richer information that can be 233 displayed to a user or be logged in by the system, but doesn't 234 mandate to always include this information in the response. 236 6. Primitives 237 6.1 System Primitives 239 6.1.1 getTemplates 241 Get the list of template identifiers supported by the system. 243 XML TBD. 245 6.1.2 getReservedConferences 247 Get the list of reservation identifiers allocated by the system. 249 XML TBD. 251 6.1.3 getActiveConferences 253 Get the list of conference identifiers of active instances running in 254 the system. 256 XML TBD. 258 6.2 Conference Primitives 260 6.2.1 addConference 262 Create a conference. The conference can be a new conference 263 "blueprint", new reservation, or a new ad-hoc instance. 265 For XML definition see Section 7. 267 The 'conferenceEntity' value in the request is a client's suggestion 268 only. The CCCP server can replace the suggested value with a 269 different 'conferenceEntity' value in the corresponding response. 271 6.2.2 getConference 273 For XML definition see Section 7. 275 6.2.3 deleteConference 277 For XML definition see Section 7. 279 6.3 User Primitives 281 6.3.1 addUser 283 For XML definition see Section 7. 285 The Client MUST provide the 'userEntity' value in the request. If 286 the client doesn't care (and/or) doesn't know the 'endpointEntity' 287 value, it must populate it with the value equal to the 'userEntity'. 288 The client MUST expect to receive in the successful response a real 289 value of the 'endpointEntity'. 291 6.3.2 getUser 293 For XML definition see Section 7. 295 6.3.3 deleteUser 297 For XML definition see Section 7. 299 6.4 Endpoint Primitives 301 6.4.1 addEndpoint 303 For XML definition see Section 7. 305 The Client MUST provide a valid 'endpointEntity' value in the 306 request. 308 6.4.2 getEndpoint 310 For XML definition see Section 7. 312 6.4.3 deleteEndpoint 314 For XML definition see Section 7. 316 6.5 Media Primitives 318 6.5.1 addMedia 320 The 'mediaId' value in the request is ignored by the CCCP server. 321 The CCCP server MUST replace the value with the real 'media-id' value 322 in the corresponding response. 324 6.5.2 getMedia 326 This operation is used to get the description of a media stream of a 327 participant in the conference. 329 For XML definition see Section 7. 331 6.5.3 deleteMedia 333 This operation is used to remove a media stream from a participant in 334 the conference. 336 For XML definition see Section 7. 338 6.5.4 modifyMediaStatus 340 This operation can be used for muting and un-muting media streams. 342 For XML definition see Section 7. 344 6.6 Stimulus Primitives 346 This operation is used to convey opaque pre-defined requests from a 347 CCCP client to a CCCP server. 349 XML TBD. 351 7. The XML 353 354 355 358 360 363 364 367 369 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 437 438 439 440 441 442 443 445 448 449 450 451 452 453 454 455 456 457 458 461 462 463 464 465 468 469 470 471 472 473 476 477 478 479 480 481 482 483 486 487 488 489 490 491 492 493 494 497 498 499 500 501 502 503 504 507 508 509 510 511 512 513 515 518 519 520 521 522 523 524 525 528 529 530 531 532 533 534 535 538 539 540 541 542 543 544 545 548 549 550 551 552 553 554 555 558 559 560 561 562 563 564 565 568 569 570 571 572 573 574 575 578 579 580 581 582 583 584 585 586 589 590 591 592 593 594 595 596 597 600 601 602 603 604 605 606 607 610 611 612 613 614 615 616 617 618 621 622 623 624 625 626 627 628 631 632 633 634 635 636 637 638 639 642 643 644 645 646 647 648 649 650 653 654 655 656 657 658 659 660 661 664 665 666 667 668 669 670 671 674 675 676 677 678 679 680 681 682 685 686 687 688 689 690 691 692 695 696 697 698 699 700 701 702 703 706 707 708 709 710 711 712 713 714 717 718 719 720 721 722 723 724 725 728 729 730 731 732 733 734 735 738 739 740 741 742 743 744 745 746 749 750 751 752 753 754 755 756 759 760 761 762 763 764 765 766 768 771 772 773 774 775 776 777 778 779 782 783 784 785 786 787 788 789 791 8. Example 793 In order to illustrate the CCCP syntax, the example below shows all 794 possible primitives issued in a single request and the corresponding 795 answers are included in a single response. In this case all the 796 primitives are executed as a single atomic operation. 798 Editor's Note: In the next version of this document the example will 799 be split into separate operations with clear semantics for each. 801 8.1 Request 803 804 805 806 810 811 812 813 100 814 815 816 817 818 audio 819 820 821 video 822 823 824 825 826 828 829 830 833 834 Agenda: This month's goals 835 836 837 tel:+18005671234 838 TTI Bridge 839 840 841 842 843 http://sharepoint/salesgroup/ 844 web-page 845 846 847 848 849 52 850 851 852 50 853 854 855 856 857 main audio 858 audio 859 860 861 main video 862 video 863 864 865 866 867 869 870 871 873 874 875 877 878 879 880 Bob Hoskins 881 884 885 Bob's Laptop 886 dialed-out 888 891 892 main audio 893 audio 894 895 896 897 899 900 901 902 903 participant 904 905 906 908 909 910 912 913 914 916 917 918 919 Bob's Laptop 920 dialed-out 922 925 926 main audio 927 audio 928 929 930 932 933 934 936 937 938 940 941 942 943 main audio 944 audio 945 946 948 951 952 953 955 recvonly 956 957 959 960 961 963 964 965 967 970 971 972 recvonly 973 975 977 8.2 Response 979 980 981 982 985 986 Agenda: This month's goals 987 988 989 tel:+18005671234 990 TTI Bridge 991 992 993 994 995 http://sharepoint/salesgroup/ 996 web-page 997 998 999 1000 1001 52 1002 1003 1004 50 1005 1006 1007 1008 1009 audio 1010 1011 1012 video 1013 1014 1015 1016 1017 1019 1020 1021 1024 1025 Agenda: This month's goals 1026 1027 1028 tel:+18005671234 1029 TTI Bridge 1030 1031 1032 1033 1034 http://sharepoint/salesgroup/ 1035 web-page 1036 1037 1038 1039 1040 52 1041 1042 1043 50 1044 1045 1046 1047 1048 audio 1049 1050 1051 video 1052 1053 1054 1055 1056 1058 1059 1060 1062 1063 1064 1065 1067 1068 1069 1070 1072 1073 1074 1075 Bob Hoskins 1076 1079 1080 Bob's Laptop 1081 dialed-out 1083 1086 1087 main audio 1088 audio 1089 1090 1091 1092 1094 1095 1096 1098 1100 1101 1102 1103 1105 1106 1107 1108 Bob's Laptop 1109 dialed-out 1111 1114 1115 main audio 1116 audio 1117 1118 1119 1121 1122 1123 1124 1126 1127 1128 1129 main audio 1130 audio 1131 1132 1134 1135 1136 1137 1139 1140 1141 1142 main audio 1143 audio 1144 1145 1146 1147 1148 1149 main audio 1150 audio 1151 1152 1154 1157 1158 1159 recvonly 1160 1162 1164 9. IANA Considerations 1166 TBD. 1168 10. Security Considerations 1170 TBD. 1172 11. Acknowledgements 1174 The author would like to thank Gur Kimchi for his earlier work that 1175 served as the starting point for this specification. 1177 12. References 1179 12.1 Normative References 1181 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1182 Levels", BCP 14, RFC 2119, March 1997. 1184 [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1185 Package for Conference State", 1186 Internet-Draft draft-ietf-sipping-conference-package-08, 1187 December 2004. 1189 12.2 Informative References 1191 [3] Rosenberg, J., "A Framework for Conferencing with the Session 1192 Initiation Protocol", 1193 Internet-Draft draft-ietf-sipping-conferencing-framework-03, 1194 October 2004. 1196 [4] Barnes, M. and C. Boulton, "A Framework and Data Model for 1197 Centralized Conferencing", 1198 Internet-Draft draft-barnes-xcon-framework-02, February 2005. 1200 Authors' Addresses 1202 Orit Levin 1203 Microsoft Corporation 1204 One Microsoft Way 1205 Redmond, WA 98052 1206 USA 1208 Email: oritl@microsoft.com 1210 Roni Even 1211 Polycom 1212 94 Derech Em Hamoshavot 1213 Petach Tikva, 49130 1214 Israel 1216 Email: roni.even@polycom.co.il 1218 Pierre Hagendorf 1219 RADVISION 1220 24, Raul Wallenberg St. 1221 Tel-Aviv, 69719 1222 Israel 1224 Email: pierre@radvision.com 1226 Intellectual Property Statement 1228 The IETF takes no position regarding the validity or scope of any 1229 Intellectual Property Rights or other rights that might be claimed to 1230 pertain to the implementation or use of the technology described in 1231 this document or the extent to which any license under such rights 1232 might or might not be available; nor does it represent that it has 1233 made any independent effort to identify any such rights. Information 1234 on the procedures with respect to rights in RFC documents can be 1235 found in BCP 78 and BCP 79. 1237 Copies of IPR disclosures made to the IETF Secretariat and any 1238 assurances of licenses to be made available, or the result of an 1239 attempt made to obtain a general license or permission for the use of 1240 such proprietary rights by implementers or users of this 1241 specification can be obtained from the IETF on-line IPR repository at 1242 http://www.ietf.org/ipr. 1244 The IETF invites any interested party to bring to its attention any 1245 copyrights, patents or patent applications, or other proprietary 1246 rights that may cover technology that may be required to implement 1247 this standard. Please address the information to the IETF at 1248 ietf-ipr@ietf.org. 1250 Disclaimer of Validity 1252 This document and the information contained herein are provided on an 1253 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1254 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1255 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1256 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1257 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1258 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1260 Copyright Statement 1262 Copyright (C) The Internet Society (2005). This document is subject 1263 to the rights, licenses and restrictions contained in BCP 78, and 1264 except as set forth therein, the authors retain all their rights. 1266 Acknowledgment 1268 Funding for the RFC Editor function is currently provided by the 1269 Internet Society.