    Network Working Group                                    V. Gurbani, Ed.
    Request for Comments: 3910                                A. Brusilovsky
    Category: Standards Track                                    I. Faynberg
                                                   Lucent Technologies, Inc.
                                                                     J. Gato
                                                             Vodafone Espana
                                                                       H. Lu
                                               Bell Labs/Lucent Technologies
                                                                 M. Unmehopa
                                                   Lucent Technologies, Inc.
                                                                October 2004

      The SPIRITS (Services in PSTN requesting Internet Services) Protocol

    Status of this Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  Distribution of this memo is unlimited.

    Copyright Notice

       Copyright (C) The Internet Society (2004).

    Abstract

       This document describes the Services in PSTN (Public Switched
       Telephone Network) requesting Internet Services (SPIRITS) protocol.
       The purpose of the SPIRITS protocol is to support services that
       originate in the cellular or wireline PSTN and necessitate
       interactions between the PSTN and the Internet.  On the PSTN side,
       the SPIRITS services are most often initiated from the Intelligent
       Network (IN) entities.  Internet Call Waiting and Internet Caller-ID
       Delivery are examples of SPIRITS services, as are location-based
       services on the cellular network.  The protocol defines the building
       blocks from which many other services can be built.

    Table of Contents

       1.   Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  3
            1.1.   Conventions used in this document. . . . . . . . . . .  3
       2.   Overview of operations. . . . . . . . . . . . . . . . . . . .  3
            2.1.   Terminology. . . . . . . . . . . . . . . . . . . . . .  6
       3.   Using XML for subscription and notification . . . . . . . . .  7
       4.   XML format definition . . . . . . . . . . . . . . . . . . . .  8

    Gurbani, et al.             Standards Track                     [Page 1]

    RFC 3910                    SPIRITS Protocol                October 2004

       5.   Call-related events . . . . . . . . . . . . . . . . . . . . . 10
            5.1.   IN-specific requirements . . . . . . . . . . . . . . . 11
            5.2.   Detection points and required parameters . . . . . . . 12
                   5.2.1.   Originating-side DPs. . . . . . . . . . . . . 12
                   5.2.2.   Terminating-side DPs. . . . . . . . . . . . . 14
            5.3.   Services through dynamic DPs . . . . . . . . . . . . . 15
                   5.3.1.   Normative usage . . . . . . . . . . . . . . . 15
                   5.3.2.   Event package name. . . . . . . . . . . . . . 16
                   5.3.3.   Event package parameters. . . . . . . . . . . 16
                   5.3.4.   SUBSCRIBE bodies. . . . . . . . . . . . . . . 16
                   5.3.5.   Subscription duration . . . . . . . . . . . . 17
                   5.3.6.   NOTIFY bodies . . . . . . . . . . . . . . . . 17
                   5.3.7.   Notifier processing of SUBSCRIBE requests . . 18
                   5.3.8.   Notifier generation of NOTIFY requests. . . . 18
                   5.3.9.   Subscriber processing of NOTIFY requests. . . 19
                   5.3.10.  Handling of forked requests . . . . . . . . . 19
                   5.3.11.  Rate of notifications . . . . . . . . . . . . 19
                   5.3.12.  State Agents. . . . . . . . . . . . . . . . . 20
                   5.3.13.  Examples. . . . . . . . . . . . . . . . . . . 20
                   5.3.14.  Use of URIs to retrieve state . . . . . . . . 25
            5.4.   Services through static DPs. . . . . . . . . . . . . . 25
                   5.4.1.   Internet Call Waiting . . . . . . . . . . . . 26
                   5.4.2.   Call disposition choices. . . . . . . . . . . 26
                   5.4.3.   Accepting an ICW session using VoIP . . . . . 28
       6.   Non-call related events . . . . . . . . . . . . . . . . . . . 29
            6.1.   Non-call events and their required parameters. . . . . 29
            6.2.   Normative usage. . . . . . . . . . . . . . . . . . . . 30
            6.3.   Event package name . . . . . . . . . . . . . . . . . . 30
            6.4.   Event package parameters . . . . . . . . . . . . . . . 31
            6.5.   SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . 31
            6.6.   Subscription duration. . . . . . . . . . . . . . . . . 31
            6.7.   NOTIFY bodies. . . . . . . . . . . . . . . . . . . . . 32
            6.8.   Notifier processing of SUBSCRIBE requests. . . . . . . 32
            6.9.   Notifier generation of NOTIFY requests . . . . . . . . 32
            6.10.  Subscriber processing of NOTIFY requests . . . . . . . 33
            6.11.  Handling of forked requests. . . . . . . . . . . . . . 33
            6.12.  Rate of notifications. . . . . . . . . . . . . . . . . 33
            6.13.  State Agents . . . . . . . . . . . . . . . . . . . . . 33
            6.14.  Examples . . . . . . . . . . . . . . . . . . . . . . . 33
            6.15.  Use of URIs to retrieve state. . . . . . . . . . . . . 37
       7.   IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
            7.1.   Registering event packages . . . . . . . . . . . . . . 38
            7.2.   Registering MIME type. . . . . . . . . . . . . . . . . 38
            7.3.   Registering URN. . . . . . . . . . . . . . . . . . . . 39
            7.4.   Registering XML schema . . . . . . . . . . . . . . . . 40
       8.   Security Considerations . . . . . . . . . . . . . . . . . . . 40
       9.   XML schema definition . . . . . . . . . . . . . . . . . . . . 42
       10.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 45

    Gurbani, et al.             Standards Track                     [Page 2]

    RFC 3910                    SPIRITS Protocol                October 2004

       11.  Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
       12.  References. . . . . . . . . . . . . . . . . . . . . . . . . . 46
       13.  Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 48
       14.  Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 48
       15.  Full Copyright Statement. . . . . . . . . . . . . . . . . . . 50

    1. Introduction

       SPIRITS (Services in the PSTN Requesting Internet Services) is an
       IETF architecture and an associated protocol that enables call
       processing elements in the telephone network to make service requests
       that are then processed on Internet hosted servers.  The term Public
       Switched Telephone Network (PSTN) is used here to include the
       wireline circuit-switched network, as well as the wireless circuit-
       switched network.

       The earlier IETF work on the PSTN/Internet Interworking (PINT)
       resulted in the protocol (RFC 2848) in support of the services
       initiated in the reverse direction - from the Internet to PSTN.

       This document has been written in response to the SPIRITS WG chairs
       call for SPIRITS Protocol proposals.  Among other contributions, this
       document is based on:

          o  Informational  "Pre-SPIRITS implementations" [10]
          o  Informational  "The SPIRITS Architecture" [1]
          o  Informational  "SPIRITS Protocol Requirements" [4]

    1.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 BCP 14, RFC 2119 [2].

    2.  Overview of operations

       The purpose of the SPIRITS protocol is to enable the execution of
       services in the Internet based on certain events occurring in the
       PSTN.  The term PSTN is used here to include all manner of switching;
       i.e. wireline circuit-switched network, as well as the wireless
       circuit-switched network.

       In general terms, an Internet host is interested in getting
       notifications of certain events occurring in the PSTN.  When the
       event of interest occurs, the PSTN notifies the Internet host.  The
       Internet host can execute appropriate services based on these
       notifications.

    Gurbani, et al.             Standards Track                     [Page 3]

    RFC 3910                    SPIRITS Protocol                October 2004

                                 +------+
                                 | PSTN |
                                 |Events|
                                 +------+
                                /       \
                               /         \
                      +-------+           +--------+
                      |Call   |           |Non-Call|
                      |Related|           |Related |
                      +-------+           +--+-----+
                     /        \              |
                    /          \             |
               +---/--+     +---\---+     +--+-----------------+
               |Static|     |Dynamic|     |Mobility Management/|
               |      |     |       |     |Registration/De-    |
               +------+     +-------+     |registration        |
                                          +--------------------+

                         Figure 1: The SPIRITS Hierarchy.

       Figure 1 contains the SPIRITS events hierarchy, including their
       subdivision in two discrete classes for service execution: events
       related to the setup, teardown and maintenance of a call and events
       un-related to call setup, teardown or maintenance.  Example of the
       latter class of events are geo-location mobility events that are
       tracked by the cellular PSTN.  SPIRITS will specify the framework to
       provide services for both of these types of events.

       Call-related events, its further subdivisions, and how they enable
       services in the Internet is contained in Section 5.  Services enabled
       from events not related to call setup, teardown, or maintenance are
       covered in detail in Section 6.

       For reference, the SPIRITS architecture from [1] is reproduced below.
       This document is focused on interfaces B and C only.  Interface D is
       a matter of local policy; the PSTN operator may have a functional
       interface between the SPIRITS client or a message passing interface.
       This document does not discuss interface D in any detail.

    Gurbani, et al.             Standards Track                     [Page 4]

    RFC 3910                    SPIRITS Protocol                October 2004

                 +--------------+
                 | Subscriber's |
                 |   IP Host    |              +--------------+
                 |              |              |              |
                 | +----------+ |              | +----------+ |
                 | | PINT     | |      A       | | PINT     | |
                 | |  Client  +<-------/-------->+  Gateway +<-----+
                 | +----------+ |              | +----------+ |    |
                 |              |              |              |    |
                 | +----------+ |              | +----------+ |    |
                 | | SPIRITS  | |      B       | | SPIRITS  | |    |
                 | |  Server  +<-------/-------->+  Gateway | |    |
                 | +----------+ |              | +--------+-+ |    |
                 |              |              |          ^   |    |
                 +--------------+              +----------|---+    |
                                                          |        |
                                          IP Network      |        |
                ------------------------------------------|--------|---
                                          PSTN            / C      / E
                                                          |        |
                                                          v        |
                                                     +----+------+ |
                                                     | SPIRITS   | |
                                                     |   Client  | v
                   +-------------------+         +---+-----D-----+-++
                   | Service Switching |INAP/SS7 | Service Control  |
                   |    Function       +---------+     Function     |
                   +----+--------------+         +------------------+
                        |
                        |line
                       +-+
                       [0] Subscriber's telephone

                        Figure 2: The SPIRITS Architecture.

         (Note: The interfaces A-E are described in detail in the SPIRITS
                            Architecture document [1].)

       The PSTN today supports service models such as the Intelligent
       Network (IN), whereby some features are executed locally on switching
       elements called Service Switching Points (SSPs).  Other features are
       executed on service elements called Service Control Points (SCPs).
       The SPIRITS architecture [1] permits these SCP elements to act as
       intelligent entities to leverage and use Internet hosts and
       capabilities to further enhance the telephone end-user's experience.

    Gurbani, et al.             Standards Track                     [Page 5]

    RFC 3910                    SPIRITS Protocol                October 2004

       The protocol used on interfaces B and C consists of the SPIRITS
       protocol, and is based on SIP and SIP event notification [3].  The
       requirements of a SPIRITS protocol and the choice of using SIP as an
       enabler are detailed in [4].

       The SPIRITS protocol is a set of two "event packages" [3].  It
       contains the procedural rules and semantic context that must be
       applied to these rules for processing SIP transactions.  The SPIRITS
       protocol has to carry subscriptions for events from the SPIRITS
       server to the SPIRITS client and notifications of these events from
       the SPIRITS client to the SPIRITS server.  Extensible Markup Language
       (XML) [12] is used to codify the subscriptions and notifications.

       Finally, in the context of ensuing discussion, the terms "SPIRITS
       server" and "SPIRITS client" are somewhat confusing since the roles
       appear reversed; to wit, the "SPIRITS server" issues a subscription
       which is accepted by a "SPIRITS client".  To mitigate such ambiguity,
       from now on, we will refer to the "SPIRITS server" as a "SPIRITS
       subscriber" and to the "SPIRITS client" as a "SPIRITS notifier".
       This convention adheres to the nomenclature outlined in [3]; the
       SPIRITS server in Figure 2 is a subscriber (issues subscriptions to
       events), and the SPIRITS client in Figure 2 is a notifier (issues
       notifications whenever the event of interest occurs).

    2.1.  Terminology

       For ease of reference, we provide a terminology of the SPIRITS actors
       discussed in the preceding above:

       Service Control Function (SCF): A PSTN entity that executes service
       logic.  It provides capabilities to influence the call processing
       occurring in the Service Switching Function (SSF).  For more
       information on how a SCF participates in the SPIRITS architecture,
       please see Sections 5 and 5.1.

       SPIRITS client: see SPIRITS notifier.

       SPIRITS server: see SPIRITS subscriber.

       SPIRITS notifier: A User Agent (UA) in the PSTN that accepts
       subscriptions from SPIRITS subscribers.  These subscriptions contain
       events that the SPIRITS subscribers are interested in receiving a
       notification for.  The SPIRITS notifier interfaces with the Service
       Control Function such that when the said event occurs, a notification
       will be sent to the relevant SPIRITS subscriber.

    Gurbani, et al.             Standards Track                     [Page 6]

    RFC 3910                    SPIRITS Protocol                October 2004

       SPIRITS subscriber: A UA in the Internet that issues a subscription
       containing events in the PSTN that it is interested in receiving a
       notification for.

    3.  Using XML for subscription and notification

       The SPIRITS protocol requirements mandate that "SPIRITS-related
       parameters be carried in a manner consistent with SIP practices"
       (RFC3298:Section 3).  SIP already provides payload description
       capabilities through the use of headers (Content-Type, Content-
       Length).  This document defines a new MIME type --
       "application/spirits-event+xml" -- and registers it with IANA
       (Section 7).  This MIME type MUST be present in the "Content-Type"
       header of SPIRITS requests and responses, and it describes an XML
       document that contains SPIRITS-related information.

       This document defines a base XML schema for subscriptions to PSTN
       events.  The list of events that can be subscribed to is defined in
       the SPIRITS protocol requirements document [4] and this document
       provides an XML schema for it.  All SPIRITS subscribers (any SPIRITS
       entity capable of issuing a SUBSCRIBE, REGISTER, or INVITE request)
       MUST support this schema.  All SPIRITS notifiers (any SPIRITS entity
       capable of receiving and processing a SUBSCRIBE, REGISTER, or INVITE
       request) MUST support this schema.  The schema is defined in Section
       9.

          The support for the SIP REGISTER request is included for PINT
          compatibility (RFC3298:Section 6).

          The support for the SIP INVITE request is mandated because pre-
          existing SPIRITS implementations did not use the SIP event
          notification scheme.  Instead, the initial PSTN detection point
          always arrived via the SIP INVITE request.

       This document also defines a base XML schema for notifications of
       events (Section 9).  All SPIRITS notifiers MUST generate XML
       documents that correspond to the base notification  schema.  All
       SPIRITS subscribers MUST support XML documents that correspond to
       this schema.

       The set of events that can be subscribed to and the amount of
       notification that is returned by the PSTN entity may vary among
       different PSTN operators.  Some PSTN operators may have a rich set of
       events that can be subscribed to, while others have only the
       primitive set of events outlined in the SPIRITS protocol requirements
       document [4].  This document defines a base XML schema (in Section 9)
       which MUST be used for the subscription and notification of the
       primitive set of events.  In order to support a richer set of event

    Gurbani, et al.             Standards Track                     [Page 7]

    RFC 3910                    SPIRITS Protocol                October 2004

       subscription and notification, implementations MAY use additional XML
       namespaces corresponding to alternate schemas in a SPIRITS XML
       document.  However, all implementations MUST support the base XML
       schema defined in Section 9 of this document.  Use of the base schema
       ensures interoperability across implementations, and the inclusion of
       additional XML namespaces allows for customization.

       A logical flow of the SPIRITS protocol is depicted below (note: this
       example shows a temporal flow; XML documents and related SPIRITS
       protocol syntax is specified in later sections of this document).  In
       the flow below, S is the SPIRITS subscriber and N is the SPIRITS
       notifier.  The SPIRIT Gateway is presumed to have a pure proxying
       functionality and thus is omitted for simplicity:

       1  S->N Subscribe (events of interest in an XML document instance
                          using base subscription schema)
       2  N->S 200 OK (Subscribe)
       3  N->S Notify
       4  S->N 200 OK (Notify communicating current resource state)
       5  ...
       6  N->S Notify (Notify communicating change in resource state;
                       payload is an XML document instance using
                       XML extensions to the base notification schema)
       7  S->N 200 OK (Notify)

       In line 1, the SPIRITS subscriber subscribes to certain events using
       an XML document based on the base schema defined in this document.
       In line 6, the SPIRITS notifier notifies the SPIRITS subscriber of
       the occurrence of the event using extensions to the base notification
       schema.  Note that this document defines a base schema for event
       notification as well; the SPIRITS notifier could have availed itself
       of these.  Instead, it chooses to pass to the SPIRITS subscriber an
       XML document composed of extensions to the base notification schema.
       The SPIRITS subscriber, if it understands the extensions, can
       interpret the XML document accordingly.  However, in the event that
       the SPIRITS subscriber is not programmed to understand the
       extensions, it MUST search the XML document for the mandatory
       elements.  These elements MUST be present in all notification schemas
       and are detailed in Section 9.

    4.  XML format definition

       This section defines the XML-encoded SPIRITS payload format.  Such a
       payload is a well formed XML document and is produced by SPIRITS
       notifiers and SPIRITS subscribers.

    Gurbani, et al.             Standards Track                     [Page 8]

    RFC 3910                    SPIRITS Protocol                October 2004

       The namespace URI for elements defined in this document is a Uniform
       Resource Name (URN) [14], using the namespace identifier 'ietf'
       defined in [15] and extended by [16]:

          urn:ietf:params:xml:ns:spirits-1.0

       SPIRITS XML documents may have a default namespace, or they may be
       associated with a namespace prefix following the convention
       established in XML namespaces [17].  Regardless, the elements and
       attributes of SPIRITS XML documents MUST conform to the SPIRITS XML
       schema specified in Section 9.

       The <spirits-event> element
          The root of a SPIRITS XML document (characterized by a Content-
          Type header of "application/spirits-event+xml">) is the <spirits-
          event> element.  This element MUST contain a namespace declaration
          ('xmlns') to indicate the namespace on which the XML document is
          based.  XML documents compliant to the SPIRITS protocol MUST
          contain the URN "urn:ietf:params:xml:ns:spirits-1.0" in the
          namespace declaration.  Other namespaces may be specified as
          needed.

          <spirits-event> element MUST contain at least one <Event> element,
          and MAY contain more than one.

       The <Event> element
          The <Event> element contains three attributes, two of which are
          mandatory.  The first mandatory attribute is a 'type' attribute
          whose value is either "INDPs" or "userprof".

          These types correspond, respectively, to call-related events
          described in Section 5 and non-call related events described in
          Section 6.

          The second mandatory attribute is a 'name' attribute.  Values for
          this attribute MUST be limited to the SPIRITS mnemonics defined in
          Section 5.2.1, Section 5.2.2, and Section 6.1.

          The third attribute, which is optional, is a 'mode' attribute.
          The value of 'mode' is either "N" or "R", corresponding
          respectively to (N)otification or (R)equest (RFC3298:Section 4).
          The default value of this attribute is "N".

          If the 'type' attribute of the <Event> element is "INDPs", then it
          MUST contain at least one or more of the following elements
          (unknown elements MAY be ignored):  <CallingPartyNumber>,
          <CalledPartyNumber>, <DialledDigits>, or <Cause>.  These elements

    Gurbani, et al.             Standards Track                     [Page 9]

    RFC 3910                    SPIRITS Protocol                October 2004

          are defined in Section 5.2; they MUST not contain any attributes
          and MUST not be used further as parent elements.  These elements
          contain a string value as described in Section 5.2.1 and 5.2.2.

          If the 'type' attribute of the <Event> element is "userprof", then
          it MUST contain a <CalledPartyNumber> element and it MAY contain a
          <Cell-ID> element.  None of these elements contain any attributes
          and neither must be used further as a parent element.  These
          elements contain a string value as described in Section 6.1.  All
          other elements MAY be ignored if not understood.

       A SPIRITS-compliant XML document using the XML namespace defined in
       this document might look like the following example:

       <?xml version="1.0" encoding="UTF-8"?>
       <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
          <Event type="INDPs" name="OD" mode="N">
             <CallingPartyNumber>5551212</CallingPartyNumber>
          </Event>
          <Event type="INDPs" name="OAB" mode="N">
             <CallingPartyNumber>5551212</CallingPartyNumber>
          </Event>
       </spirits-event>

    5.  Call-related events

       For readers who may not be familiar with the service execution
       aspects of PSTN/IN, we provide a brief tutorial next.  Interested
       readers are urged to consult [19] for a detailed treatment of this
       subject.

       Services in the PSTN/IN are executed based on a call model.  A call
       model is a finite state machine used in SSPs and other call
       processing elements that accurately and concisely reflects the
       current state of a call at any given point in time.  Call models
       consist of states called PICs (Points In Call) and transitions
       between states.  Inter-state transitions pass through elements called
       Detection Points or DPs.  DPs house one or more triggers.  Every
       trigger has a firing criteria associated with it.  When a trigger is
       armed (made active), and its associated firing criteria are
       satisfied, it fires.  The particulars of firing criteria may vary
       based on the call model being supported.

       When a trigger fires, a message is formatted with call state
       information and transmitted by the SSP to the SCP.  The SCP then
       reads this call related data and generates a response which the SSP
       then uses in further call processing.

    Gurbani, et al.             Standards Track                    [Page 10]

    RFC 3910                    SPIRITS Protocol                October 2004

       Detection Points are of two types: TDPs (or Trigger Detection
       Points), and EDPs (or Event Detection Points).  TDPs are provisioned
       with statically armed triggers (armed through Service Management
       Tools).  EDPs are dynamically armed triggers (armed by the SCP as
       call processing proceeds).  DPs may also be classified as "Request"
       or "Notification" DPs.  Thus, one can have TDP-R's, TDP-N's, EDP-R's
       and EDP-N's.

       The "-R" type of DPs require the SSP to suspend call processing when
       communication with the SCP is initiated.  Call processing resumes
       when a response is received.  The "-N" type of DPs enable the SSP to
       continue with call processing when the trigger fires, after it sends
       out the message to the SCP, notifying it that a certain event has
       occurred.

       Call models typically support different types of detection points.
       Note that while INAP and the IN Capability Set (CS)-2 [7] call model
       are used in this document as examples, and for ease of explanation,
       other call models possess similar properties.  For example, the
       Wireless Intelligent Network (WIN) call model also supports the
       dynamic arming of triggers.  Thus, the essence of this discussion
       applies not just to the wireline domain, but applies equally well to
       the wireless domain as well.

       When the SCP receives the INAP formatted message from the SSP, if the
       SCP supports the SPIRITS architecture, it can encode the INAP message
       contents into a SPIRITS protocol message which is then transmitted to
       SPIRITS-capable elements in the IP network.  Similarly, when it
       receives responses back from said SPIRITS capable elements, it can
       reformat the response content into the INAP format and forward these
       messages back to SSPs.  Thus the process of inter-conversion and/or
       encoding between the INAP parameters and the SPIRITS protocol is of
       primary interest.

       An SCP is a physical manifestation of the Service Control Function.
       An SSP is a physical manifestation of the Service Switching Function
       (and the Call Control Function).  To support uniformity of
       nomenclature between the various SPIRITS drafts, we shall use the
       terms SCP and SCF, and SSP and SSF interchangeably in this document.

    5.1.  IN-specific requirements

       Section 4 of [4] outlines the IN-related requirements on the SPIRITS
       protocol.  The SUBSCRIBE request arriving at the SPIRITS notifier
       MUST contain the events to be monitored (in the form of a DP list),
       the mode (request or a notification, the difference being that for a

    Gurbani, et al.             Standards Track                    [Page 11]

    RFC 3910                    SPIRITS Protocol                October 2004

       request, the SPIRITS subscriber can influence subsequent call
       processing and for a notification, no further influence is needed),
       and any DP-related parameters.

       Section 4 of [4] also enumerates a list of Capability Set 3 (CS-3)
       DPs for SPIRITS services.  It is a requirement (RFC3298:Section 4)
       that the SPIRITS protocol specify the relevant parameters of the DPs.
       These DPs and their relevant parameters to be carried in a SUBSCRIBE
       request are codified in an XML schema.  All SPIRITS subscribers MUST
       understand this schema for subscribing to the DPs in the PSTN.  The
       schema is defined in Section 9.

       When a DP fires, a notification -- using a SIP NOTIFY request -- is
       transmitted from the SPIRITS notifier to the SPIRITS subscriber.  The
       NOTIFY request contains an XML document which describes the DP that
       fired and any relevant parameters.  The DPs and their relevant
       parameters to be carried in a NOTIFY request are codified in an XML
       schema.  All SPIRITS notifiers MUST understand this schema; this
       schema MAY be extended.  The schema is defined in Section 9.

       In addition, Appendices A and B of [6] contain a select subset of
       CS-2 DPs that may be of interest to the reader.  However, this
       document will only refer to CS-3 DPs outlined in [4].

    5.2.  Detection points and required parameters

       The IN CS-3 DPs envisioned for SPIRITS services (RFC3298:Section 4)
       are described next.  IN DPs are characterized by many parameters,
       however, not all such parameters are required -- or even needed -- by
       SPIRITS.  This section, thus, serves to list the mandatory parameters
       for each DP that MUST be specified in subscriptions and
       notifications.  Implementations can specify additional parameters as
       XML extensions associated with a private (or public and standardized)
       namespace.

       The exhaustive list of IN CS-3 DPs and their parameters can be found
       in reference [13].

       Each DP is given a SPIRITS-specific mnemonic for use in the
       subscriptions and notifications.

    5.2.1.  Originating-side DPs

       Origination Attempt Authorized
       SPIRITS mnemonic: OAA
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

    Gurbani, et al.             Standards Track                    [Page 12]

    RFC 3910                    SPIRITS Protocol                October 2004

       CallingPartyNumber: A string used to identify the calling party for
       the call.  The actual length and encoding of this parameter depend on
       the particulars of the dialing plan used.

       CalledPartyNumber: A string containing the number (e.g., called
       directory number) used to identify the called party.  The actual
       length and encoding of this parameter depend on the particulars of
       the dialing plan used.

       Collected Information
       SPIRITS mnemonic: OCI
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits

       DialledDigits: This parameter contains non-translated address
       information collected/received from the originating user/line/trunk

       Analyzed Information
       SPIRITS mnemonic: OAI
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits

       Origination Answer
       SPIRITS mnemonic: OA
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

       Origination Term Seized
       SPIRITS mnemonic: OTS
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

       Origination No Answer
       SPIRITS mnemonic: ONA
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

       Origination Called Party Busy
       SPIRITS mnemonic: OCPB
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

       Route Select Failure
       SPIRITS mnemonic: ORSF
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

    Gurbani, et al.             Standards Track                    [Page 13]

    RFC 3910                    SPIRITS Protocol                October 2004

       Origination Mid Call
       SPIRITS mnemonic: OMC
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameter in NOTIFY: CallingPartyNumber

       Origination Abandon
       SPIRITS mnemonic: OAB

       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameter in NOTIFY: CallingPartyNumber

       Origination Disconnect
       SPIRITS mnemonic: OD
       Mandatory parameter in SUBSCRIBE: CallingPartyNumber
       Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

    5.2.2.  Terminating-side DPs

       Termination Answer
       SPIRITS mnemonic: TA
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

       Termination No Answer
       SPIRITS mnemonic: TNA Mandatory parameter in SUBSCRIBE:
       CalledPartyNumber
       Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

       Termination Mid-Call
       SPIRITS mnemonic: TMC
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameter in NOTIFY: CalledPartyNumber

       Termination Abandon
       SPIRITS mnemonic: TAB
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameter in NOTIFY: CalledPartyNumber

       Termination Disconnect
       SPIRITS mnemonic: TD
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber

       Termination Attempt Authorized
       SPIRITS mnemonic: TAA
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber

    Gurbani, et al.             Standards Track                    [Page 14]

    RFC 3910                    SPIRITS Protocol                October 2004

       Termination Facility Selected and Available
       SPIRITS mnemonic: TFSA
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameter in NOTIFY: CalledPartyNumber

       Termination Busy
       SPIRITS mnemonic: TB
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameters in NOTIFY: CalledPartyNumber,
       CallingPartyNumber, Cause

       Cause: This parameter contains a string value of either "Busy" or
       "Unreachable".  The difference between these is translated as a
       requirement (RFC3298:Section 5) to aid in the SPIRITS subscriber in
       determining if the called party is indeed busy (engaged), or if the
       called party is unavailable (as it would be if it were on the
       cellular PSTN and the mobile subscriber was not registered with the
       network).

    5.3.  Services through dynamic DPs

       Triggers in the PSTN can be armed dynamically, often outside the
       context of a call.  The SIP event notification mechanism [3] is,
       therefore, a convenient means to exploit in those cases where
       triggers housed in EDPs fire (see section 3 of [4]).  Note that [4]
       uses the term "persistent" to refer to call-related DP arming and
       associated interactions.

       The SIP Events Package enables IP endpoints (or hosts) to subscribe
       to and receive subsequent notification of events occurring in the
       PSTN.  With reference to Figure 2, this includes communication on the
       interfaces marked "B" and "C".

    5.3.1.  Normative usage

       A subscriber will issue a SUBSCRIBE request which identifies a set of
       events (DPs) it is interested in getting the notification of.  This
       set MUST contain at least one DP, it MAY contain more than one.  The
       SUBSCRIBE request is routed to the notifier, where it is accepted,
       pending a successful authentication.

       When any of the DPs identified in the set of events fires, the
       notifier will format a NOTIFY request and direct it towards the
       subscriber.  The NOTIFY request will contain information pertinent to
       the event that was triggered.  The un-encountered DPs MUST be
       subsequently dis-armed by the SPIRITS notifier and/or the SCF.

    Gurbani, et al.             Standards Track                    [Page 15]

    RFC 3910                    SPIRITS Protocol                October 2004

       The dialog established by the SUBSCRIBE terminates when the event of
       interest occurs and this notification is passed to the subscriber
       through a NOTIFY request.  If the subscriber is interested in the
       future occurrence of the same event, it MUST issue a new SUBSCRIBE
       request, establishing a new dialog.

       When the subscriber receives a NOTIFY request, it can subsequently
       choose to act in a manner appropriate to the notification.

       The remaining sections fill in the specific package responsibilities
       raised in RFC3265 [3], Section 4.4.

    5.3.2.  Event package name

       This document defines two event packages; the first of these is
       defined in this section and is called "spirits-INDPs".  This package
       MUST be used for events corresponding to IN detection points in the
       cellular or wireline PSTN.  All entities that implement the SPIRITS
       protocol and support IN detection points MUST set the "Event" request
       header [3] to "spirits-INDPs."  The "Allow-Events" general header [3]
       MUST include the token "spirits-INDPs" if the entity implements the
       SPIRITS protocol and supports IN detection points.

          Event: spirits-INDPs
          Allow-Events: spirits-INDPs

       The second event package is defined and discussed in Section 6.

    5.3.3.  Event package parameters

       The "spirits-INDPs" event package does not support any additional
       parameters to the Event header.

    5.3.4.  SUBSCRIBE bodies

       SUBSCRIBE requests that serve to terminate the subscription MAY
       contain an empty body; however, SUBSCRIBE requests that establish a
       dialog MUST contain a body which encodes three pieces of information:

          (1) The set of events (DPs) that is being subscribed to.  A
          subscriber MAY subscribe to multiple DPs in one SUBSCRIBE request,
          or MAY issue a different SUBSCRIBE request for each DP it is
          interested in receiving a notification for.  The protocol allows
          for both forms of representation, however, it recommends the
          former manner of subscribing to DPs if the service depends on any
          of the DPs being triggered.

    Gurbani, et al.             Standards Track                    [Page 16]

    RFC 3910                    SPIRITS Protocol                October 2004

          (2) Because of the requirement [4] that IN be informed whether the
          detection point is set as the request or notification, all events
          in the "spirits-INDPs" package (but not in the "spirits-user-prof"
          package) are required to provide a "mode" parameter, whose values
          are "R" (for Request) and "N" for notification.

          (3) A list of the values of the parameters associated with the
          event detection point (Note: the term "event" here refers to the
          IN usage -- a dynamically armed DP is called an Event Detection
          Point).  Please see Section 5.2.1 and Section 5.2.2 for a list of
          parameters associated with each DP.

       The default body type for SUBSCRIBEs in SPIRITS is denoted by the
       MIME type "application/spirits-event+xml".  The "Accept" header, if
       present, MUST include this MIME type.

    5.3.5.  Subscription duration

       For package "spirits-INDPs", the purpose of the SUBSCRIBE request is
       to arm the DP, since as far as IN is concerned, being armed is the
       first essential pre-requisite.  A DP maybe armed either statically
       (for instance, through service provisioning), or dynamically (by the
       SCF).  A statically armed DP remains armed until it is disarmed
       proactively.  A dynamically armed DP remains armed for the duration
       of a call (or more appropriately, no longer than the duration of a
       particular SSF-SCF relationship).

       Dynamically armed DPs are automatically disarmed when the event of
       interest occurs in the notifier.  It is up to the subscriber to re-
       arm the DPs within the context of a call, if it so desires.

       Statically armed DPs are considered outside the scope of the SPIRITS
       protocol requirements [4] and thus will not be considered any
       further.

    5.3.6.  NOTIFY bodies

       Bodies in NOTIFY requests for the "spirits-INDPs" package are
       optional.  If present, they MUST be of the MIME type
       "application/spirits-event+xml".  The body in a NOTIFY request
       encapsulates the following pieces of information which can be used by
       the subscriber:

          (1) The event that resulted in the NOTIFY being generated
          (typically, but not always, this will be the same event present in
          the corresponding SUBSCRIBE request).

    Gurbani, et al.             Standards Track                    [Page 17]

    RFC 3910                    SPIRITS Protocol                October 2004

          (2) The "mode" parameter; it is simply reflected back from the
          corresponding SUBSCRIBE request.

          (3) A list of values of the parameters associated with the event
          that the NOTIFY is being generated for.  Depending on the actual
          event, the list of the parameters will vary.

       If the subscriber armed multiple DPs as part of a single SUBSCRIBE
       request, all the un-encountered DPs that were part of the same
       SUBSCRIBE dialog MUST be dis-armed by the SPIRITS notifier and/or the
       SCF/SCP.

    5.3.7.  Notifier processing of SUBSCRIBE requests

       When the notifier receives a SUBSCRIBE request, it MUST authenticate
       the request and ensure that the subscriber is authorized to access
       the resource being subscribed to, in this case, PSTN/IN events on a
       certain PSTN line.

       Once the SUBSCRIBE request has been authenticated and authorized, the
       notifier interfaces with the SCF over interface D to arm the
       detection points corresponding to the PSTN line contained in the
       SUBSCRIBE body.  The particulars about interface D is out of scope
       for this document; here we will simply assume that the notifier can
       affect the arming (and disarming) of triggers in the PSTN through
       interface D.

    5.3.8.  Notifier generation of NOTIFY requests

       If the notifier expects the arming of triggers to take more than 200
       ms, it MUST send a 202 response to the SUBSCRIBE request immediately,
       accepting the subscription.  It should then send a NOTIFY request
       with an empty body.  This NOTIFY request MUST have a "Subscription-
       State" header with a value of "pending".

             This immediate NOTIFY with an empty body is needed since the
             resource identified in the SUBSCRIBE request does not have as
             yet a meaningful state.

       Once the notifier has successfully interfaced with the SCF, it MUST
       send a subsequent NOTIFY request with an empty body and a
       "Subscription-State" header with a value of "active."

       When the event of interest identified in the SUBSCRIBE request
       occurs, the notifier sends out a new NOTIFY request which MUST
       contain a body (see Section 5.3.6).  The NOTIFY request MUST have a
       "Subscription-State" header and its value MUST be set to "terminated"
       with a reason parameter of "fired".

    Gurbani, et al.             Standards Track                    [Page 18]

    RFC 3910                    SPIRITS Protocol                October 2004

    5.3.9.  Subscriber processing of NOTIFY requests

       The exact steps executed at the subscriber when it gets a NOTIFY
       request will depend on the service being implemented.  As a
       generality, the UA associated with the subscriber should somehow
       impart this information to the user by visual or auditory means, if
       at all possible.

       If the NOTIFY request contained a "Subscription-State" header with a
       value of "terminated" and a reason parameter of "fired", the UA
       associated with the subscriber MAY initiate a new subscription for
       the event that was just reported through the NOTIFY request.

             Whether or not to initiate a new subscription when an existing
             one expires is up to the context of the service that is being
             implemented.  For instance, a user may configure her UA to
             always re-subscribe to the same event when it fires, but this
             is not necessarily the normative case.

    5.3.10.  Handling of forked requests

       Forking of SUBSCRIBE requests is prohibited.  Since the SUBSCRIBE
       request is targeted towards the PSTN, highly irregular behaviors
       occur if the request is allowed to fork.  The normal SIP DNS lookup
       and routing rules [11] should result in a target set with exactly one
       element: the notifier.

    5.3.11.  Rate of notifications

       For reasons of security more than network traffic, it is RECOMMENDED
       that the notifier issue two or, at most three NOTIFY requests for a
       subscription.  If the subscription was accepted with a 202 response,
       a NOTIFY will be sent immediately towards the subscriber.  This
       NOTIFY serves to inform the subscriber that the request has been
       accepted and is being acted on.

       Once the resource (detection points) identified in the SUBSCRIBE
       request have been initialized, the notifier MUST send a second NOTIFY
       request.  This request contains the base state of the resource.

       When an event of interest occurs which leads to the firing of the
       trigger associated with the detection points identified in the
       SUBSCRIBE request, a final NOTIFY is sent to the subscriber.  This
       NOTIFY request contains more information about the event of interest.

    Gurbani, et al.             Standards Track                    [Page 19]

    RFC 3910                    SPIRITS Protocol                October 2004

       If the subscription was accepted with a 200 response, the notifier
       simply sends two NOTIFY requests: one containing the base state of
       the resource, and the other containing information that lead to the
       firing of the detection point.

    5.3.12.  State agents

       State agents are not used in SPIRITS.

    5.3.13.  Examples

       This section contains example call flows for a SPIRITS service called
       Internet Caller-ID Delivery (ICID).  One of the benchmark SPIRITS
       service, as described in section 2.2 of [1] is Internet Caller-ID
       delivery:

          This service allows the subscriber to see the caller's number or
          name or both while being connected to the Internet.  If the
          subscriber has only one telephone line and is using the very line
          for the Internet connection, the service is a subset of the ICW
          service and follows the relevant description in Section 2.1.
          Otherwise, the subscriber's IP host serves as an auxiliary device
          of the telephone to which the call is first sent.

       We present an example of a SPIRITS call flow to realize this service.
       Note that this is an example only, not a normative description of the
       Internet Caller-ID service.

       Further text and details of SIP messages below refer to the call flow
       provided in Figure 3.  Figure 3 depicts the 4 entities that are an
       integral part of any SPIRITS service (the headings of the entities
       refer to the names established in Figure 1 in [1]) -- the SPIRITS
       subscriber, the SPIRITS notifier and the SCF.  Note that the SPIRITS
       gateway is not included in this figure; logically, SPIRITS messages
       flow between the SPIRITS server and the SPIRITS client.  A gateway,
       if present, may act as a proxy.

    Gurbani, et al.             Standards Track                    [Page 20]

    RFC 3910                    SPIRITS Protocol                October 2004

          SPIRITS server       SPIRITS client      SCF
          ("subscriber")        ("notifier")
             S                      N
             |                      |                |
             | F1 SUBSCRIBE         |                |
             +--------------------->+                |
             |                      |                |
             |                      | F2 Arm DP      |
             |     F3 200 OK (SUBS) +--------------->|
             |<---------------------|                |
             |                      |                |
             |            F4 NOTIFY |                |
             |<---------------------+                |
             |                      |                |
             |      F5 200 OK (NOT) |                |
             +--------------------->|                |
             |                      |                |
             ~                      ~                ~
             ~                      ~                ~
             |                      |  F6 Evt. Not.  |
             |                      |<---------------+
             |            F7 NOTIFY +                |
             |<---------------------|                |
             |                      |                |
             |      F8 200 OK (NOT) |                |
             +--------------------->|                |
             |                      |                |
             |                      |                |
            \|/                    \|/              \|/
             v                      v                v

                            Figure 3: Sample call flow

       This call flow depicts an overall operation of a "subscriber"
       successfully subscribing to the IN Termination_Attempt_Authorized DP
       (the "subscriber" is assumed to be a user, possibly at work, who is
       interested in knowing when he/she gets a phone call to his/her home
       phone number) -- this interaction is captured in messages F1 through
       F8 in Figure 3.  The user sends (F1) a SIP SUBSCRIBE request
       identifying the DP it is interested in along with zero or more
       parameters relevant to that DP (in this example, the
       Termination_Attempt_DP will be employed).  The SPIRITS notifier in
       turns interacts with the SCF to arm the Termination_Attempt_DP for
       the service (F2).  An immediate NOTIFY with the current state
       information is send to the subscriber (F4, F5).

    Gurbani, et al.             Standards Track                    [Page 21]

    RFC 3910                    SPIRITS Protocol                October 2004

       At some point  after the above sequence of events has transpired, the
       PSTN gets a call to the users phone.  The SSF informs the SCF of this
       event when it encounters an armed Termination_Attempt_DP (not shown
       in Figure 3).  The SCF informs the SPIRITS notifier of this event
       (F6).

       When the SPIRITS notifier receives this event, it forms a SIP NOTIFY
       request and directs it to the SPIRITS subscriber (F7).  This NOTIFY
       will contain all the information elements necessary to identify the
       caller to the subscriber.  The subscriber, upon receiving the
       notification (F8) may pop open a window with the date/time and the
       number of the caller.

       The rest of this section contains the details of the SIP messages in
       Figure 3.  The call flow details below assume that the SPIRITS
       gateway is, for the purpose of this example, a SIP proxy that serves
       as the default outbound proxy for the notifier and an ingress host of
       the myprovider.com domain for the subscriber.  The subscriber and
       notifier may be in separate administrative domains.

       F1: S->N

       SUBSCRIBE sip:myprovider.com SIP/2.0
       From: <sip:vkg@example.com>;tag=8177-afd-991
       To: <sip:16302240216@myprovider.com>
       CSeq: 18992 SUBSCRIBE
       Call-ID: 3329as77@host.example.com
       Contact: <sip:vkg@host.example.com>
       Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
       Expires: 3600
       Event: spirits-INDPs
       Allow-Events: spirits-INDPs, spirits-user-prof
       Accept: application/spirits-event+xml
       Content-Type: application/spirits-event+xml
       Content-Length: ...

       <?xml version="1.0" encoding="UTF-8"?>
       <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
          <Event type="INDPs" name="TAA" mode="N">
                <CalledPartyNumber>6302240216</CalledPartyNumber>
          </Event>
       </spirits-event>

       The subscriber forms a SIP SUBSCRIBE request which identifies the DP
       that it wants to subscribe to (in this case, the TAA DP) and the
       actual line it wants that DP armed for (in this case, the line

    Gurbani, et al.             Standards Track                    [Page 22]

    RFC 3910                    SPIRITS Protocol                October 2004

       associated with the phone number 6302240216).  This request
       eventually arrives at the SIPRITS notifier, N, which authenticates it
       (not shown) and sends a successful response to the subscriber:

       F3: N->S

       SIP/2.0 200 OK
       From: <sip:vkg@example.com>;tag=8177-afd-991
       To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
       CSeq: 18992 SUBSCRIBE
       Call-ID: 3329as77@host.example.com
       Contact: <sip:notifier.myprovider.com>
       Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
       Expires: 3600
       Accept: application/spirits-event+xml
       Content-Length: 0

       The notifier interacts with the SCF to arm the DP and also sends an
       immediate NOTIFY towards the subscriber informing the subscriber of
       the current state of the notification:

       F4: N->S

       NOTIFY sip:vkg@host.example.com SIP/2.0
       From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
       To: <sip:vkg@example.com>;tag=8177-afd-991
       Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
       Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
       Call-ID: 3329as77@host.example.com
       Contact: <sip:notifier.myprovider.com>
       Subscription-State: active
       CSeq: 3299 NOTIFY
       Accept: application/spirits-event+xml
       Content-Length: 0

       F5: S->N

       SIP/2.0 200 OK
       From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
       To: <sip:vkg@example.com>;tag=8177-afd-991
       Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
       Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
       Call-ID: 3329as77@host.example.com
       Contact: <sip:vkg@host.example.com>
       CSeq: 3299 NOTIFY
       Accept: application/spirits-event+xml
       Content-Length: 0

    Gurbani, et al.             Standards Track                    [Page 23]

    RFC 3910                    SPIRITS Protocol                October 2004

       At some later point in time (before the subscription established in
       F1 expires at the notifier), a call arrives at the number identified
       in XML-encoded body of F1 -- 6302240216.  The SCF notifies the
       notifier (F6).  Included in this notification is the relevant
       information from the PSTN, namely, the phone number of the party
       attempting to call 6302240216.  The notifier uses this information to
       create a SIP NOTIFY request and sends it to the subscriber.  The SIP
       NOTIFY request has a XML-encoded body with the relevant information
       from the PSTN:

       F7: N->S

       NOTIFY sip:vkg@host.example.com SIP/2.0
       From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
       To: <sip:vkg@example.com>;tag=8177-afd-991
       Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK9inn-=u7
       Call-ID: 3329as77@host.example.com
       Contact: <sip:notifier.myprovider.com>
       CSeq: 3300 NOTIFY
       Subscription-State: terminated;reason=fired
       Accept: application/spirits-event+xml
       Event: spirits-INDPs
       Allow-Events: spirits-INDPs, spirits-user-prof
       Content-Type: application/spirits-event+xml
       Content-Length: ...

       <?xml version="1.0" encoding="UTF-8"?>
       <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
          <Event type="INDPs" name="TAA" mode="N">
                <CalledPartyNumber>6302240216</CalledPartyNumber>
                <CallingPartyNumber>3125551212</CallingPartyNumber>
          </Event>
       </spirits-event>

       There are two important issues to note in the call flows for F7:

          (1) The body of the NOTIFY request contains the information passed
              to the SPIRITS notifier from the SCF.  In this particular
              example, this is the phone number of the party (3125551212)
              that attempted to call 6302240216.

          (2) Since the notification occurred, the subscription established
              in F1 terminated (as evident by the Subscription-State
              header).  The subscription terminated normally due to the DP
              associated with TAA firing (hence the reason code of "fired"
              in the Subscription-State header).  If the subscriber

    Gurbani, et al.             Standards Track                    [Page 24]

    RFC 3910                    SPIRITS Protocol                October 2004

              wants to get notified of another attempt to call the number
              6302240216, he/she should send a new SUBSCRIBE request to the
              notifier.

       The subscriber can take any appropriate action upon the receipt of
       the NOTIFY in F7.  A reasonable implementation may pop up a window
       populated with the information contained in the body of F12, along
       with a button asking the subscriber if they would like to re-
       subscribe to the same event.  Alternatively, a re-subscription could
       be generated automatically by the subscriber's UA based on his/her
       preferences.

       To complete the protocol, the subscriber also sends a 200 OK message
       towards the notifier:

       F8: S->N

       200 OK SIP/2.0
       From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
       To: <sip:vkg@example.com>;tag=8177-afd-991
       Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7
       Call-ID: 3329as77@host.example.com
       CSeq: 3300 NOTIFY
       Content-Length: 0

    5.3.14.  Use of URIs to retrieve state

       The "spirits-INDPs" package MUST NOT use URIs to retrieve state.  It
       is expected that most state information for this package is compact
       enough to fit in a SIP message.  However, to err on the side of
       caution, implementations MUST follow the convention outlined in
       Section 18.1.1 of [5] and use a congestion controlled transport if
       the size of the request is within 200 bytes of the path MTU if known,
       or if the request size is larger than 1300 bytes and the path MTU is
       unknown.

    5.4.  Services through static DPs

       We mentioned in Section 5.1 that the first trigger that fires during
       call processing is typically a TDP since there isn't any pre-existing
       control relationship between the SSF and the SCF.  Some Internet
       hosts may have expressed an interest in executing services based on
       TDPs (through an a-priori arrangement, which is not a part of this
       specification).  Thus, the PSTN will notify such hosts.  To do so, it
       will send a SIP request (typically an INVITE) towards the Internet
       host.  The body of the SIP request MUST contain multi-part MIME with
       two MIME components: the first part corresponding to the normal
       payload, if any, of the request; and the second part will contain

    Gurbani, et al.             Standards Track                    [Page 25]

    RFC 3910                    SPIRITS Protocol                October 2004

       SPIRITS-specific information (e.g., the DP that fired).  Responses to
       the INVITE request, or subsequent SUBSCRIBE messages from the
       Internet host to the PSTN within a current call context may result in
       EDPs being armed.

    5.4.1.  Internet Call Waiting (ICW)

       ICW as a benchmark SPIRITS service actually predates SPIRITS itself.
       Pre-SPIRITS implementations of ICW are detailed in [10].  However, as
       the document notes, while a diversity of implementations exists,
       these implementations are not interoperable.  At the time [10] was
       published, the industry did not have the depth of experience with SIP
       as is the case now.  The use of SIP in [10] does not constitute
       normative usage of SIP as described in [5]; for instance, no mention
       is made of the SDP (if any) in the initial INVITE (especially since
       this pertains to "accept the call using VoIP" case).  Thus this
       section serves to provide a normative description of ICW in SPIRITS.

       The description of ICW is deceptively simple: it is a service most
       useful for single line phone subscribers that use the line to
       establish an Internet session.  In a nutshell, the service enables a
       subscriber engaged in an Internet dial-up session to

          o  be notified of an incoming call to the very same telephone line
             that is being used for the Internet connection,

          o  specify the desirable treatment of the call, and

          o  have the call handled as specified.

    5.4.2.  Call disposition choices

       Section 2 of [10] details the call disposition outcome of a ICW
       session.  They are reproduced here as a numbered list for further
       discussion:

          1. Accepting the call over the PSTN line, thus terminating the
          Internet (modem) connection

          2. Accepting the call over the Internet using Voice over IP (VoIP)

          3.  Rejecting the call

          4. Playing a pre-recorded message to the calling party and
          disconnecting the call

          5. Forwarding the call to voice mail

    Gurbani, et al.             Standards Track                    [Page 26]

    RFC 3910                    SPIRITS Protocol                October 2004

          6. Forwarding the call to another number

          7. Rejecting (or Forwarding) on no Response - If the subscriber
          fails to respond within a certain period of time after the dialog
          box has been displayed, the incoming call can be either rejected
          or handled based on the treatment pre-defined by the subscriber.

       It should be pointed out for the sake of completeness that ICW as a
       SPIRITS service is not possible without making the SCP aware of the
       fact that the subscriber line is being used for an Internet session.
       That awareness, however, is not a part of the ICW service, but solely
       a pre-requisite.  One of the following three methods MUST be utilized
       to impart this information to the SCP:

          A. ICW subscriber based method: the ICW client on the subscriber's
          PC notifies the SCP of the Internet session by issuing a SIP
          REGISTER request.

          B. IN based method: SCP maintains a list of Internet Service
          Provider (ISP) access numbers for a geographical area; when one of
          these numbers is dialed and connected to, it (the SCP) assumes
          that the calling party is engaged in an Internet session.

          C. Any combination of methods A and B.

       ICW depends on a TDP to be provisioned in the SSP.  When the said TDP
       is encountered, the SSP suspends processing of the call and sends a
       request to the SPIRITS-capable SCP.  The SCP determines that the
       subscriber line is being used for an Internet session.  It instructs
       the SPIRITS notifier on the SCP to create a SIP INVITE request and
       send it to the SPIRITS subscriber running on the subscriber's IP
       host.

       The SPIRITS subscriber MUST return one of the possible call
       disposition outcomes catalogued in Section 5.4.2.  Note that outcomes
       1 and 4 through 7 can all be coalesced into one case, namely
       redirecting (using the SIP 3xx response code) the call to an
       alternative SIP URI.  In case of 1, the URI of the redirected call
       MUST match the very same number being used by the customer to get
       online.  Rejecting the call implies sending a non-2xx and non-3xx
       final response; the remaining outcomes result in the call being
       redirected to an alternate URI which provides the desired service
       (i.e., play a pre-recorded announcement, or record a voice message).

    Gurbani, et al.             Standards Track                    [Page 27]

    RFC 3910                    SPIRITS Protocol                October 2004

       Further processing of a SPIRITS notifier when it receives a final
       response can be summarized by the following steps:

          1. If the response is a 4xx, 5xx, or 6xx class of response,
          generate and transmit an ACK request and instruct the SSP to play
          a busy tone to the caller.

          2. Else, for all 3xx responses, generate and transmit an ACK
          request, and compare the redirected URI to the subscriber's line
          number:

             2a.  If the comparison indicates a match, instruct the SSP to
             hold onto the call for just enough time to allow the SPIRITS
             subscriber to disconnect the modem, thus freeing up the line;
             and then continue with normal call processing, which will
             result in the subscriber's phone to ring.

             2b.  If the comparison fails, instruct the SSP to route the
             call to the redirected URI.

          3. Else, for a 2xx response, follow the steps in section 5.4.3.

    5.4.3.  Accepting an ICW session using VoIP

       One call handling option in ICW is to "accept an incoming call using
       VoIP".  The SPIRITS notifier has no way of knowing a-priori if the
       subscriber (callee) will be choosing this option; nonetheless, it has
       to account for such a choice by adding a SDP in the body of the
       INVITE request.  A possible way of accomplishing this is to have the
       SPIRITS notifier control a PSTN gateway and allocate appropriate
       resources on it.  Once this is done, the SPIRITS notifier adds
       network information (IP address of the gateway and port numbers where
       media will be received) and codec information as the SDP portion of
       the body in the INVITE request.  SPIRITS requires the DP information
       to be carried in the request body as well.  To that extent, the
       SPIRITS notifier MUST also add the information associated with the
       TDP that triggered the service.  Thus, the body of the INVITE MUST
       contain multi-part MIME, with two components.

       The SPIRITS notifier transmits the INVITE request to the subscriber
       and now waits for a final response.  Further processing when the
       SPIRITS subscriber returns a 200 OK MUST be handled as follows:

          On the receipt of a 200 OK containing the SDP of the subscriber's
          UA, the SPIRITS notifier will instruct the SSP to terminate the
          call on a pre-allocated port on the gateway.  This port MUST be
          correlated by the gateway to the SDP that was sent in the earlier
          INVITE.

    Gurbani, et al.             Standards Track                    [Page 28]

    RFC 3910                    SPIRITS Protocol                October 2004

       The end result is that the caller and callee hold a voice session
       with part of the session occurring over VoIP.

    6.  Non-call related events

       There are network events that are not related to setting up,
       maintaining, or tearing down voice calls.  Such events occur on the
       cellular wireless network and can be used by SPIRITS to provide
       services.  The SPIRITS protocol requirement explicitly includes the
       following events for which SPIRITS notification is needed
       (RFC3298:Section 5(b)):

       1. Location update in the same Visitor Location Register (VLR)
          service area

       2. Location update in another VLR service area

       3. International Mobile Subscriber Identity (IMSI) attach

       4. Mobile Subscriber (MS) initiated IMSI detach

       5. Network initiated IMSI detach

    6.1.  Non-call events and their required parameters

       Each of the five non-call related event is given a SPIRITS-specific
       mnemonic for use in subscriptions and notifications.

       Location update in the same VLR area
       SPIRITS mnemonic: LUSV
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID

       Cell-ID: A string used to identify the serving Cell-ID.  The actual
       length and representation of this parameter depend on the particulars
       of the cellular provider's network.

       Location update in different VLR area
       SPIRITS mnemonic: LUDV
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID

       IMSI attach
       SPIRITS mnemonic: REG
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID

    Gurbani, et al.             Standards Track                    [Page 29]

    RFC 3910                    SPIRITS Protocol                October 2004

       MS initiated IMSI detach
       SPIRITS mnemonic: UNREGMS
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameter in NOTIFY: CalledPartyNumber

       Network initiated IMSI detach
       SPIRITS mnemonic: UNREGNTWK
       Mandatory parameter in SUBSCRIBE: CalledPartyNumber
       Mandatory parameter in NOTIFY: CalledPartyNumber

    6.2.  Normative usage

       A subscriber will issue a SUBSCRIBE request which identifies a set of
       non-call related PSTN events it is interested in getting the
       notification of.  This set MAY contain exactly one event, or it MAY
       contain multiple events.  The SUBSCRIBE request is routed to the
       notifier where it is accepted, pending a successful authentication.

       When any of the events identified in the set occurs, the notifier
       will format a NOTIFY request and direct it towards the subscriber.
       The NOTIFY request will contain information pertinent to the one of
       the event whose notification was requested.

       The dialog established by the SUBSCRIBE persists until it expires
       normally, or is explicitly expired by the subscriber.  This behavior
       is different than the behavior for subscriptions associated with the
       "spirits-INDPs" package.  In the cellular network, the events
       subscribed for may occur at a far greater frequency than those
       compared to the wireline network (consider location updates as a
       cellular user moves around).  Thus it is far more expedient to allow
       the subscription to expire normally.

       When a subscriber receives a NOTIFY request, it can subsequently
       choose to act in a manner appropriate to the notification.

       The remaining sections fill in the specific package responsibilities
       raised in RFC3265 [3], Section 4.4.

    6.3.  Event package name

       This document defines two event packages; the first was defined in
       Section 5.3.  The second package, defined in this section is called
       "spirits-user-prof".  This package MUST be used for events
       corresponding to non-call related events in the cellular network.
       All entities that implement the SPIRITS protocol and support the
       non-call related events outlined in the SPIRITS protocol requirements

    Gurbani, et al.             Standards Track                    [Page 30]

    RFC 3910                    SPIRITS Protocol                October 2004

       (RFC3298:Section 5(b)) MUST set the "Event" header request header[3]
       to "spirits-user-prof."  The "Allow-Events" general header [3] MUST
       include the token "spirits-user-prof" as well.

       Example:

       Event: spirits-user-prof
       Allow-Events: spirits-user-prof, spirits-INDPs

    6.4.  Event package parameters

       The "spirits-user-prof" event package does not support any additional
       parameters to the Event header

    6.5.  SUBSCRIBE bodies

       SUBSCRIBE requests that serve to terminate the subscriptions MAY
       contain an empty body; however, SUBSCRIBE requests that establish a
       dialog MUST contain a body which encodes two pieces of information:

          (1) The set of events that is being subscribed to.  A subscriber
          MAY subscribe to multiple events in one SUBSCRIBE request, or MAY
          issue a different SUBSCRIBE request for each event it is
          interested in receiving a notification for.  The protocol allows
          for both forms of representation.  However, note that if one
          SUBSCRIBE is used to subscribe to multiple events, then an expiry
          for the dialog associated with that subscription affects all such
          events.

          (2) A list of values of the parameters associated with the event.
          Please see Section 6.1 for a list of parameters associated with
          each event.

       The default body type for SUBSCRIBEs in SPIRITS is denoted by the
       MIME type "application/spirits-event+xml".  The "Accept" header, if
       present, MUST include this MIME type.

    6.6.  Subscription duration

       The duration of a dialog established by a SUBSCRIBE request is
       limited to the expiration time negotiated between the subscriber and
       notifier when the dialog was established.  The subscriber MUST send a
       new SUBSCRIBE to refresh the dialog if it is interested in keeping it
       alive.  A dialog can be terminated by sending a new SUBSCRIBE request
       with an "Expires" header value of 0, as outlined in [3].

    Gurbani, et al.             Standards Track                    [Page 31]

    RFC 3910                    SPIRITS Protocol                October 2004

    6.7.  NOTIFY bodies

       Bodies in NOTIFY requests for the "spirits-user-prof" package are
       optional.  If present, they MUST be of the MIME type
       "application/spirits-event+xml".  The body in a NOTIFY request
       encapsulates the following pieces of information which can be used by
       the subscriber:

          (1) The event that resulted in the NOTIFY being generated
          (typically, but not always, this will be the same event present in
          the corresponding SUBSCRIBE request).

          (2) A list of values of the parameters associated with the event
          that the NOTIFY is being generated for.  Depending on the actual
          event, the list of the parameters will vary.

    6.8.  Notifier processing of SUBSCRIBE requests

       When the notifier receives a SUBSCRIBE request, it MUST authenticate
       the request and ensure that the subscriber is authorized to access
       the resource being subscribed to, in this case, non-call related
       cellular events for a mobile phone.

       Once the SUBSCRIBE request has been authenticated and authorized, the
       notifier interfaces with the SCF over interface D to set marks in the
       HLR corresponding to the mobile phone number contained in the
       SUBSCRIBE body.  The particulars of interface D are outside the scope
       of this document; here we simply assume that the notifier is able to
       set the appropriate marks in the HLR.

    6.9.  Notifier generation of NOTIFY requests

       If the notifier expects the setting of marks in the HLR to take more
       than 200 ms, it MUST send a 202 response to the SUBSCRIBE request
       immediately, accepting the subscription.  It should then send a
       NOTIFY request with an empty body.  This NOTIFY request MUST have a
       "Subscription-State" header with a value of "pending".

          This immediate NOTIFY with an empty body is needed since the
          resource identified in the SUBSCRIBE request does not have as yet
          a meaningful state.

       Once the notifier has successfully interfaced with the SCF, it MUST
       send a subsequent NOTIFY request with an empty body and a
       "Subscription-State" header with a value of "active."

    Gurbani, et al.             Standards Track                    [Page 32]

    RFC 3910                    SPIRITS Protocol                October 2004

       When the event of interest identified in the SUBSCRIBE request
       occurs, the notifier sends out a new NOTIFY request which MUST
       contain a body as described in Section 6.7.

    6.10.  Subscriber processing of NOTIFY requests

       The exact steps executed at the subscriber when it receives a NOTIFY
       request depend on the nature of the service that is being
       implemented.  As a generality, the UA associated with the subscriber
       should somehow impart this information to the user by visual or
       auditory means, if at all possible.

    6.11.  Handling of forked requests

       Forking of SUBSCRIBE requests is prohibited.  Since the SUBSCRIBE
       request is targeted towards the PSTN, highly irregular behaviors
       occur if the request is allowed to fork.  The normal SIP DNS lookup
       and routing rules [11] should result in a target set with exactly one
       element: the notifier.

    6.12.  Rate of notifications

       For reasons of congestion control, it is important that the rate of
       notifications not become excessive.  For instance, if a subscriber
       subscribes to the location update event for a notifier moving through
       the cellular network at a high enough velocity, it is entirely
       conceivable that the notifier may generate many NOTIFY requests in a
       small time frame.  Thus, within this package, the location update
       event needs an appropriate throttling mechanism.

       Whenever a SPIRITS notifier sends a location update NOTIFY, it MUST
       start a timer (Tn) with a value of 15 seconds.  If a subsequent
       location update NOTIFY request needs to be sent out before the timer
       has expired, it MUST be discarded.  Any future location update NOTIFY
       requests MUST be transmitted only if Tn has expired (i.e. 15 seconds
       have passed since the last NOTIFY request was send out).  If a
       location update NOTIFY is send out, Tn should be reset to go off
       again in 15 seconds.

    6.13.  State agents

       State agents are not used in SPIRITS.

    6.14.  Examples

       This section contains an example of a SPIRITS service that may be
       used to update the presence status of a mobile user.  The call flow
       is depicted in Figure 4 below.

    Gurbani, et al.             Standards Track                    [Page 33]

    RFC 3910                    SPIRITS Protocol                October 2004

          SPIRITS server       SPIRITS client      SCF
          ("subscriber")        ("notifier")
             S                      N
             |                      |                |
             | F1 SUBSCRIBE         |                |
             +--------------------->+                |
             |                      |                |
             |                      | F2 Set HLR mark|
             |     F3 200 OK (SUBS) +--------------->|
             |<---------------------|                |
             |                      |                |
             |            F4 NOTIFY |                |
             |<---------------------+                |
             |                      |                |
             |      F5 200 OK (NOT) |                |
             +--------------------->|                |
             |                      |                |
             ~                      ~                ~
             ~                      ~                ~
             |                      |  F6 Evt. Not.  |
             |                      |<---------------+
             |            F7 NOTIFY +                |
             |<---------------------|                |
             |                      |                |
             |      F8 200 OK (NOT) |                |
             +--------------------->|                |
             |                      |                |
             |                      |                |
            \|/                    \|/              \|/
             v                      v                v

                         Figure 4: Sample call flow

       In F1 of Figure 4, the subscriber indicates an interest in receiving
       a notification when a mobile user registers with the cellular
       network.  The cellular network notes this event (F2) and confirms the
       subscription (F3-F5).  When the mobile user turns on her cell phone
       and registers with the network, this event is detected (F6).  The
       cellular network then sends out a notification to the subscriber
       informing it of this event (F7-F8).

       We present the details of the call flow next.

       In F1, the subscriber subscribes to the registration event (REG) of a
       cellular phone number.

    Gurbani, et al.             Standards Track                    [Page 34]

    RFC 3910                    SPIRITS Protocol                October 2004

       F1: S->N
       SUBSCRIBE sip:myprovider.com SIP/2.0
       From: <sip:vkg@example.com>;tag=8177-afd-991
       To: <sip:16302240216@myprovider.com>
       CSeq: 18992 SUBSCRIBE
       Call-ID: 3329as77@host.example.com
       Contact: <sip:vkg@host.example.com>
       Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
       Expires: 3600
       Event: spirits-user-prof
       Allow-Events: spirits-INDPs, spirits-user-prof
       Accept: application/spirits-event+xml
       Content-Type: application/spirits-event+xml
       Content-Length: ...

       <?xml version="1.0" encoding="UTF-8"?>
       <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
          <Event type="userprof" name="REG">
                <CalledPartyNumber>6302240216</CalledPartyNumber>
          </Event>
       </spirits-event>

       The subscription reaches the notifier which authenticates the request
       (not shown) and interacts with the SCF to update the subscribers
       database for this event.  The notifier sends out a successful
       response to the subscription:

       F3: N->S
       SIP/2.0 200 OK
       From: <sip:vkg@example.com>;tag=8177-afd-991
       To: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
       CSeq: 18992 SUBSCRIBE
       Call-ID: 3329as77@host.example.com
       Contact: <sip:notifier.myprovider.com>
       Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
       Expires: 3600
       Allow-Events: spirits-INDPs, spirits-user-prof
       Accept: application/spirits-event+xml
       Content-Length: 0

       The notifier also sends out a NOTIFY request confirming the
       subscription:

       F4: N->S
       NOTIFY sip:vkg@host.example.com SIP/2.0
       To: <sip:vkg@example.com>;tag=8177-afd-991
       From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
       CSeq: 9121 NOTIFY

    Gurbani, et al.             Standards Track                    [Page 35]

    RFC 3910                    SPIRITS Protocol                October 2004

       Call-ID: 3329as77@host.example.com
       Contact: <sip:notifier.myprovider.com>
       Subscription-State: active
       Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
       Allow-Events: spirits-INDPs, spirits-user-prof
       Accept: application/spirits-event+xml
       Content-Length: 0

       The subscriber confirms the receipt of the NOTIFY request:

       F5: S->N
       SIP/2.0 200 OK
       To: <sip:vkg@example.com>;tag=8177-afd-991
       From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
       CSeq: 9121 NOTIFY
       Call-ID: 3329as77@host.example.com
       Contact: <sip:vkg@host.example.com>
       Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
       Content-Length: 0

       In F6, the mobile user identified by the PSTN number "6302240216"
       turns the mobile phone on, thus causing it to register with the
       cellular network.  The cellular network detects this event, and since
       a subscriber has indicated an interest in receiving a notification of
       this event, a SIP NOTIFY request is transmitted towards the
       subscriber:

       F7: N->S
       NOTIFY sip:vkg@host.example.com SIP/2.0
       To: <sip:vkg@example.com>;tag=8177-afd-991
       From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
       CSeq: 9122 NOTIFY
       Call-ID: 3329as77@host.example.com
       Contact: <sip:notifier.myprovider.com>
       Subscription-State: terminated;reason=fired
       Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
       Event: spirits-user-prof
       Allow-Events: spirits-INDPs, spirits-user-prof
       Accept: application/spirits-event+xml
       Content-Type: application/spirits-event+xml
       Content-Length: ...

    Gurbani, et al.             Standards Track                    [Page 36]

    RFC 3910                    SPIRITS Protocol                October 2004

       <?xml version="1.0" encoding="UTF-8"?>
       <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
          <Event type="userprof" name="REG">
                <CalledPartyNumber>6302240216</CalledPartyNumber>
                <Cell-ID>45987</Cell-ID>
          </Event>
       </spirits-event>

       The subscriber receives the notification and acknowledges it by
       sending a response:

       F8: S->N

       SIP/2.0 200 OK
       To: <sip:vkg@example.com>;tag=8177-afd-991
       From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
       CSeq: 9122 NOTIFY
       Call-ID: 3329as77@host.example.com
       Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
       Content-Length: 0

       Note that once the subscriber has received this notification, it can
       execute appropriate services.  In this particular instance, an
       appropriate service may consist of the subscriber acting as a
       composer of a presence service and turning the presence status of the
       user associated with the phone number "6302240216" to "on".  Also
       note in F7 that the notifier included a Cell ID in the notification.

       The Cell ID can be used as a basis for location specific services;
       however, a discussion of such services is out of the scope of this
       document.

    6.15.  Use of URIs to retrieve state

       The "spirits-user-prof" package MUST NOT use URIs to retrieve state.
       It is expected that most state information for this package is
       compact enough to fit in a SIP message.  However, to err on the side
       of caution, implementations MUST follow the convention outlined in
       Section 18.1.1 of [5] and use a congestion controlled transport if
       the size of the request is within 200 bytes of the path MTU if known,
       or if the request size is larger than 1300 bytes and the path MTU is
       unknown.

    Gurbani, et al.             Standards Track                    [Page 37]

    RFC 3910                    SPIRITS Protocol                October 2004

    7.  IANA Considerations

       This document calls for IANA to:

          o register two new SIP Event Packages per [3].

          o register a new MIME type per [20].

          o register a new namespace URN per [16].

          o register a new XML schema per [16].

    7.1.  Registering event packages

       Package Name: spirits-INDPs

       Type: package

       Contact: Vijay K. Gurbani, vkg@lucent.com

       Reference: RFC 3910

       Package Name: spirits-user-prof

       Type: package

       Contact: Vijay K. Gurbani, vkg@lucent.com

       Reference: RFC 3910

    7.2.  Registering MIME type

       MIME media type name: application

       MIME subtype name: spirits-event+xml

       Mandatory parameters: none

       Optional parameters: charset (same semantics of charset parameter in
       application/xml [9])

       Encoding considerations: same as considerations outlined for
       application/xml in [9].

       Security considerations: Section 10 of [9] and Section 8 of this
       document.

       Interoperability considerations: none.

    Gurbani, et al.             Standards Track                    [Page 38]

    RFC 3910                    SPIRITS Protocol                October 2004

       Published specifications: this document.

       Applications which use this media type: SPIRITS aware entities which
       adhere to this document.

       Additional information:

          Magic number(s): none.

          File extension(s): none.

          Macintosh file type code(s): none.

          Object Identifier(s) or OID(s): none.

       Person and email address for further information: Vijay K. Gurbani,
       <vkg@lucent.com>

       Intended usage: Common

       Author/Change controller: The IETF

    7.3.  Registering URN

       URI
          urn:ietf:params:xml:ns:spirits-1.0

       Description
       This is the XML namespace URI for XML elements defined by this
       document.  Such elements describe the SPIRITS information in the
       "application/ spirits-event+xml" content type.

       Registrant Contact
       IESG.

       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=utf-8"/>
             <title>Namespace for SPIRITS-related information</title>
           </head>
           <body>
             <h1>Namespace for SPIRITS-related information</h1>

    Gurbani, et al.             Standards Track                    [Page 39]

    RFC 3910                    SPIRITS Protocol                October 2004

             <h2>application/spirits-event+xml</h2>
             <p>See <a href="[[[URL of published RFC]]]">RFC3910</a>.</p>
           </body>
           </html>
         END

    7.4.  Registering XML schema

       URI
          urn:ietf:params:xml:schema:spirits-1.0

       Description
       XML base schema for SPIRITS entities.

       Registrant Contact
       IESG.

       XML
       Please see XML schema definition in Section 9 of this document.

    8.  Security Considerations

       This section focuses on security considerations which are unique to
       SPIRITS.  SIP security mechanisms are discussed in detail in the core
       SIP specification [5] and are outside the scope of this document.
       SPIRITS security mechanisms are based on and strengthen SIP security
       [5], for example, SPIRITS mandates the support of S/MIME.  Beyond
       that, any other security solutions specified in [5], i.e., TLS or
       HTTP Digest authentication, may be utilized by SPIRITS operators.

       As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the
       following security aspects are applicable to the SPIRITS protocol:

          Authentication

          Integrity

          Confidentiality

          Non-repudiation

       The SPIRITS architecture in Figure 1 contains 5 interfaces -- A, B,
       C, D, and E.  Of these, only two -- B and C -- are of interest to
       SPIRITS.  Interfaces A and E are PINT interfaces and are thus assumed
       secured by the PINT RFC [8].  Security for interface D is out of
       scope in this document since it deals primarily with the PSTN
       infrastructure.  We will discuss security aspects on interfaces B and
       C predicated on certain assumptions.

    Gurbani, et al.             Standards Track                    [Page 40]

    RFC 3910                    SPIRITS Protocol                October 2004

       A driving assumption for SPIRITS security is that the SPIRITS gateway
       is owned by the same PSTN operator that owns the SPIRITS notifier.
       Thus, it is attractive to simply relegate security of interface C to
       the PSTN operator, and in fact, there are merits to doing just that
       since interface C crosses the IP Network and PSTN boundaries.
       However, a closer inspection reveals that both interfaces B and C
       transmit the SPIRITS protocol; thus, any security arrangement we
       arrive at for interface B can be suitably applied to interface C as
       well.  This makes it possible to secure interface C in case the
       SPIRITS gateway is not owned by the same PSTN operator that owns the
       SPIRITS notifier.

       The ensuing security discussion assumes that the SPIRITS subscriber
       is communicating directly to the SPIRITS notifier (and vice-versa)
       and specifies a security apparatus for this arrangement.  However,
       the same apparatus can be used to secure the communication between a
       SPIRITS subscriber and an intermediary (like the SPIRITS gateway),
       and the same intermediary and the SPIRITS notifier.

       Confidentiality of the SPIRITS protocol is essential since the
       information carried in the protocol data units is of a sensitive
       nature and may lead to privacy concerns if revealed to non-authorized
       parties.  The communication path between the SPIRITS notifier and the
       SPIRITS subscriber should be secured through S/MIME [18] to alleviate
       privacy concerns, as is described in the Security Consideration
       section of the core SIP specification [5].

          S/MIME is an end-to-end security mechanism which encrypts the
          SPIRITS bodies for transit across an open network.  Intermediaries
          need not be cognizant of S/MIME in order to route the messages
          (routing headers travel in the clear).

       S/MIME provides all the security aspects for SPIRITS outlined at the
       beginning of this section: authentication, message integrity,
       confidentiality, and non-repudiation.  Authentication properties
       provided by S/MIME would allow the recipient of a SPIRITS message to
       ensure that the SPIRITS payload was generated by an authorized
       entity.  Encryption would ensure that only those SPIRITS entities
       possessing a particular decryption key are capable of inspecting
       encapsulated SPIRITS bodies in a SIP request.

       All SPIRITS endpoints MUST support S/MIME signatures (CMS SignedData)
       and MUST support encryption (CMS EnvelopedData).

       If the B and C interfaces are owned by the same PSTN operator, it is
       possible that public keys will be installed in the SPIRITS endpoints.

    Gurbani, et al.             Standards Track                    [Page 41]

    RFC 3910                    SPIRITS Protocol                October 2004

       S/MIME supports two methods -- issuerAndSerialNumber and
       subjectKeyIdentifier -- of naming the public key needed to validate a
       signature.  Between these, subjectKeyIdentifier works with X.509
       certificates and other schemes as well, while issuerAndSerialNumber
       works with X.509 certificates only.  If the administrator configures
       the necessary public keys, providing integrity through procedural
       means, then S/MIME can be used without X.509 certificates.

       All requests (and responses) between SPIRITS entities MUST be
       encrypted.

       When a request arrives at a SPIRITS notifier from a SPIRITS
       subscriber, the SPIRITS notifier MUST authenticate the request.  The
       subscription (or registration) from a SPIRITS subscriber MUST be
       rejected if the authentication fails.  If the SPIRITS subscriber
       successfully authenticated itself to the SPIRITS notifier, the
       SPIRITS notifier MUST, at the very least, ensure that the SPIRITS
       subscriber is indeed allowed to receive notifications of the events
       it is subscribing to.

          Note that this document does not proscribe how the SPIRITS
          notifier achieves this.  In practice, it could be through access
          control lists (ACL) that are populated by a service management
          system in the PSTN, or through a web interface of some sort.

       Requests from the SPIRITS notifier to the SPIRITS subscribers MUST
       also be authenticated, lest a malicious party attempts to
       fraudulently pose as a SPIRITS notifier to hijack a session.

    9.  XML schema definition

       The SPIRITS payload is specified in XML; this section defines the
       base XML schema for documents that make up the SPIRITS payload.  All
       SPIRITS entities that transport a payload characterized by the MIME
       type "application/spirits-event+xml" MUST support documents
       corresponding to the base schema below.

       Multiple versions of the base schema are not expected; rather, any
       additional functionality (e.g., conveying new PSTN events) must be
       accomplished through the definition of a new XML namespace and a
       corresponding schema.  Elements from the new XML namespace will then
       co-exist with elements from the base schema in a document.

    Gurbani, et al.             Standards Track                    [Page 42]

    RFC 3910                    SPIRITS Protocol                October 2004

    <xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"
           xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified"
           attributeFormDefault="unqualified">

         <!-- This import brings in the XML language attribute xml:lang-->
         <xs:import namespace="http://www.w3.org/XML/1998/namespace"
                    schemaLocation="http://www.w3.org/2001/xml.xsd"/>

         <xs:annotation>
            <xs:documentation xml:lang="en">
                  Describes SPIRITS events.
            </xs:documentation>
         </xs:annotation>

         <xs:element name="spirits-event" type="tns:SpiritsEventType"/>

         <xs:complexType name="SpiritsEventType">
            <xs:sequence>
               <xs:element name="Event" type="tns:EventType" minOccurs="1"
                   maxOccurs="unbounded"/>
               <xs:any namespace="##other" processContents="lax"
                   maxOccurs="unbounded"/>
            </xs:sequence>
         </xs:complexType>

         <xs:complexType name="EventType">
            <xs:sequence>
               <xs:element name="CalledPartyNumber" type="xs:token"
                   minOccurs="0" maxOccurs="1"/>
               <xs:element name="CallingPartyNumber" type="xs:token"
                   minOccurs="0" maxOccurs="1"/>
               <xs:element name="DialledDigits" type="xs:token"
                   minOccurs="0" maxOccurs="1"/>
               <xs:element name="Cell-ID" type="xs:token"
                   minOccurs="0" maxOccurs="1"/>
               <xs:element name="Cause" type="tns:CauseType"
                   minOccurs="0" maxOccurs="1"/>
            </xs:sequence>
            <xs:attribute name="type" type="tns:PayloadType"
                use="required"/>
            <xs:attribute name="name" type="tns:EventNameType"
                use="required"/>
            <xs:attribute name="mode" type="tns:ModeType"
                use="optional" default="N"/>
         </xs:complexType>

    Gurbani, et al.             Standards Track                    [Page 43]

    RFC 3910                    SPIRITS Protocol                October 2004

         <xs:simpleType name="PayloadType">
            <!-- The <spirits-event> will contain either a list of -->
            <!-- INDPs events or a list of userprof events -->
            <xs:restriction base="xs:string">
               <xs:enumeration value="INDPs"/>
               <xs:enumeration value="userprof"/>
            </xs:restriction>
         </xs:simpleType>

         <xs:simpleType name="EventNameType">
            <xs:restriction base="xs:string">
               <!-- These are the call related events (DPs).  If the -->
               <!-- PaylaodType is "INDPs", then the value of the "name" -->
               <!-- attribute is one of these; example -->
               <!-- <spirits-event type="INDPs" name="OCI"> -->
               <xs:enumeration value="OAA"/>
               <xs:enumeration value="OCI"/>
               <xs:enumeration value="OAI"/>
               <xs:enumeration value="OA"/>
               <xs:enumeration value="OTS"/>
               <xs:enumeration value="ONA"/>
               <xs:enumeration value="OCPB"/>
               <xs:enumeration value="ORSF"/>
               <xs:enumeration value="OMC"/>
               <xs:enumeration value="OAB"/>
               <xs:enumeration value="OD"/>
               <xs:enumeration value="TA"/>
               <xs:enumeration value="TMC"/>
               <xs:enumeration value="TAB"/>
               <xs:enumeration value="TD"/>
               <xs:enumeration value="TAA"/>
               <xs:enumeration value="TFSA"/>
               <xs:enumeration value="TB"/>
               <!-- These are the non-call related events.  If the -->
               <!-- PayloadType is "user-prof", then the value of the -->
               <!-- "name" attribute is one of these; example -->
               <!-- <spirits-event type="userprof" name="LUDV"> -->
               <xs:enumeration value="LUSV"/>
               <xs:enumeration value="LUDV"/>
               <xs:enumeration value="REG"/>
               <xs:enumeration value="UNREGMS"/>
               <xs:enumeration value="UNREGNTWK"/>
            </xs:restriction>
         </xs:simpleType>

         <xs:simpleType name="ModeType">
            <!-- One of two values: "N"otification or "R"equest -->
            <xs:restriction base="xs:string">

    Gurbani, et al.             Standards Track                    [Page 44]

    RFC 3910                    SPIRITS Protocol                October 2004

               <xs:enumeration value="N"/>
               <xs:enumeration value="R"/>
            </xs:restriction>
         </xs:simpleType>

         <xs:simpleType name="CauseType">
            <xs:restriction base="xs:string">
               <xs:enumeration value="Busy"/>
               <xs:enumeration value="Unreachable"/>
            </xs:restriction>
         </xs:simpleType>
    </xs:schema>

    10.  Acknowledgements

       The authors are grateful to participants in the SPIRITS WG for the
       discussion that contributed to this work.  These include J-L. Bakker,
       J. Bjorkner, J. Buller, J-E. Chapron, B. Chatras, O. Cleuziou,
       L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik,
       W. Montgomery, S. Nyckelgard, M. O'Doherty, A. Roach, J. Rosenberg,
       H. Sinnreich, L. Slutsman, D. Varney, and W. Zeuch.  The authors also
       acknowledge Steve Bellovin, Allison Mankin and Jon Peterson for help
       provided on the Security section.

    11.  Acronyms

       ACL                  Access Control List
       CS                   Capability Set
       DP                   Detection Point
       DTD                  Document Type Definition
       EDP                  Event Detection Point
       EDP-N                Event Detection Point "Notification"
       EDP-R                Event Detection Point "Request"
       IANA                 Internet Assigned Numbers Authority
       ICW                  Internet Call Waiting
       IMSI                 International Mobile Subscriber Identity
       IN                   Intelligent Network
       INAP                 Intelligent Network Application Protocol
       IP                   Internet Protocol
       ISP                  Internet Service Provider
       ITU                  International Telecommunications Union
       MIME                 Multipurpose Internet Mail Extensions
       MS                   Mobile Station (or Mobile Subscriber)
       OBCSM                Originating Basic Call State Model
       PIC                  Point In Call
       PINT                 PSTN/Internet Interworking
       PSTN                 Public Switched Telephone Network
       SCF                  Service Control Function

    Gurbani, et al.             Standards Track                    [Page 45]

    RFC 3910                    SPIRITS Protocol                October 2004

       SCP                  Service Control Point
       SDP                  Session Description Protocol
       SIP                  Session Initiation Protocol
       SIP-T                SIP for Telephones
       SPIRITS              Services in the PSTN/IN Requesting InTernet
                                Services
       SSF                  Service Switching Function
       SSP                  Service Switching Point
       STD                  State Transition Diagram
       TBCSM                Terminating Basic Call State Model
       TDP                  Trigger Detection Point
       TDP-N                Trigger Detection Point "Notification"
       TDP-R                Trigger Detection Point "Request"
       TLS                  Transport Layer Security
       UA                   User Agent
       VLR                  Visitor Location Register
       WIN                  Wireless Intelligent Network
       XML                  Extensible Markup Language

    12.  References

    12.1.  Normative References

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

       [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
            Levels", BCP 14, RFC 2119, March 1997.

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

       [4]  Faynberg, I., Gato, J., Lu, H., and L. Slutsman, "Service in the
            Public Switched Telephone Network/Intelligent Network (PSTN/IN)
            Requesting InTernet Service (SPIRITS) Protocol Requirements",
            RFC 3298, August 2002.

       [5]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
            Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
            Session Initiation Protocol", RFC 3261, June 2002.

    12.2. Informative References

       [6]  M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F.
            Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On
            selection of IN parameters to be carried by the SPIRITS
            Protocol", Work In Progress, January 2003.

    Gurbani, et al.             Standards Track                    [Page 46]

    RFC 3910                    SPIRITS Protocol                October 2004

       [7]  Intelligent Network Capability Set 2. ITU-T, Recommendation
            Q.1228.

       [8]  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.

       [9]  Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC
            3023, January 2001.

       [10] Lu, H., 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.

       [11] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
            (SIP): Locating SIP Servers", RFC 3263, June 2002.

       [12] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
            Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
            May 2001.  <http://www.w3c.org/XML/>.

       [13] "Interface recommendations for intelligent network capability
            set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June
            2000.

       [14] Moats, R., "URN Syntax", RFC 2141, May 1997.

       [15] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
            August 1999.

       [16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
            2004.

       [17] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in
            XML", W3C recommendation: xml-names, 14th January 1999,
            <http://www.w3.org/ TR/REC-xml-names>.

       [18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
            (S/MIME) Version 3.1 Message Specification", RFC 3851, July
            2004.

       [19] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The
            Intelligent Network Standards: Their Application to Services",
            McGraw-Hill, 1997.

    Gurbani, et al.             Standards Track                    [Page 47]

    RFC 3910                    SPIRITS Protocol                October 2004

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

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

            Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
            Three:  Message Header Extensions for Non-ASCII Text ", RFC
            2047, November 1996.

            Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
            Mail Extensions (MIME) Part Four: Registration Procedures", BCP
            13, RFC 2048, November 1996.

            Freed, N. and N. Borenstein, "Multipurpose Internet Mail
            Extensions (MIME) Part Five: Conformance Criteria and Examples",
            RFC 2049, November 1996.

    13.  Contributors

       Kumar Vemuri
       Lucent Technologies, Inc.
       2000 Naperville Rd.
       Naperville, IL 60566
       USA

       EMail: vvkumar@lucent.com

    14.  Authors' Addresses

       Vijay K. Gurbani, Editor
       2000 Lucent Lane
       Rm 6G-440
       Naperville, IL 60566
       USA

       EMail: vkg@lucent.com

       Alec Brusilovsky
       2601 Lucent Lane
       Lisle, IL 60532-3640
       USA

       EMail: abrusilovsky@lucent.com

    Gurbani, et al.             Standards Track                    [Page 48]

    RFC 3910                    SPIRITS Protocol                October 2004

       Igor Faynberg
       Lucent Technologies, Inc.
       101 Crawfords Corner Rd.
       Holmdel, NJ 07733
       USA

       EMail: faynberg@lucent.com

       Jorge Gato
       Vodafone Espana
       Isabel Colbrand, 22
       28050 Madrid
       Spain

       EMail: jorge.gato@vodafone.com

       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

       Musa Unmehopa
       Lucent Technologies, Inc.
       Larenseweg 50,
       Postbus 1168
       1200 BD, Hilversum,
       The Netherlands

       EMail: unmehopa@lucent.com

    Gurbani, et al.             Standards Track                    [Page 49]

    RFC 3910                    SPIRITS Protocol                October 2004

    15.  Full Copyright Statement

       Copyright (C) The Internet Society (2004).

       This document is subject to the rights, licenses and restrictions
       contained in BCP 78, and except as set forth therein, the authors
       retain all their rights.

       This document and the information contained herein are provided on an
       "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
       REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
       INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

    Intellectual Property

       The IETF takes no position regarding the validity or scope of any
       Intellectual Property Rights 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; nor does it represent that it has
       made any independent effort to identify any such rights.  Information
       on the IETF's procedures with respect to rights in IETF Documents can
       be found in BCP 78 and BCP 79.

       Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
       specification can be obtained from the IETF on-line IPR repository at
       http://www.ietf.org/ipr.

       The IETF invites any interested party to bring to its attention any
       copyrights, patents or patent applications, or other proprietary
       rights that may cover technology that may be required to implement
       this standard.  Please address the information to the IETF at ietf-
       ipr@ietf.org.

    Acknowledgement

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

    Gurbani, et al.             Standards Track                    [Page 50]