RFC 2458
Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations
Pages: 60
Informational
Informational
Part 3 of 3 – Pages 43 to 60
7. Session Initiation Protocol--An Emerging Standard 7.1 Overview SIP, the Session Initiation Protocol, is a simple signaling protocol for Internet conferencing and telephony. It is currently under development within the IETF MMUSIC (Multiparty Multimedia Session Control) Working Group. SIP provides the necessary mechanisms to support the following services: - call forwarding, including the equivalent of 700-, 800- and 900- type calls; - call-forwarding no answer;
- call-forwarding busy;
- call-forwarding unconditional;
- other address-translation services;
- callee and calling "numbers" delivery, where the numbers can be of
any (preferably unique) naming scheme;
- personal mobility, i.e., the ability to reach a called party under
a single, location-independent address, even when the user changes
terminals;
- terminal-type negotiation and selection: a caller can be given a
choice of how to reach a party, e.g., via Internet telephony,
mobile, phone, and an answering service;
- caller and callee authentication;
- blind and supervised call transfer;
- user location; and
- invitation to multicast conferences.
Extensions of SIP to allow third-party signaling (e.g., for click-
to-dial-back services, fully meshed conferences and connections to
Multipoint Control Units (MCUs), as well as mixed modes and the
transition between those) have been specified.
SIP addresses (URLs) can be embedded in Web pages. SIP is
addressing-neutral, with addresses expressed as URLs of various types
such as SIP, H.323 or telephone (E.164). A purely representational
example of a SIP URL might be sip:+12125551212@foo.example.com, where
foo.example.com is the host serving as a gateway into the PSTN.
SIP is independent of the packet layer and only requires an
unreliable datagram service, as it provides its own reliability
mechanism. While SIP typically is used over UDP or TCP, it could,
without technical changes, be run over IPX, or carrier pigeons, ATM
AAL5 or X.25, in rough order of desirability.
SIP can set up calls "out-of-band". For example, while the SIP
protocol exchanges use IP, plus UDP or TCP, the actual data transport
can take place via the PSTN. This feature makes it possible to use
SIP to control a PBX or send requests to a Service Control Point. The
PINT services make use of this flexibility.
7.2 SIP Protocol
SIP is a textual client-server protocol, similar in syntax to HTTP
and RTSP. Requests consist of a method (INVITE, BYE, ACK, or
REGISTER), a list of parameter-value pairs describing the request and
an optional request body. Parameters include the origin and
destination of the call and a unique call identifier. They may
indicate the caller's organization as well as the call's subject and
priority. The request body contains a description of the call to be
established or the conference to be joined. The description format is not prescribed by SIP; SDP is one possibility being standardized within the IETF. For the purposes of providing PINT services, an additional phone number address format is to be added to SDP. Responses indicate whether a request is still being processed, was successful, can possibly be satisfied by another node or failed. When a call is redirected, the response indicates the name of the node to be tried. Unsuccessful calls may also return a better time to try again. In a typical successful call, the caller sends an INVITE request to the callee. The callee accepts the call by returning a response code to the callee, which then confirms the receipt of that acceptance with an ACK request. Either side can terminate the call by sending a BYE request. Requests can be authenticated using standard HTTP password and challenge-response mechanisms. Requests and responses may also be signed and encrypted. 7.3 SIP entities SIP distinguishes three kinds of entities: User agents receive and initiate calls and may forward the call. A proxy server is an intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy must interpret, and, if necessary, rewrite a request message before forwarding it. A proxy server may, for example, locate a user and then attempt one or more possible network addresses. Redirect server accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server, it does not initiate its own SIP request. Unlike a user agent server, it does not accept calls. Proxy and redirect servers may make use of location servers that determine the current likely location of the callee. A PSTN gateway initiates phone calls between two parties. This may be a server that sends requests to an SCP in an IN environment or it may be a CTI-controlled PBX. A SIP call may traverse one or more proxy servers.
The servers that control a PBX or an SCP act as user agents. A Web server may also act as a SIP user agent. 7.4 Providing Call Control Functionality The SIP for PINT specification provides details on how to use SIP to initiate phone calls between two PSTN end points. (SIP can also initiate calls between Internet end points and between an Internet and PSTN end point, but this is beyond the scope of this document.) It should be noted that the SIP client for initiating such phone calls can be either at the user's location (his/her workstation) or can be a Web server that calls up a SIP client via a CGI program. There is no difference in operation or functionality, except that the owner of the Web server may be legally responsible for the calls made. A SIP client needs to convey two addresses to the PSTN gateway: the party making the call and the party to be called. (The party to be billed also needs to be identified; this can either be done by a SIP header or by having the server look up the appropriate party based on the two parties. This aspect is for further study.) Described below are three ways these addresses can be conveyed in SIP. In the example, the address of party A is +1-212-555-1234 and that of party B is +1-415-555-1200. (The URL types in this and other examples are representational; they may but do not have to exist.) (1) The two PSTN addresses are contained in the To header (and request-URI) and an Also header. For example: INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0 To: phone:1-212-555-1234 From: sip:j.doe@example.com Content-type: application/sdp Call-ID: 19970721T135107.25.181@foo.bar.com Also: phone:+1-415-555-1200 v=0 o=user1 53655765 2353687637 IN IP4 128.3.4.5 c=PSTN E.164 +1-415-555-1200 t=0 0 m=audio 0 RTP/AVP 0 In that case, the gateway first connects to party A and then party B, but without waiting for A to accept the call before calling B.
(2) Parties A and B are indicated by separate invitations. This
allows the gateway to make sure that party A is indeed available
before calling party B. After calling party A, the gateway could
play an announcement indicating that the call is being connected
using, for example, RTSP with appropriate Conference header
indicating the call.
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
...
INVITE sip:+1-415-555-1200@pbx.example.com SIP/2.0
To: phone:+1-415-555-1200
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
...
(3) The two PSTN addresses are conveyed in the To header of the SIP
request and the address in the SDP media description. Thus, a request
may look as follows:
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200
t=0 0
m=audio 0 RTP/AVP 0
Here, pbx.example.com is the name of the PSTN gateway; the call will
be established between 1-212-555-1234 and +1-415-555-1200.
Users can be added to an existing call by method (1) or (2).
8. Overall Security Considerations
Inter-networking of the Internet and PSTN necessitates the
introduction of new interfaces (e.g., the A, B and E interfaces in
Figure 6). To ensure that their use does not put the networks, in
particular the PSTN, at additional security risk, these interfaces
need to be designed with proper security considerations. Sections
5.1.5 and 5.2.2.7 describe how two of the pre-PINT implementations, the Lucent and Siemens systems, handle the security aspect, respectively. Worth noting are the security requirements suggested by pre-PINT experiences. They are: +Peer entity authentication to allow a communicating entity to prove its identity to another in the network (e.g., the requesting IP-host to the PINT gateway, and the PINT gateway to the PSTN node providing the service control function). +Authorization and access control to verify if a network entity (e.g., the requesting IP-host) is allowed to use a network resource (e.g., requesting services from the PINT gateway). +Non-repudiation to account for all operations in case of doubt or dispute. +Confidentiality to avoid disclosure of information (e.g., the end user profile information and data) without the permission of its owner. In the course of the PINT interface development, additional requirements are likely to arise. It is imperative that the resultant interfaces include specific means to meet all the security requirements. 9. Conclusion This document has provided the information relevant to the development of inter-networking interfaces between the PSTN and Internet for supporting PINT services. Specifically, it addressed technologies, architectures, and several existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of the PINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services. 10. Acknowledgments The authors would like to acknowledge Scott Bradner, Igor Faynberg, Dave Oran, Scott Petrack, Allyn Romanow for their insightful comments presented to the discussions in the PINT Working Group that lead to the creation of this document.
11. Appendix 11.1 PSTN/IN 101 11.1.1 Public Switched Telephone Network What is normally considered as "the Telephone Network" consists of a set of interconnected networks. Potentially, each of these networks could be owned by a different Network Operator. The official name for such a network is Public Switched Telecommunications Network (PSTN). A simple PSTN consists of a set of Switches (called Central Offices or Telephone Exchanges) with links interconnecting them to make up the network, along with a set of access connections by which terminals are attached. The PSTN is used to deliver calls between terminals connected to itself or to other PSTNs with which it is interconnected. Calls on the PSTN are circuit switched; that is, a bi-directional connection is made between the calling and called terminals for the duration of the call. In PSTNs the connection is usually carried through the network in digital format occupying a fixed bandwidth; this is usually 56 or 64 Kbps. The overall configuration of the PSTN is shown in Figure 16. /--\ ()/\()__ /__\ \ ................................. \ ! ! ! /--\ __ \ [-!-] [-!-] ! ()/\() \ \ \__[CO ]=========[CO ]==\\ ! ___/__\ [Fax]________[---] [---] \\ [-!-] / __ \\=======[CO ]____/ \ \ [---]________[Fax] Key: ___ Access Lines === Trunk Links (inter-CO user data links) ... Inter-CO signaling network links Figure 16 Messages are sent between the Switches to make and dissolve connections through the network on demand and to indicate the status of terminals involved in a call; these "signaling" messages are carried over a separate (resilient) data network dedicated to this purpose. This signaling network is also known as the Common Channel Signaling (CCS) or Signaling System Number 7 (or SS7) network after the names of the signaling protocol suite used. As yet, the majority of access connections to a PSTN carry analogue signals, with simple (analogue) telephones or Facsimile machines as terminals. Call requests are indicated to the Central Office to which
a telephone is connected either by a sequence of pulses or tone pairs
being sent. Notifications on the status of the request are sent back
to the telephone in the form of tones. Indication from a Central
Office that a call is being offered to a telephone is arranged by
sending an alternating voltage down the access connection which in
turn causes the ringer in the telephone to sound. These access lines
have a unique address associated with them and can support a single
call.
However, with analogue or digital multi-line connections, or
Integrated Service Digital Network (ISDN) Basic or Primary Rate
Interfaces (BRI or PRI), several concurrent calls are possible and a
set of addresses are associated with them. The new ISDN access
connections are designed so that data exchanged with the network is
in multiplexed digital form, and there is an individual channel for
each of the potential connections, together with a separate channel
dedicated to sending and receiving call request and call alert data
as well as carrying packet switched user data. These call request and
call alert messages act as the equivalent of the pulses or tones that
are sent when dialing, and the ringing signal that is sent to a
telephone when a call is being made to it.
The operation of the call request is fairly simple in most cases and
is shown in Figure 17.
/--\
() ()
--____
/++\ \ ................................. /--\
/----\ \ ^ v ! () ()
A \ [-!-] [-!-] ! --
\->[CO ]=========[CO ]==\\ v ->-/ \
[---] [---] \\ [-!-] / /----\
\\=======[CO ]____/ B
[---]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
Figure 17
The user presses a sequence of numbers on a telephone handset
(labeled A), and the telephone passes a sequence of digits (either as
pulses or tone pairs) to the Central Office via the access line. The
Central Office contains a processor that will be notified that the
user has made a request and the digit string that is the sole
parameter of the request. This digit string is taken to be the unique
address of an access line connected either to itself or to another Central Office. There is a hierarchical addressing scheme, so that the digit string can be parsed easily. A call request to a terminal (labeled B) connected to a remote Central Office can be routed by examining the digit string passed; the Central Office will extract the part of the passed address that corresponds to the remote Central Office in question, and can route the request onward, forming an inter-Switch call request and passing it via the signaling network. At the same time it will allocate one of its available transmission channels towards the remote Central Office. 11.1.2 Intelligent Network This scheme has been used since the 1950s, and suffices for the majority of calls. However, there are a range of other services that can be (and have been) provided, enhancing this basic call processing. Freephone or Premium Rate services (1-800 or 1-900 services) are good examples of the supplementary services that have been introduced. Apart from the important feature that the cost of these calls is varied so that the caller does not pay for a free- phone call, or pays an extra charge for a premium rate call, they have the similarity that the number dialed must be translated to arrive at the "real" address of the destination terminal. They are known as number translation services, and make up the bulk of all supplementary services delivered today. These were originally programmed into each Central Office, but the complexity of maintaining the data tables on each processor grew cumbersome, so a more general solution was sought. After a considerable gestation period, the eventual solution was the Intelligent Network. This takes the separation of Central Offices and the network links interconnecting them a stage further. The Central Offices are considered to provide the Call Control Function (CCF). In addition, the Service Switching Function (SSF) is provided to "enhance" the operation of these Switches by detecting when a particular request has been made (such as by dialing 1-800). If this pattern is detected, the equipment implementing the SSF will send a specialized request message over the signaling network to a separate computer that implements the Service Control Function (SCF). This entity is responsible for querying service specific data (held in a unit providing the Service Data Function, or SDF), performing any digit translations necessary, and sending the details of how to proceed back to the SSF, where they are obeyed and the call is put through to the "real" destination. In many implementations, the SDF is closely coupled to the SCF. This configuration is shown in Figure 18.
[---] [---] [---]
/--\ [SRF] [SCF] [SDF]
()/\()__ [|-!] [-!-] [-!-]
/__\ \ || \.............!......!........
\ || / ! ! /--\
__ \ [|-!] [-!-] ! ()/\()
\ \ \__[SSF] [CCF] ! ___/__\
[Fax]________[CCF]=========[---]==\\ [!--] / __
\\========[CCF]__/ \ \
[---]_______[Fax]
Key: ___ access relationship
=== trunk relationship
... signaling relationship
Figure 18
The advantage is that there can be a much smaller number of physical
units dedicated to the SCF, and as they are connected to the
signaling network they can be contacted by, and can send instructions
back to, all of the units providing the SSF and thus the CCF.
In another enhancement, a separate entity called the Special Resource
Function (SRF) was defined. Equipment implementing this function
includes announcement units to play recorded messages (for example,
prompts to enter digits) to callers. It will also include the tone
decoders needed to capture any digits pressed by the caller in
response to the prompts. It is connected to the rest of the PSTN
usually via trunk data links. It will also include a signaling
connection (directly or indirectly) back to the SCF, via the PSTN's
core signaling network.
As an example of the way that these different functional entities
interact, the SCF can ask an SSF handling a call to route the caller
temporarily through to an SRF. In response to instructions sent to it
from the SCF over the signaling network, the SRF can play
announcements and can collect digits that the user presses on their
terminal in response to prompts they are played. Once these digits
have been collected they can be passed on to the SCF via a signaling
message for further processing. In normal operation, the SCF would
then ask the SSF to dissolve the temporary connection between the
user's terminal and the SRF. This allows the collection of account
numbers or passwords (or PINs) and forms the heart of many "Calling
Card" services.
This pattern of user interaction is also used in a wide variety of
other services where extra account information and PINs are needed.
They are collected as just described and can be checked against the
correct values stored in the service database prior to allowing the
call to proceed.
The Intelligent Network functional entities can be realized as
physical units in a number of different combinations. A common
configuration is shown in Figure 19.
[---] [---] [---] [---]
/--\ [I.P] [SCP] [SDP] [SN ]
()/\()__ [|-!] [-!-] [-!-] [--|]
/__\ \ || \.............!.....!..... |
\ || / ! \ | /--\
__ \ [|-!] [-!-] \ | ()/\()
\ \ \__[SSP]=========[CO ]==\\ \ | ___/__\
[Fax]________[---] [---] \\ [!-|] / __
\\=======[CO ]__/ \ \
[---]_______[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
SSP Service Switching Point - a unit that implements the
Service Switching Function
CCP Call Control Point - a unit that performs call control
functions.
This is normally a kind of Central Office (shown as CO
above)
SCP Service Control Point - a unit implementing the Service
Control Function. NOTE that this is connected to the SS7
Network and uses this connection for all of its
communications.
I.P Intelligent Peripheral - a unit that contains specialized
resources (like announcement units, tone decoders).
In effect, it implements Special Resource Functions.
SN Service Node
Figure 19
This diagram also shows a unit called a Service Node, or SN. This
contains components that realize all of the operational Intelligent
Network functions (SSF, SCF, SDF, and SRF). It is sometimes more
convenient to have all of these elements in one node (for example,
for operations and maintenance reasons), particularly within smaller
PSTNs or where there is a relatively low level of requests for
particular services. Another difference is that, as they are all co- located, proprietary protocols can be used for internal communication, rather than the full Intelligent Network Application Part (INAP) protocol used over the core signaling network between discrete units. It also differs from the "unbundled" approach in that it is connected to the COs within a PSTN as a peripheral, having only an access connection to a Central Office; there is no connection to the core signaling network. Other than this, it operates in a similar way, and can provide the same kinds of services. Information on the specification of the Intelligent Network can be found in the ITU recommendations [1], while two books ([2] and [3]) describe the system, its history, operation, and the philosophy behind it. 11.2 Call Center Features A Call Center is a system that allows a company to be organized with a group of similar individuals (agents), all of whom can either make calls to, or take calls from, customers. The system distributes incoming calls to the agents based on their availability and automates the placement of outgoing calls, selecting an agent to handle the call and routing the call to them only once the call request has been made of the PSTN. The incoming call distribution feature ("automatic call distribution", or ACD) is usually coupled with a call queuing scheme. In this scheme, the callers are connected temporarily with an announcement unit that normally plays music. The calls are treated in sequence so that (once the caller is at the front of the queue) the ACD system selects the next available agent and routes the call through to them. Another feature connects a customer making an incoming call to a unit that asks them for some information on the purpose of their call, selecting the agent to handle the call based on the particular area of expertise needed; to do this, the agents are further categorized by their knowledge (or "Skill Set"). If this skill set categorization is used then by implication there will be separate queues for each of the skill sets. This user selection scheme can be used independently of the others. For example these so-called "voice navigation systems" can be used to select a particular department extension number, based on the function required by the customer; as such, they can automate the job of company telephone receptionist in routing incoming calls. Where possible, the information gleaned from the customer can be provided to the selected agent, usually via a separate networked computer connection. Similarly, if an outgoing call is being made to one of a list of customers, information on the customer and the purpose of the call can be provided to the agent selected to handle
the call. Such configurations are generally called "Computer Telephony Integration" or CTI systems. Strictly, a CTI system can be arranged to handle routing of incoming calls and automation of outgoing calls only (also known as computer integrated telephony features), without the agents having access to a network of computers. However, the business case for combining the telephony functions of the call center with provision to the agents of computers with customer information can be compelling. This is often further combined with a company's order and service processing computer system. In this case, a call is treated as part of a business transaction, with the information to be exchanged captured as fields of a computer form. While such a computer system is not, strictly, part of a call center, integrating the company computer system with the call center is very common. This allows the details of the call to be stored on a centralized database, allowing further automated order processing, for example. It also allows the call to be transferred from one agent to another where needed, ensuring that the new agent has the information already captured. This might be useful if someone with a different area of expertise were to be needed to handle the customer's requirements. Traditionally, Call Centers have been used to support teams of agents working at a single site (or a small number of sites, with private telephony trunks interconnecting them). The site Private Automatic Branch eXchange (PABX) was integrated with a computer system to provide these features to people at that site. There can be a business case for provision of such features to distributed teams of workers as well. In particular, the possibility of providing support for people working from home has been seen as important. Some of the Call Center features have been incorporated into public telephone exchanges or Central Offices (COs) from many manufacturers as part of their "Centrex" service offerings. There are practical limitations in providing such features on COs. Apart from the procedures needed to configure these features for any telephone line that is to use them, the basic requirement that every agent must have a connection to the supporting CO can limit its usefulness. Another approach is to provide Call Center features via the Intelligent Network. The features might thus be provided over a Telephone Operator's entire network, and would mean that the Call Center could be configured centrally while still allowing agents to be located anywhere within the telephone network. It also means that the supported company can pay for the Call Center features "as they go" rather than having a high "up front" cost.
12. References [1] ITU-T Q.12xx Recommendation Series, Geneva, 1995. [2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The Intelligent Network Standards, their Application to Services", McGraw-Hill, 1996. [3] T. Magedanz and R. Popesku-Zeletin, "Intelligent Networks: Basic Technology, Standards and Evolution", Intl. Thomson Computer Press, 1996. [4] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December, 1987. [5] McCloghrie, K., Editor, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [6] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997. [7] Zimmerman, D., "The Finger User Information Protocol", RFC 1288 December 1991.
Authors' Addresses Steve Bellovin AT&T Labs Room E-215 180 Park Ave. Bldg. 103 Florham Park, NJ 07932-0000 USA Phone: +1 973 360 8656 Fax: +1 973 360 8077 EMail: smb@research.att.com Fred M. Burg AT&T Labs Room 1N-117 307 Middletown Lincroft Road Lincroft, NJ 07738 USA Phone: +1 732 576 4322 Fax: +1 732 576 4317 EMail: fburg@hogpb.att.com Lawrence Conroy Roke Manor Research Limited IT&N-INIA Group Roke Manor, Old Salisbury Lane, Romsey, Hampshire SO51 0ZN U.K. Phone: +44 1794 833666 Fax: +44 1794 833434 EMail: lwc@roke.co.uk Paul Davidson Nortel P.O.Box 3511 Station "C" Mail Stop 242 Ottawa, Ontario, Canada K1Y 4H7 Phone: +1 613 763 4234 EMail: pauldav@nortel.ca
A. DeSimone Lucent Technologies Room 6H510 600-700 Mountain Avenue Murray Hill, NJ 07974-0636 USA Phone: +1 908 582 2382 Fax: +1 908 582 1086 E-Mail:tds@lucent.com Murali Krishnaswamy Bell Laboratories Lucent Technologies Room 2G-527a 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA Phone: +1 732 949 3611 Fax: +1 732 949 3210 EMail: murali@bell-labs.com Hui-Lan Lu Bell Laboratories Lucent Technologies Room 4K-309 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA Phone: +1 732 949 0321 Fax: +1 732 949 1196 EMail: hui-lan.lu@bell-labs.com Henning Schulzrinne Dept. of Computer Science Columbia University New York, NY 10027 USA Phone: +1 212 939 7042 (@Bell Labs: 732 949 8344) Fax: +1 212 666 0140 EMail: schulzrinne@cs.columbia.edu
Kamlesh T. Tewani AT&T Labs Room 1K-334 101, Crawfords Corner Rd. Holmdel, NJ 07733 USA Phone: +1 732 949 5369 Fax: +1 732 949 8569 EMail: tewani@att.com Kumar Vishwanathan Isochrone EMail: kumar@isochrone.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). 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 assigns.
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.