idnits 2.17.1 draft-rosenberg-peterson-simple-pidf-phone-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2003) is 7613 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: '1' is defined on line 677, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 680, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '4') == Outdated reference: A later version (-03) exists of draft-ietf-simple-data-req-02 == Outdated reference: A later version (-01) exists of draft-ietf-simple-xcap-auth-usage-00 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: December 22, 2003 J. Peterson 5 Neustar 6 June 23, 2003 8 Extensions to the Presence Information Document Format (PIDF) for 9 Conveying Phone State 10 draft-rosenberg-peterson-simple-pidf-phone-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 22, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document presents extensions to the Presence Information 41 Document Format (PIDF) for representing the state of telephones. This 42 state includes whether the telephone is in a call or not, whether it 43 is registered to the network, whether it is ringing, and so on. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Common State Elements . . . . . . . . . . . . . . . . . . . 3 49 2.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. POTS Line State . . . . . . . . . . . . . . . . . . . . . . 4 51 3.1 POTS line XML Schema . . . . . . . . . . . . . . . . . . . . 6 52 3.2 Example POTS Line PIDF document . . . . . . . . . . . . . . 7 53 4. Enterprise Phone State . . . . . . . . . . . . . . . . . . . 7 54 4.1 Enterprise Phone XML Schema . . . . . . . . . . . . . . . . 7 55 4.2 Enterprise Phone PIDF Document Example . . . . . . . . . . . 9 56 5. Wireless Phone State . . . . . . . . . . . . . . . . . . . . 9 57 5.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 11 58 5.2 Example Presence Document . . . . . . . . . . . . . . . . . 12 59 6. Security Considerations . . . . . . . . . . . . . . . . . . 13 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 61 7.1 URN Sub-Namespace Registrations . . . . . . . . . . . . . . 13 62 7.1.1 urn:ietf:params:xml:ns:pidf:common-phone . . . . . . . . . . 14 63 7.1.2 urn:ietf:params:xml:ns:pidf:wireless-phone-state . . . . . . 14 64 7.1.3 urn:ietf:params:xml:ns:pidf:pls . . . . . . . . . . . . . . 15 65 7.1.4 urn:ietf:params:xml:ns:pidf:eps . . . . . . . . . . . . . . 16 66 7.2 Schema Registrations . . . . . . . . . . . . . . . . . . . . 16 67 7.2.1 Common Phone State . . . . . . . . . . . . . . . . . . . . . 16 68 7.2.2 POTS Line State . . . . . . . . . . . . . . . . . . . . . . 16 69 7.2.3 Enterprise Phone State . . . . . . . . . . . . . . . . . . . 17 70 7.2.4 Wireless Phone State . . . . . . . . . . . . . . . . . . . . 17 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 72 Normative References . . . . . . . . . . . . . . . . . . . . 17 73 Informative References . . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 75 Intellectual Property and Copyright Statements . . . . . . . 20 77 1. Introduction 79 The Presence Information Document Format (PIDF) [6] provides a 80 baseline set of presence information that allows a presentity [7] to 81 inform a watcher about itself. Information about a presentity is 82 broken into a set of tuples. Each tuple represents a point of contact 83 for a presentity. The tuple includes a URI that can be used to reach 84 the presentity, a basic status of either open or closed, and a 85 textual note meant for consumption by a human. 87 PIDF is meant to be extended to provide additional information about 88 presentities. In this specification, we define extensions to PIDF 89 that allow a tuple to represent a telephone, or any device with 90 telephone-like behaviors. Specifically, a telephone is any piece of 91 hardware or software that is capable of making and/or receiving real 92 time media streams with another such device. 94 Most telephones in the world today lack Internet connections, and 95 communicate only through the Public Switched Telephone Network 96 (PSTN). The presence for telephones described in this document might 97 therefore be created by a telephone switch or other agent responsible 98 for managing dumb telephones when the telephones themselves lack the 99 intelligence to generate or disseminate presence information. That 100 much said, these presence extensions are also servicable for 101 representing Internet telephones. 103 2. Common State Elements 105 While the presence states associated with wireless phones, POTS 106 phones and enterprise PBX phones do vary, there are certain pieces of 107 presence state that are common to all. In particular, the notion of 108 call state is common across all three types. As such, we specify a 109 common XML schema for describing call state. The namespace URI for 110 elements that represent common presence state across phones is a URN 111 [3], using the namespace identifier 'ietf' defined by [4] and 112 extended by [5]. This URN is: 114 urn:ietf:params:xml:ns:pidf:common-phone-state 116 The elements defined in this schema are: 118 call-state: This element indicates the state of any calls made by, or 119 received by, the phone. The possible values of this element are: 121 not-in-call: The phone is not in a call. 123 dialing: The phone is attempting to initiate a call. This state 124 includes the entry of digits by the user and the subsequent 125 signaling into the network. 127 ringing: The phone has initiated a call, and has received ringback 128 from the called party. 130 alerting: The phone has received a call, and is alerting the user. 132 in-call: The phone is in an active call. 134 in-error: The call could not be completed because of some kind of 135 error, such as all-circuits-busy. 137 2.1 XML Schema 139 140 145 146 147 148 149 150 151 152 153 154 155 156 158 3. POTS Line State 160 Plain Old Telephone Service (POTS) is a term used to denote the 161 lowest common denominator of functionality among end terminals in the 162 PSTN. A POTS phone (or "black" phone in common parlance) is usually a 163 device with a numeric (multifrequency or rotary) user interface which 164 may or may not support a visual display. 166 POTS devices are not intelligent endpoints - their primary function 167 is to render and receive audio information (in the form of dialing 168 information, human speech or other audible tones) over their 169 connection to a telephone switch. As such, a POTS phone by definition 170 cannot create a presence document and communicate it to the switching 171 infrastructure. The telephone switch to which a POTS phone connects, 172 however, could create a presence document representing the state of 173 the line. 175 Due to the nature of POTS lines, the switching infrastructure has no 176 reliable way to determine whether zero, one or more terminals have 177 been connected to a single telephone line - thus a presence document 178 generated by the switching infrastructure cannot be know with any 179 certainty to correspond to a particular telephone. As such, we term 180 it "POTS line state" rather than "POTS phone state". 182 To integrate the call state of a POTS line into PIDF, we specify a 183 two elements that extend the status element of baseline PIDF: 185 call-state: This element indicates the state of any calls made by, or 186 received by, the phone. 188 call-waiting: This element is used when the call state is 'in-call' 189 only. It signifies whether or not the call is progress is 190 interruptable by call waiting. If the call is interruptable, the 191 value of this element should be "available". If the call waiting 192 feature is not available on the line, or is already occupied by 193 another caller, the value of this element should be "unavailable". 194 If this element is not present, and the call state is 'in-call', 195 the value is assumed to be "unavailable". 197 3.1 POTS line XML Schema 199 200 205 206 207 208 210 212 214 215 217 218 219 220 221 222 224 226 3.2 Example POTS Line PIDF document 228 229 232 233 234 closed 235 236 in-call 237 available 238 239 240 tel:+09012345678 241 242 244 4. Enterprise Phone State 246 Many enterprise telephone networks utilize private branch exchanges 247 (PBXs) that allow phones more functionality than Plain Old Telephone 248 Service. PBXs typically have a signaling interface to a telephone 249 switch that runs over an ISDN Primary Rate Interface (PRI) line, 250 rather than the audio interface supported by a blackphone. Many 251 enterprise phones themselves also have digital signalling interfaces 252 to the PBXs. 254 As a result, many enterprise phones can support multiple lines, call 255 transfer capabilities and other sophisticated features. Moreover, 256 many private branch exchange switches have an integrated voicemail 257 capability for all connected terminals. 259 [[EDITOR's NOTE: Need more input on enterprise devices.]] 261 call-state: This element indicates the state of any calls made by, or 262 received by, the phone. 264 4.1 Enterprise Phone XML Schema 265 266 272 273 275 276 277 279 281 282 284 285 286 288 290 292 293 295 297 4.2 Enterprise Phone PIDF Document Example 299 300 303 304 305 closed 306 307 308 Line 1 309 not-in-call 310 311 312 Line 2 313 not-in-call 314 315 316 Line 3 317 ringing 318 319 320 321 tel:+09012345678 322 323 325 5. Wireless Phone State 327 Wireless phones refer to mobile devices that have no wired connection 328 to a network, and can change their attachment point to the network at 329 any point (including while a user is in the middle of a call). This 330 includes phones on the GSM, CDMA, TDMA, GPRS, CDMA2000, and WCDMA 331 networks, along WiFi phones as well. 333 Some of these devices do not support data interfaces to the network, 334 and therefore may not be able to directly publish their own state to 335 a presence agent (many do support SMS, which can be used as a vehicle 336 for published presence state). However, most aspects of the phone 337 state can be derived from network elements, such as the Home Location 338 Register (HLR) and Visiting Location Register (VLR). We therefore 339 focus on state derivable by these entities. 341 Wireless phone status is represented by several XML elements. The 342 namespace URI for elements that represent wireless phone state is a 343 URN [3], using the namespace identifier 'ietf' defined by [4] and 344 extended by [5]. This URN is: 346 urn:ietf:params:xml:ns:pidf:wireless-phone-state 348 We have selected elements which generally represent dynamic state, 349 and which include information that would generally be helpful to a 350 user in deciding whether to make a call. These elements are: 352 barred: This element indicates whether the phone has been barred from 353 registered in the visiting network, due to a lack of roaming 354 agreements or policy that explicitly disallows roaming. 356 call-state: This element indicates the state of any calls made by, or 357 received by, the phone. There is no attempt to support devices 358 which can have multiple calls, each with its own state. 360 data-state: This element indicates whether the phone is connected to 361 a wireless data network, such as GPRS or CDMA1xRTT. The phone is 362 considered connected if, at that time, it is capable of sending 363 and receiving data packets. In some phones, this state is dynamic, 364 since users need to explicitly connect and disconnect. In others, 365 the phone is connected to the data network as long as its 366 registered. The values of this element can be not-connected and 367 connected. 369 ran: This element indicates the current radio access network (RAN) to 370 which the user is connected. The values of this element can be 371 GSM, GPRS, CDMA, CDMA2000, UMTS-PS, UMTS-CS, AMPS, NMT, PDC, TDMA, 372 CDPD, or WiFi, Mobitex, HS-CSD, and IDEN. Additional values can be 373 defined in the future. The "registered" attribute of the element 374 indicates whether the phone has registered on that network. 376 roaming: This element indicates whether or not the phone is currently 377 roaming. It is an XML boolean. 379 home-network: This element is a textual string which indicates the 380 home network provider for the phone. Here, "network provider" 381 refers to the provider of call control and signaling services. 383 visited-network: This element is a textual string which indicates the 384 visited network provider for the phone. Here, "network provider" 385 refers to the provider of call control and signaling services. 387 signal-strength: This element is a number between 0 and 5 which 388 indicates the signal strength for the phone. A 5 means excellent, 389 and a 0 means no signal. This information is likely to change 390 frequently, and it should be included in notifications with great 391 care. 393 5.1 XML Schema 395 396 403 404 405 406 407 408 409 410 411 412 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 461 5.2 Example Presence Document 463 The following presence document indicates that the user has a single 464 contact which represents a phone. This is a wireless phone on the GSM 465 network. The phone is roaming, and the user is in a call. The fact 466 that they are in a call results in the basic status being set to 467 closed. 469 470 473 474 475 closed 476 477 gsm 478 true 479 in-call 480 481 482 tel:+09012345678 483 484 486 6. Security Considerations 488 Phone state, like other presence state, represents sensitive 489 information. It conveys detailed information about what a user is 490 doing, and potentially where they are. Users may therefore wish to 491 have this information hidden from eavesdroppers. Encryption of this 492 presence data is provided by the underlying protocol that carriers 493 this document. It is RECOMMENDED that presence documents conveying 494 phone status only be transported with protocols that can provide 495 encryption. For example, SIP extensions for presence [9] can provide 496 encryption. 498 Users may also wish to control who can have access to phone state 499 information. Users can control the type of information conveyed to 500 watchers of their presence using a data manipulation protocol, as 501 described in [8]. The protocol used for such a purpose is the XML 502 Configuration Access Protocol (XCAP) [10]. An XCAP application usage 503 has been specified for setting authorization policy [11]. This 504 mechanism allows a user to enable or disable access to presence 505 information on a namespace by namespace basis. Therefore, to prevent 506 phone state information from being distributed, users would remove 507 permissions for viewing the namespaces defined in this specification. 509 7. IANA Considerations 511 There are several IANA considerations associated with this 512 specification. 514 7.1 URN Sub-Namespace Registrations 515 This section registers three new XML namespaces, as per the 516 guidelines in [5]. 518 7.1.1 urn:ietf:params:xml:ns:pidf:common-phone 520 URI: The URI for this namespace is 521 urn:ietf:params:xml:ns:pidf:common-phone-state. 523 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 524 Jonathan Rosenberg (jdrosen@jdrosen.net). 526 XML: 528 BEGIN 529 530 532 533 534 536 Common Phone State Namespace 537 538 539

Namespace for Common Phone State

540

urn:ietf:params:xml:ns:pidf:common-phone

541

See RFCXXXX.

542 543 544 END 546 7.1.2 urn:ietf:params:xml:ns:pidf:wireless-phone-state 548 URI: The URI for this namespace is 549 urn:ietf:params:xml:ns:pidf:wireless-phone-state. 551 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 552 Jonathan Rosenberg (jdrosen@jdrosen.net). 554 XML: 556 BEGIN 557 558 560 561 562 564 Wireless Phone State Namespace 565 566 567

Namespace for Wireless Phone State

568

urn:ietf:params:xml:ns:pidf:wireless-phone-state

569

See RFCXXXX.

570 571 572 END 574 7.1.3 urn:ietf:params:xml:ns:pidf:pls 576 URI: The URI for this namespace is 577 urn:ietf:params:xml:ns:pidf:pls. 579 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 580 Jon Peterson (jon.peterson@neustar.biz). 582 XML: 584 BEGIN 585 586 588 589 590 592 POTS Line State Namsepace 593 594 595

Namespace for POTS Line State

596

urn:ietf:params:xml:ns:pidf:pls

597

See RFCXXXX.

598 599 600 END 602 7.1.4 urn:ietf:params:xml:ns:pidf:eps 604 URI: The URI for this namespace is 605 urn:ietf:params:xml:ns:pidf:eps. 607 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 608 Jon Peterson (jon.peterson@neustar.biz). 610 XML: 612 BEGIN 613 614 616 617 618 620 Enterprise Phone State Namsepace 621 622 623

Namespace for Enterprise Phone State

624

urn:ietf:params:xml:ns:pidf:eps

625

See RFCXXXX.

626 627 628 END 630 7.2 Schema Registrations 632 This specification registers four schemas, as per the guidelines in 633 in [5]. 635 7.2.1 Common Phone State 637 URI: please assign. 639 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 640 Jon Peterson (jon.peterson@neustar.biz). 642 XML: The XML can be found as the sole content of Section 2.1. 644 7.2.2 POTS Line State 645 URI: please assign. 647 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 648 Jon Peterson (jon.peterson@neustar.biz). 650 XML: The XML can be found as the sole content of Section 3.1. 652 7.2.3 Enterprise Phone State 654 URI: please assign. 656 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 657 Jon Peterson (jon.peterson@neustar.biz). 659 XML: The XML can be found as the sole content of Section 4.1. 661 7.2.4 Wireless Phone State 663 URI: please assign. 665 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 666 Jonathan Rosenberg (jdrosen@jdrosen.net). 668 XML: The XML can be found as the sole content of Section 5.1. 670 8. Acknowledgments 672 The authors would like to thank Rob Allen, Adam Roach and Mark Peck 673 for their comments on this specification. 675 Normative References 677 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 678 Levels", BCP 14, RFC 2119, March 1997. 680 [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 681 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC 682 REC-xml-20001006, October 2000. 684 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 686 [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 687 August 1999. 689 [5] Mealling, M., "The IETF XML Registry", 690 draft-mealling-iana-xmlns-registry-05 (work in progress), June 691 2003. 693 [6] Fujimoto, S. and H. Sugano, "Presence Information Data Format 694 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 695 2003. 697 Informative References 699 [7] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 700 Instant Messaging", RFC 2778, February 2000. 702 [8] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of 703 Data Elements in Session Initiation Protocol (SIP) for Instant 704 Messaging and Presence Leveraging Extensions (SIMPLE) Systems", 705 draft-ietf-simple-data-req-02 (work in progress), April 2003. 707 [9] Rosenberg, J., "A Presence Event Package for the Session 708 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 709 in progress), January 2003. 711 [10] Rosenberg, J., "The Extensible Markup Language (XML) 712 Configuration Access Protocol (XCAP)", 713 draft-rosenberg-simple-xcap-00 (work in progress), May 2003. 715 [11] Rosenberg, J., "An Extensible Markup Language (XML) 716 Configuration Access Protocol (XCAP) Usage for Presence 717 Authorization", draft-ietf-simple-xcap-auth-usage-00 (work in 718 progress), June 2003. 720 Authors' Addresses 722 Jonathan Rosenberg 723 dynamicsoft 724 600 Lanidex Plaza 725 Parsippany, NJ 07054 726 US 728 Phone: +1 973 952-5000 729 EMail: jdrosen@dynamicsoft.com 730 URI: http://www.jdrosen.net 731 Jon Peterson 732 Neustar 733 1800 Sutter Street 734 Suite 570 735 Concord, CA 94520 736 US 738 Phone: +1 925 363-8720 739 EMail: jon.peterson@neustar.biz 740 URI: http://www.neustar.biz 742 Intellectual Property Statement 744 The IETF takes no position regarding the validity or scope of any 745 intellectual property or other rights that might be claimed to 746 pertain to the implementation or use of the technology described in 747 this document or the extent to which any license under such rights 748 might or might not be available; neither does it represent that it 749 has made any effort to identify any such rights. Information on the 750 IETF's procedures with respect to rights in standards-track and 751 standards-related documentation can be found in BCP-11. Copies of 752 claims of rights made available for publication and any assurances of 753 licenses to be made available, or the result of an attempt made to 754 obtain a general license or permission for the use of such 755 proprietary rights by implementors or users of this specification can 756 be obtained from the IETF Secretariat. 758 The IETF invites any interested party to bring to its attention any 759 copyrights, patents or patent applications, or other proprietary 760 rights which may cover technology that may be required to practice 761 this standard. Please address the information to the IETF Executive 762 Director. 764 Full Copyright Statement 766 Copyright (C) The Internet Society (2003). All Rights Reserved. 768 This document and translations of it may be copied and furnished to 769 others, and derivative works that comment on or otherwise explain it 770 or assist in its implementation may be prepared, copied, published 771 and distributed, in whole or in part, without restriction of any 772 kind, provided that the above copyright notice and this paragraph are 773 included on all such copies and derivative works. However, this 774 document itself may not be modified in any way, such as by removing 775 the copyright notice or references to the Internet Society or other 776 Internet organizations, except as needed for the purpose of 777 developing Internet standards in which case the procedures for 778 copyrights defined in the Internet Standards process must be 779 followed, or as required to translate it into languages other than 780 English. 782 The limited permissions granted above are perpetual and will not be 783 revoked by the Internet Society or its successors or assignees. 785 This document and the information contained herein is provided on an 786 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 787 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 788 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 789 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 790 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Acknowledgement 794 Funding for the RFC Editor function is currently provided by the 795 Internet Society.