RFC 3298

Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements

📅 published September 2002, from ietf

Title Block: RFC 3298 🎀

okay bestie, RFC 3298 is giving SPIRITS 🦋 Its full title is Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements. It's an Informational document from August 2002, written for the Network Working Group. Faynberg is the editor (Lucent Technologies), and the other authors are J. Gato (Vodaphone), H. Lu (Lucent Technologies), and L. Slutsman (AT&T). The title block doesn't list anything it obsoletes or updates. 📋✨

Status of this Memo

This memo gives information to the Internet community. It is not an Internet standard of any kind, and it can be shared freely with no limits on distribution. 🌸

Copyright (C) The Internet Society (2002). All Rights Reserved. 💜

Abstract

okay so this document lays out the SPIRITS protocol requirements, built on the architecture in RFC 3136. (SPIRITS = "Service in the PSTN/IN Requesting InTernet Service", and it's so iconic 😭) The whole point is to support services that start in the Public Switched Telephone Network (PSTN) but need the PSTN and the Internet to talk to each other. Those are called SPIRITS services. Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples, but the protocol is really meant to define the building blocks that let you make tons of other services too 🧚 On the PSTN side, SPIRITS services get kicked off from Intelligent Network (IN) entities. Earlier IETF work on PSTN/Internet Interworking (PINT) gave us the protocol in RFC 2848, which goes the other way around, starting services from the Internet and reaching into the PSTN 🔥

So this doc covers the general requirements for SPIRITS, plus the ones for IN, Wireless IN, and PINT building blocks. It also shares the SPIRITS WG consensus on which SPIRITS signaling protocol to pick. 💅

1. Conventions used in this document ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 🫶

Unless it says otherwise, "PINT" here doesn't mean today's PINT services and protocol. It's about the general PINT scope, meaning services invoked from an IP network instead of the PSTN, which is kind of the opposite of SPIRITS 🙈

2. Introduction 🌈

Okay, the intro basically repeats the abstract with a bit more detail, so here we go 💖 SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service." The goal is still to support services that start in the PSTN and need the PSTN and the Internet working together. Those are SPIRITS services. Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are the examples again, and the protocol is meant to be the building blocks for other services. On the PSTN side, the IN entities start SPIRITS services. The earlier PINT work produced RFC 2848, which covers services started from the Internet and going to the PSTN 🦋

Same deal as the abstract: this doc has the general requirements, the IN ones, the Wireless IN ones, and the PINT building blocks, plus the SPIRITS WG consensus on the signaling protocol choice. The joint PINT/SPIRITS architecture (described in [1]) is shown in Figure 1 🍓

It's assumed the Spirits Client is either co-located with the IN Service Control Function (SCF) or talks to it over the PSTN-specific interface D, so that it acts on behalf of the PSTN/IN. Current implementations back this up, as reported in [2] 💜

SPIRITS services get invoked (and then the SPIRITS protocol kicks in) when a message from a SPIRITS Client arrives on interface C at the SPIRITS gateway. That client lives in the IN Service Control Point [SCP] or Service Node [SN]. The gateway processes the message and passes it along over Interface B to the SPIRITS server. Most of the time, the client's request was caused by a request from a Central Office (basically a telephone switch) sent to the SCP or SN. Theoretically, those elements could start an Internet-based service on their own without the Central Office, but none of the SPIRITS benchmark services work that way. So for protocol development, assume the invocation was a direct result of an earlier action by the Service Switching Function 🔥

                                      ......................
      +----------------+              .                    .
      | +------------+ |              .   +------------+   .
      | |            | |       A      .   |            |   .
      | | PINT Client|********************|PINT Server/|********
      | |            | |              .   |  Gateway   |       *
      | +------------+ |              .   +------------+   .   *
      |                |              .                    .   *
      |  Subscriber's  |              .                    .   *
      |                |              .                    .   *
      |  IP Host       |              .                    .   *
      |                |              .   +------------+   .   *
      | +------------+ |              .   | SPIRITS    |   .   *
      | | SPIRITS    | |       B      .   | Gateway    |   .   *
      | | Server     |********************|            |   .   * E
      | |            | |              .   +------------+   .   *
      | +------------+ |              .          *         .   *
      +----------------+              .          *         .   *
                                      ...........*..........   *
                                                 *             *
                                                 *             *
           Subscriber's                          *  C          *
           Telephone                             *             *
                                                 *             *
             (---)                               *             *
               *                                 *             *
              * *                                *             *
     ++++++++++++++++++++++++++  PSTN   ++++++++++++++++++++++++++
               *                                 *             *
               *                                 *             *
               *                          +------------------+ *
               * Line                     | SPIRITS Client   | *
               *                          |                  | *
      +--------------------+          +---+----- D  ---------+-*+
      |                    | INAP/SS7 |                         |
      |Service Switching   ************Service Control Function |
      |    Function        |          |                         |
      |                    |          +-------------------------+
      |                    |
      |                    |
      +--------------------+

             Figure 1. Joint PINT/SPIRITS Architecture

With PINT (which also covers the PINT architecture and protocol described in [3]), the PINT Client always starts the service request to the PINT Server over interface A. The PINT Server can either be co-located with the IN Service Control or a similar entity (which [3] calls the "Executive System"), or talk to it over the PSTN-specific interface E 🧚

Looking at Figure 1, the PINT Client and SPIRITS Server live together in the Subscriber's IP Host. They can even run as one process. There's no provision for the PINT Client and Spirits Server to interact directly 🙈 The PINT Server/PINT Gateway and SPIRITS gateway are assumed to be co-located too. That's convenient but not essential, since the PINT Server could also be co-located with the SPIRITS Client. Either way, there's no specific provision for interworking between the PINT Server and Spirits Gateway, or between the PINT Server and SPIRITS Client, beyond listing the overall PINT-related requirements 💅

For SPIRITS purposes, the wireless networks deployed worldwide today count as PSTN networks, because they're based on circuit switching. Adding SPIRITS-type services to wireless networks can unlock new services. For example, geolocation information can be handled in the IP network 🌸

That said, wireless networks have some quirks that force changes to the protocol requirements and the SPIRITS architecture. ✨

The specific Wireless IN standard considered here is CAMEL phase 3, standardized by the Third Generation Partnership group (3GPP). The related service and architecture considerations and protocol requirements come later in this document 🫶 On the architecture side, certain wireless events are generated by the Home Location Register (HLR), which may, but does not have to, be part of the Mobile Switching Center (MSC), which is the wireless version of the SSP. Those events get communicated to Service Control, and at that point they use the same mechanism the IN would use to invoke SPIRITS services 🔥

The rest of this document covers the general requirements, IN requirements, specific Wireless IN requirements, PINT requirements, the protocol development methodology, and security issues, in that order. 💖

3. General Requirements 🎀

okay so bestie, SIP [7] got picked as the signaling base protocol for SPIRITS 💖 and that's because extending SIP for PINT ([3]) went so well, and the pre-SPIRITS implementations in [2] really proved it works 🔥

It is a requirement that SPIRITS-related parameters get carried in a way that's consistent with SIP practices ✨ Either Session Description Protocol (SDP) [8] or Multi-purpose Internet Mail Extensions MIME [5-6] may be used for this. Apart from the proposed new SUBSCRIBE/NOTIFY mechanism [4] and the extensions already defined in PINT, no new SIP extensions are foreseen 🧚 Instead, SPIRITS just relies on those extension mechanisms, and honestly that's giving clean.

It is by no means a requirement that any SPIRITS implementation automatically supports PINT services 🙈 The SPIRITS protocol must be defined so that, at the very minimum, it can support only the basic notification mechanism without relying on PINT services or otherwise relying on persistent interactions with PSTN. Nevertheless, it has been demonstrated [2] that combining PINT building blocks with those of SPIRITS is beneficial for building rich, enhanced PSTN/Internet services 🌈 So the SPIRITS protocol must meet the PINT-related requirements listed in section 7 of this document.

Here's one specific example of that last requirement, and it gets elaborated on later in the doc 🦋 Implementation of SUBSCRIBE/NOTIFY is not mandatory as far as the minimum SPIRITS protocol is concerned. So the initial PSTN (Detection Point) notification will always arrive via the SIP INVITE method. However, to implement persistent interactions with the PSTN, the SUBSCRIBE method may be used to get further notifications of PSTN events. After that, those events get reported by means of the NOTIFY method 💜

4. IN Requirements 💅

The interface that matters most for IN is the one between the SPIRITS Client and the SPIRITS Gateway, which is called interface C 👑 A typical message (the one that starts a SPIRITS service) looks like this:

C -> G: <Event Notification>, <Parameter-List (DP)>

The relevant events line up with the detection points (DPs) of the IN Basic Call State Model (BCSM) ✨ The <Parameter-List> depends on the specific DP, since it holds the parameters that are relevant to that DP. These are the following requirements:

  1. The list of DPs to be covered includes the ones defined in the IN Capability Set 3 BCSM, plus the ones related to the Wireless IN (WIN) specified by the IMT 2000 project in ITU-T 🌸
  2. Not every parameter linked to these DPs is needed by the SPIRITS benchmark services, and not all of them may be needed in SPIRITS either 🍓 Picking the relevant parameters is part of defining the SPIRITS protocol.
  3. It's desirable to avoid semantic overload of protocol messages 🫶 (One way to do that is to match each type of event with a message that corresponds to it.) SPIRITS is designed as a set of extensions to another, existing protocol with a defined message set, so the syntax and semantics of those extensions should be defined with this requirement in mind.
  4. The ITU-T Recommendations use Abstract Syntax Notation One (ASN.1) to specify the semantics of IN Application Protocol (INAP) parameters, and those parameters are expected to be binary-encoded. Using ASN.1, or requiring binary encoding, isn't typical for IETF application protocols 🙃 Knowing that, provisions must be made for careful specification of how INAP parameters get converted to text, and that conversion has to preserve their original semantics. The actual conversion of the parameters is the job of the SPIRITS Client.

To issue an initial query (or a notification) to service control, a switch must have that DP set. This can be done statically via service management (this particular action is left to implementation, so it's considered outside the scope of the SPIRITS Protocol), or dynamically, but only for the purpose of a particular call, from service control 💖 In the latter case, it's part of the SPIRITS (or PINT) protocol to request the event notification from service control. The SIP specific event notification scheme [4] should be specifically considered. This function can be performed by either the Spirits Client or the PINT Server, and the distinction is discussed further in the next section. Assuming the SPIRITS Client performs it, the relevant message should look like this:

G->C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>,

Here, <Event> refers to a particular DP. <Mode> determines whether the Event Detection Point (EDP) is armed as EDP Request (EDP-R), EDP Notification (EDP-N), or TDP-R. The need for TDP-N isn't foreseen, because it wouldn't add any extra capability for SPIRITS 🦋 And the <DP-specific parameters> is the list of values for the parameters associated with the EDP. For example, if the DP in question is O_No_Answer, then the value of the appropriate timer should be included in the list ⏰

Note that such a subscription may also originate at a) a PINT Client or b) a SPIRITS Gateway. Either of them may (but doesn't have to) have a locally significant definition of the <Event> 🧁 Either way, it's the job of the SPIRITS Client to translate the definition of the Event into a particular DP (or set of DPs) when passing the message to Service Control. To sum up, for the case where PINT and SPIRITS events are defined without referring to the BCSM DPs, it's the SPIRITS Client's job to define a mapping like this, for each event where a PSTN notification is needed:

Event -> DP List,

The list of CS-3 DPs envisioned in SPIRITS is:

  • origination_attempt_authorized (the SPIRITS service can control call attempts, (for example, to limit calls during specific time periods)
  • collected_information and analyzed_information (for SPIRITS outgoing call screening)
  • o_answer, o_term_seized, and t_answer (to release SPIRITS resources after the call is complete and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.)
  • o_no_answer, route_select_failure, and t_no_answer (to re-route a call) 🔀
  • o_called_party_busy (to re-route a call and for Internet Call Waiting) 📞
  • o_mid_call and t_mid_call (to assist a midcall action)
  • o_abandon, o_disconnect, t_abandon, and t_disconnect (to terminate a SPIRITS service and release the resources and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.) 🧹

In addition, these DPs are relevant to the present SPIRITS milestone services:

  • termination_attempt_authorized
  • facility_selected_and_available (could be used in SPIRITS Internet Caller-ID) 🪪
  • t_busy (for Internet Call Waiting and Call Forwarding)

Wireless IN covers several types of "calls" that are neither circuit switched nor have any effect on circuit switched calls 🙅‍♀️ Because of that, SPIRITS requirements don't consider them. To make this extra clear, the types of "calls" that aren't considered are:

  • USSD (Unstructured Supplementary Service Data)
  • GPRS (General Packet Radio System)
  • SMS (Short Message System)

The types of calls that ARE relevant to SPIRITS are as follows:

a) Voice Calls. No new DP is needed here, since CAMEL DPs are included in CS2 🎀 The only special case is "Not Reachable" (when it's detected that the mobile user is out of coverage or has switched off), which is mapped as a special cause in the Busy DP. Since the Busy DP parameters would be received (if a SPIRITS service has subscribed to Busy), it would be possible to tell a "busy" apart from a "not reachable" situation 👀

That translates into a requirement that one of the parameters in the Event Notification message (from the SPIRITS Client to the SPIRITS Gateway, over interface C) denotes the "cause" for the Busy Detection Point.

Another difference from the PSTN is how static DPs get set. In CAMEL networks, this is done in the Home Location Register (HLR), and then copied to the VLR during a location update. It's important to note this difference, even though it has no effect on the SPIRITS protocol 📝

b) Mobility Management events. This lets a SPIRITS server get notified when a mobile user's location changes 📍 These events would only apply to mobile users reachable through a Circuit-Switched network. To provide this function, the subscription marks must be set in the subscriber's HLR. This is equivalent to setting TDPs in the SSP. In this case, the marks in the HLR (which get copied to the Visitor Location Register [VLR] on location update) are not mapped into Trigger Detection Points.

As with TDP setting, this is outside the scope of the SPIRITS protocol 🙌

In order to support this function in SPIRITS, the SPIRITS protocol should be able to map the CAMEL specific operations into event notifications to the SPIRITS client. Since the SCP receives the information about the mobility state, this involves the C interface. (This is just an extension of the DP notification mechanism from the SPIRITS client to the SPIRITS gateway.)

The events (which are not DP-related) that need notifications are:

  • Location Update in the same VLR service area
  • Location Update in another VLR service area
  • IMSI attach
  • MS initiated IMSI detach
  • Network initiated IMSI detach

With this mechanism, SPIRITS services can use the user-profile-based location information. For example, the Internet Call Waiting service can re-direct the call to a mobile phone 📱✨

c) Supplementary Services Notification. This mechanism makes a SPIRITS server aware of a subscriber having invoked one of the following supplementary services: Explicit Call Transfer, Call Deflection, Call Completion on Busy Subscriber, or Multi-Party 💜

