1. Introduction

   The ability to request asynchronous notification of events proves
   useful in many types of SIP services for which cooperation between
   end-nodes is required.  Examples of such services include automatic
   callback services (based on terminal state events), buddy lists
   (based on user presence events), message waiting indications (based
   on mailbox state change events), and PSTN and Internet
   Internetworking (PINT) [2] status (based on call state events).

   The methods described in this document provide a framework by which
   notification of these events can be ordered.

   The event notification mechanisms defined herein are NOT intended to
   be a general-purpose infrastructure for all classes of event
   subscription and notification.  Meeting requirements for the general
   problem set of subscription and notification is far too complex for a
   single protocol.  Our goal is to provide a SIP-specific framework for
   event notification which is not so complex as to be unusable for
   simple features, but which is still flexible enough to provide
   powerful services.  Note, however, that event packages based on this
   framework may define arbitrarily elaborate rules which govern the
   subscription and notification for the events or classes of events
   they describe.

   This document does not describe an extension which may be used
   directly; it must be extended by other documents (herein referred to
   as "event packages").  In object-oriented design terminology, it may

   be thought of as an abstract base class which must be derived into an
   instantiatable class by further extensions.  Guidelines for creating
   these extensions are described in section 4.

1.1. Overview of Operation

   The general concept is that entities in the network can subscribe to
   resource or call state for various resources or calls in the network,
   and those entities (or entities acting on their behalf) can send
   notifications when those states change.

   A typical flow of messages would be:

   Subscriber          Notifier
       |-----SUBSCRIBE---->|     Request state subscription
       |<-------200--------|     Acknowledge subscription
       |<------NOTIFY----- |     Return current state information
       |--------200------->|
       |<------NOTIFY----- |     Return current state information
       |--------200------->|

   Subscriptions are expired and must be refreshed by subsequent
   SUBSCRIBE messages.

1.2. Documentation Conventions

   There are several paragraphs throughout this document which provide
   motivational or clarifying text.  Such passages are non-normative,
   and are provided only to assist with reader comprehension.  These
   passages are set off from the remainder of the text by being indented
   thus:

      This is an example of non-normative explanatory text.  It does not
      form part of the specification, and is used only for
      clarification.

   Numbers in square brackets (e.g., [1]) denote a reference to one of
   the entries in the reference sections; see sections 8 and 9.

   The all-capital terms "MUST", "SHOULD", "MAY", "SHOULD NOT", "MUST
   NOT", and "RECOMMENDED" are used as defined in RFC 2119 [5].

   The use of quotation marks next to periods and commas follows the
   convention used by the American Mathematical Society; although
   contrary to traditional American English convention, this usage lends
   clarity to certain passages.