| TOC |
|
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 22, 2003.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document presents extensions to the Presence Information Document Format (PIDF) for representing the state of telephones. This state includes whether the telephone is in a call or not, whether it is registered to the network, whether it is ringing, and so on.
| TOC |
| TOC |
The Presence Information Document Format (PIDF) [6] provides a baseline set of presence information that allows a presentity[7] to inform a watcher about itself. Information about a presentity is broken into a set of tuples. Each tuple represents a point of contact for a presentity. The tuple includes a URI that can be used to reach the presentity, a basic status of either open or closed, and a textual note meant for consumption by a human.
PIDF is meant to be extended to provide additional information about presentities. In this specification, we define extensions to PIDF that allow a tuple to represent a telephone, or any device with telephone-like behaviors. Specifically, a telephone is any piece of hardware or software that is capable of making and/or receiving real time media streams with another such device.
Most telephones in the world today lack Internet connections, and communicate only through the Public Switched Telephone Network (PSTN). The presence for telephones described in this document might therefore be created by a telephone switch or other agent responsible for managing dumb telephones when the telephones themselves lack the intelligence to generate or disseminate presence information. That much said, these presence extensions are also servicable for representing Internet telephones.
| TOC |
While the presence states associated with wireless phones, POTS phones and enterprise PBX phones do vary, there are certain pieces of presence state that are common to all. In particular, the notion of call state is common across all three types. As such, we specify a common XML schema for describing call state. The namespace URI for elements that represent common presence state across phones is a URN[3], using the namespace identifier 'ietf' defined by [4] and extended by [5]. This URN is:
- urn:ietf:params:xml:ns:pidf:common-phone-state
The elements defined in this schema are:
- call-state:
- This element indicates the state of any calls made by, or received by, the phone. The possible values of this element are:
- not-in-call:
- The phone is not in a call.
- dialing:
- The phone is attempting to initiate a call. This state includes the entry of digits by the user and the subsequent signaling into the network.
- ringing:
- The phone has initiated a call, and has received ringback from the called party.
- alerting:
- The phone has received a call, and is alerting the user.
- in-call:
- The phone is in an active call.
- in-error:
- The call could not be completed because of some kind of error, such as all-circuits-busy.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:common-phone"
xmlns:tns="urn:ietf:params:xml:ns:pidf:common-phone"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:simpleType name="call-stateType">
<xs:restriction base="xs:string">
<xs:enumeration value="not-in-call"/>
<xs:enumeration value="dialing"/>
<xs:enumeration value="alerting"/>
<xs:enumeration value="ringing"/>
<xs:enumeration value="in-call"/>
<xs:enumeration value="in-error"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="call-state" type="tns:call-stateType"/>
</xs:schema>
| TOC |
Plain Old Telephone Service (POTS) is a term used to denote the lowest common denominator of functionality among end terminals in the PSTN. A POTS phone (or "black" phone in common parlance) is usually a device with a numeric (multifrequency or rotary) user interface which may or may not support a visual display.
POTS devices are not intelligent endpoints - their primary function is to render and receive audio information (in the form of dialing information, human speech or other audible tones) over their connection to a telephone switch. As such, a POTS phone by definition cannot create a presence document and communicate it to the switching infrastructure. The telephone switch to which a POTS phone connects, however, could create a presence document representing the state of the line.
Due to the nature of POTS lines, the switching infrastructure has no reliable way to determine whether zero, one or more terminals have been connected to a single telephone line - thus a presence document generated by the switching infrastructure cannot be know with any certainty to correspond to a particular telephone. As such, we term it "POTS line state" rather than "POTS phone state".
To integrate the call state of a POTS line into PIDF, we specify a two elements that extend the status element of baseline PIDF:
- call-state:
- This element indicates the state of any calls made by, or received by, the phone.
- call-waiting:
- This element is used when the call state is 'in-call' only. It signifies whether or not the call is progress is interruptable by call waiting. If the call is interruptable, the value of this element should be "available". If the call waiting feature is not available on the line, or is already occupied by another caller, the value of this element should be "unavailable". If this element is not present, and the call state is 'in-call', the value is assumed to be "unavailable".
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:pls"
xmlns:tns="urn:ietf:params:xml:ns:pidf:pls"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="pots-line-state" type="tns:pots-line-stateType"/>
<xs:complexType name="pots-line-stateType">
<xs:sequence>
<xs:any namespace="urn:ietf:params:xml:ns:pidf:common-phone"
minOccurs="1" maxOccurs="1"/>
<xs:element name="call-waiting" type="tns:call-waitingType"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="call-waitingType">
<xs:restriction base="xs:string">
<xs:enumeration value="available"/>
<xs:enumeration value="unavailable"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:ph="urn:ietf:params:xml:ns:pidf:pls"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>closed</basic>
<ph:pots-line-state>
<ph:call-state>in-call</ph:call-state>
<ph:call-waiting>available</ph:call-waiting>
</ph:pots-line-state>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
| TOC |
Many enterprise telephone networks utilize private branch exchanges (PBXs) that allow phones more functionality than Plain Old Telephone Service. PBXs typically have a signaling interface to a telephone switch that runs over an ISDN Primary Rate Interface (PRI) line, rather than the audio interface supported by a blackphone. Many enterprise phones themselves also have digital signalling interfaces to the PBXs.
As a result, many enterprise phones can support multiple lines, call transfer capabilities and other sophisticated features. Moreover, many private branch exchange switches have an integrated voicemail capability for all connected terminals.
- [[EDITOR's NOTE: Need more input on enterprise devices.]]
- call-state:
- This element indicates the state of any calls made by, or received by, the phone.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:eps"
xmlns:tns="urn:ietf:params:xml:ns:pidf:eps"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cps="urn:ietf:params:xml:ns:pidf:common-phone"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:pidf:common-phone"/>
<xs:element name="enterprise-phone-state"
type="tns:enterprise-phone-stateType"/>
<xs:complexType name="enterprise-phone-stateType">
<xs:sequence>
<xs:element name="line" type="tns:lineType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="lineType">
<xs:sequence>
<xs:element name="line-name" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="line-state" type="cps:call-stateType"
minOccurs="1" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:ph="urn:ietf:params:xml:ns:pidf:eps"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>closed</basic>
<ph:enterprise-phone-state>
<ph:line>
<ph:line-name>Line 1</ph:line-name>
<ph:line-state>not-in-call</ph:line-state>
</ph:line>
<ph:line>
<ph:line-name>Line 2</ph:line-name>
<ph:line-state>not-in-call</ph:line-state>
</ph:line>
<ph:line>
<ph:line-name>Line 3</ph:line-name>
<ph:line-state>ringing</ph:line-state>
</ph:line>
</ph:enterprise-phone-state>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
| TOC |
Wireless phones refer to mobile devices that have no wired connection to a network, and can change their attachment point to the network at any point (including while a user is in the middle of a call). This includes phones on the GSM, CDMA, TDMA, GPRS, CDMA2000, and WCDMA networks, along WiFi phones as well.
Some of these devices do not support data interfaces to the network, and therefore may not be able to directly publish their own state to a presence agent (many do support SMS, which can be used as a vehicle for published presence state). However, most aspects of the phone state can be derived from network elements, such as the Home Location Register (HLR) and Visiting Location Register (VLR). We therefore focus on state derivable by these entities.
Wireless phone status is represented by several XML elements. The namespace URI for elements that represent wireless phone state is a URN[3], using the namespace identifier 'ietf' defined by [4] and extended by [5]. This URN is:
- urn:ietf:params:xml:ns:pidf:wireless-phone-state
We have selected elements which generally represent dynamic state, and which include information that would generally be helpful to a user in deciding whether to make a call. These elements are:
- barred:
- This element indicates whether the phone has been barred from registered in the visiting network, due to a lack of roaming agreements or policy that explicitly disallows roaming.
- call-state:
- This element indicates the state of any calls made by, or received by, the phone. There is no attempt to support devices which can have multiple calls, each with its own state.
- data-state:
- This element indicates whether the phone is connected to a wireless data network, such as GPRS or CDMA1xRTT. The phone is considered connected if, at that time, it is capable of sending and receiving data packets. In some phones, this state is dynamic, since users need to explicitly connect and disconnect. In others, the phone is connected to the data network as long as its registered. The values of this element can be not-connected and connected.
- ran:
- This element indicates the current radio access network (RAN) to which the user is connected. The values of this element can be GSM, GPRS, CDMA, CDMA2000, UMTS-PS, UMTS-CS, AMPS, NMT, PDC, TDMA, CDPD, or WiFi, Mobitex, HS-CSD, and IDEN. Additional values can be defined in the future. The "registered" attribute of the element indicates whether the phone has registered on that network.
- roaming:
- This element indicates whether or not the phone is currently roaming. It is an XML boolean.
- home-network:
- This element is a textual string which indicates the home network provider for the phone. Here, "network provider" refers to the provider of call control and signaling services.
- visited-network:
- This element is a textual string which indicates the visited network provider for the phone. Here, "network provider" refers to the provider of call control and signaling services.
- signal-strength:
- This element is a number between 0 and 5 which indicates the signal strength for the phone. A 5 means excellent, and a 0 means no signal. This information is likely to change frequently, and it should be included in notifications with great care.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:wireless-phone-state"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:pidf:wireless-phone-state"
xmlns:cps="urn:ietf:params:xml:ns:pidf:common-phone"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:pidf:common-phone"/>
<xs:element name="wireless-phone-state" type="tns:wpsType"/>
<xs:complexType name="wpsType">
<xs:sequence>
<xs:element name="data-state" type="tns:data-stateType" minOccurs="0"/>
<xs:element name="ran" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="tns:ranType">
<xs:attribute name="registered" type="xs:boolean"
use="optional" default="true"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="visited-network" type="xs:string" minOccurs="0"/>
<xs:element name="home-network" type="xs:string" minOccurs="0"/>
<xs:element name="roaming" type="xs:boolean" minOccurs="0"/>
<xs:element name="signal-strength" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="5"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="call-state" type="cps:call-stateType" minOccurs="0"/>
<xs:element name="barred" type="xs:boolean" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="data-stateType">
<xs:restriction base="xs:string">
<xs:enumeration value="not-connected"/>
<xs:enumeration value="connected"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ranType">
<xs:restriction base="xs:string">
<xs:enumeration value="cdma2000"/>
<xs:enumeration value="gsm"/>
<xs:enumeration value="cdma"/>
<xs:enumeration value="umts-cs"/>
<xs:enumeration value="umts-ps"/>
<xs:enumeration value="amps"/>
<xs:enumeration value="nmt"/>
<xs:enumeration value="pdc"/>
<xs:enumeration value="tdma"/>
<xs:enumeration value="cdpd"/>
<xs:enumeration value="wifi"/>
<xs:enumeration value="gprs"/>
<xs:enumeration value="mobitex"/>
<xs:enumeration value="hs-csd"/>
<xs:enumeration value="iden"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
The following presence document indicates that the user has a single contact which represents a phone. This is a wireless phone on the GSM network. The phone is roaming, and the user is in a call. The fact that they are in a call results in the basic status being set to closed.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:ph="urn:ietf:params:xml:ns:pidf:wireless-phone-state"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>closed</basic>
<ph:wireless-phone-state>
<ph:ran registered="true">gsm</ph:ran>
<ph:roaming>true</ph:roaming>
<ph:call-state>in-call</ph:call-state>
</ph:wireless-phone-state>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
| TOC |
Phone state, like other presence state, represents sensitive information. It conveys detailed information about what a user is doing, and potentially where they are. Users may therefore wish to have this information hidden from eavesdroppers. Encryption of this presence data is provided by the underlying protocol that carriers this document. It is RECOMMENDED that presence documents conveying phone status only be transported with protocols that can provide encryption. For example, SIP extensions for presence[9] can provide encryption.
Users may also wish to control who can have access to phone state information. Users can control the type of information conveyed to watchers of their presence using a data manipulation protocol, as described in [8]. The protocol used for such a purpose is the XML Configuration Access Protocol (XCAP)[10]. An XCAP application usage has been specified for setting authorization policy[11]. This mechanism allows a user to enable or disable access to presence information on a namespace by namespace basis. Therefore, to prevent phone state information from being distributed, users would remove permissions for viewing the namespaces defined in this specification.
| TOC |
There are several IANA considerations associated with this specification.
This section registers three new XML namespaces, as per the guidelines in [5].
- URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:common-phone-state.
- Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
- XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Common Phone State Namespace</title>
</head>
<body>
<h1>Namespace for Common Phone State</h1>
<h2>urn:ietf:params:xml:ns:pidf:common-phone</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
- URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:wireless-phone-state.
- Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
- XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Wireless Phone State Namespace</title>
</head>
<body>
<h1>Namespace for Wireless Phone State</h1>
<h2>urn:ietf:params:xml:ns:pidf:wireless-phone-state</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
- URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:pls.
- Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz).
- XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>POTS Line State Namsepace</title>
</head>
<body>
<h1>Namespace for POTS Line State</h1>
<h2>urn:ietf:params:xml:ns:pidf:pls</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
- URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:eps.
- Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz).
- XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Enterprise Phone State Namsepace</title>
</head>
<body>
<h1>Namespace for Enterprise Phone State</h1>
<h2>urn:ietf:params:xml:ns:pidf:eps</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
This specification registers four schemas, as per the guidelines in in [5].
- URI: please assign.
- Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz).
- XML: The XML can be found as the sole content of XML Schema.
- URI: please assign.
- Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz).
- XML: The XML can be found as the sole content of POTS line XML Schema.
- URI: please assign.
- Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz).
- XML: The XML can be found as the sole content of Enterprise Phone XML Schema.
- URI: please assign.
- Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
- XML: The XML can be found as the sole content of XML Schema.
| TOC |
The authors would like to thank Rob Allen, Adam Roach and Mark Peck for their comments on this specification.
| TOC |
| [1] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [2] | Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000. |
| [3] | Moats, R., "URN Syntax", RFC 2141, May 1997 (TXT, HTML, XML). |
| [4] | Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. |
| [5] | Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003. |
| [6] | Fujimoto, S. and H. Sugano, "Presence Information Data Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. |
| TOC |
| [7] | Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. |
| [8] | Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems", draft-ietf-simple-data-req-02 (work in progress), April 2003. |
| [9] | Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), January 2003. |
| [10] | Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-rosenberg-simple-xcap-00 (work in progress), May 2003. |
| [11] | Rosenberg, J., "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Authorization", draft-ietf-simple-xcap-auth-usage-00 (work in progress), June 2003. |
| TOC |
| Jonathan Rosenberg | |
| dynamicsoft | |
| 600 Lanidex Plaza | |
| Parsippany, NJ 07054 | |
| US | |
| Phone: | +1 973 952-5000 |
| EMail: | jdrosen@dynamicsoft.com |
| URI: | http://www.jdrosen.net |
| Jon Peterson | |
| Neustar | |
| 1800 Sutter Street | |
| Suite 570 | |
| Concord, CA 94520 | |
| US | |
| Phone: | +1 925 363-8720 |
| EMail: | jon.peterson@neustar.biz |
| URI: | http://www.neustar.biz |
| TOC |
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.