okay bestie so before a SPIRITS service can be invoked, the relevant IP Host has to be registered 🫶 Registration is the essential first step and it gets kicked off from the IP side. The registration info is what the PSTN ultimately uses to authenticate the subscriber 🔐

Depending on the model, there are two ways to do this with the present architecture:

  1. The PINT Client issues the appropriate Register message over the interface A, which is then passed by the PINT server to the SPIRITS Gateway and SPIRITS Client:
PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS
C.].

In this case the SPIRITS Client (co-located with the service control) is responsible for record keeping and the authentication 📒

  1. The PINT Client issues the appropriate Register message to the PINT Server, which then passes this information to the PSTN service control "by magic" ✨🪄

The second model is way easier to handle because it involves only one relevant interface ("A") 💅 However, it assumes no interworking between PINT and SPIRITS, except that the SPIRITS Client finds "by magic" that a friendly and expecting IP Host is alive and well 🙈

Finally, in the event PINT is not implemented, the SIP SUBSCRIBE mechanism can be used 🦋

As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT building blocks [3] must be extended for their use in SPIRITS, for the purposes of setting DPs and getting DP event notifications. (A more general SIP mechanism for the same PINT-introduced block is described in [4]; it provides the necessary mechanism for specifying relevant events 👀) Conversely, the same building blocks for the functional capabilities can be used in both PINT and SPIRITS protocols. Note, however, that in SPIRITS the PSTN notification may arrive without a particular subscription to an event (in the case of a statically set DP) 💜

7. Follow-up on Event Notifications

The requirements of this section are neither PINT-specific nor IN-specific 🌈 Their job is to outline the remaining element needed to deliver the SPIRITS service, which is the reaction to the notification received. It's the glow-up part!

In a particular scenario where:

a) The IP subscriber registers a SPIRITS service;

b) A call triggering the SPIRITS service is received (and notification is sent); and

c) The call disposition is performed by the end user,

the signalling flow is demonstrated in Figure 2 🎀

                |---->  Registration  ----->|
        SPIRITS |<-- Event Notification <-- | SPIRITS
        Gateway |---> Call Disposition ---->| Client
                |                   |
                                    |
                                    |
                                    |
                                    V
                              Service Control
                                    |
                                    |
                                    V
                                   SSP

           Figure 2: Sequence of SPIRITS actions

One of the following actions is required by benchmark services:

a) Accept the incoming call

b) Reject the incoming call

c) Redirect the incoming call

d) Accept the call via VoIP (this particular item is outside of the scope of SPIRITS WG) 🚫

Accordingly, the SPIRITS protocol should define the following message types 📨

a) S->G: <Accept Call>

b) S->G: <[Reject Call],[Cause]>

c) S->G: <[Redirect Call],[Redirection Destination]>

8. Methodology

To figure out the MINIMUM SPIRITS protocol vocabulary (aka the set of messages 📖), the PSTN events associated with each detection point of the Basic Call State Model should be examined. To date, the CS-3 BSCM has the richest set of DPs, although not all switching exchanges have implemented it 🧠

To figure out the MINIMUM information available to the SPIRITS client (this info is carried by the SPIRITS protocol from SPIRITS client to SPIRITS server 📦), each DP-specific information element needs to be examined.

Parameters should be event-specific. The following generic types of parameters are expected to be mandatory:

  • timer (for no answer)
  • midcall control info (for mid_call)
  • number of digits (for collected_information)

9. Security Considerations

⚠️ Okay bestie, this section is SERIOUS. Like, the whole vibe changes here. Read every word 🥺

Overall, the basic aspects of security apply to the SPIRITS protocol:

  • Authentication: In the communications between the SPIRITS Client and SPIRITS Gateway, as well as between the SPIRITS Gateway and SPIRITS Server, it is required that the information be sent between known and trusted partners 🤝
  • Integrity: It is a requirement that no exchanged data be modified in transit 🛡️
  • Confidentiality: It is a requirement that any private user information or confidential network data be protected by the protocol (typically through encryption, for which the protocol should allow a choice in the algorithm selection 🔒
  • Availability: It is a requirement that the communicating endpoints remain in service for authorized use only 🚪

In addition, the protocol should support non-repudiation for those control messages pertinent to charging the PSTN subscriber 💸

As Figure 1 demonstrates, there are two distinct communications interfaces, B and C. The B interface is, in general, across the public Internet, and is thus most vulnerable to security attacks resulting in theft or denial of service 😬 The C interface, on the other hand, is likely to be implemented across a service provider's intranet, where the security measures should be applied at the discretion of the service provider. Even then, because at least one IP host (the PINT gateway) is connected to the Internet, special measures (e.g., installation of firewalls, although this particular measure alone may be insufficient) need to be taken to protect the interface C and the rest of the network from security attacks 🧱

The assumption that the PINT Client and SPIRITS server are co-located dictates that the security considerations for the A and B interfaces are exactly the same. Detailed security requirements and solutions for interface A (and, consequently, B) can be found in RFC 2848 [3] 📚

Possible security attacks can result in both theft and denial of services. In addition, such attacks may violate the privacy of a PSTN subscriber 😭 For example, with Internet Call Waiting, a fraudulent registration (or a manipulation of the integrity of a valid registration) may force a network operator to provide an authorized party with a full log of attempted telephone calls (accompanied by the identification of callers). Furthermore, the calls may be diverted to wrong recipients, who may further defraud the unsuspecting calling party 💀 In this case, the calling party is using only the PSTN and is thus expecting the security of communications that are typical of the PSTN. The PSTN service providers may be liable for the consequences of establishing wrong connections. In addition, the PSTN service providers may be liable for inadvertent divulging of the private information of the subscriber 🙀

The service and network providers need to review the possibilities of security attacks and prepare the means of protection from them. Some of this may be achieved by using means outside of those provided by the protocol itself. For example, administrative information (such as statistics collected by PINT MIB or SPIRITS MIB) can help in determining violations and thwarting them 📊 As far as the protocol is concerned, it must provide the means for authenticating a subscriber as well as a session. It must also provide a capability to carry encrypted information in its body 🔐🫶

10. Acknowledgements

The authors are grateful to all participants in the SPIRITS group for the discussion that has been shaping this work 🌸 Many thanks go to Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren Nyckelgard, and John Voelker for their incisive comments 👑 Special thanks are due to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose careful, detailed reviews of several versions of this document were particularly helpful in improving its quality ✨🫶

11. References

[1] Slutsman, L., Faynberg, I., Lu, H. and M. Weissman, "The Spirits Architecture", RFC 3136, June 2001.

[2] Lu, H. (Editor), Faynberg, I., Voelker, J., Weissman, M., Zhang, W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S., Nyckelgard, S., Yoakum, J. and L. Robart, "Pre-SPIRITS Implementations of PSTN-Initiated Services", RFC 2995, November 2000.

[3] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.

[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.

[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.

[8] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.

12. Authors' Addresses 🦋

Lev Slutsman
AT&T Laboratories
200 Laurel Ave.
Middletown, New Jersey, 07748

Phone: (732) 420-3752
EMail: lslutsman@att.com


Igor Faynberg
Bell Labs/Lucent Technologies
Room 4D-601A, 101 Crawfords Corner Road
Holmdel, New Jersey, 07733

Phone: (732) 949-0137
EMail: faynberg@lucent.com


Jorge Gato
Vodaphone
Avda de Europa, 1.
28108 Alcobendas (Madrid). Spain

Phone: +34 607 13 31 10
Fax:   +34 607 13 30 57
EMail: jgato@airtel.es


Hui-Lan Lu
Bell Labs/Lucent Technologies
Room 4C-607A, 101 Crawfords Corner Road
Holmdel, New Jersey, 07733

Phone: (732) 949-0321
EMail: huilanlu@lucent.com

Okay bestie, time for the legal bit 💅 Copyright first: Copyright (C) The Internet Society (2002). All Rights Reserved. 🎀

This document and its translations can be copied and handed out to others 📄. You're also allowed to make derivative works that comment on or explain it, or that help people implement it 🔧. Those can be prepared, copied, published and distributed, in whole or in part, with no restriction of any kind 🦋. The one condition is that the copyright notice above and this paragraph have to be included on every copy and every derivative work 💜.

BUT the document itself may not be modified in any way 🙅‍♀️. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed 📜, or when it's being translated into a language other than English 🌍.

The limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them ♾️✨.

Now the big disclaimer, no cap 😭:

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.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 💖.

📦 where this page comes from