Internet Engineering Task Force                                   SIP WG
Internet Draft                                              J. Rosenberg
                                                             dynamicsoft
draft-rosenberg-sip-reg-00.txt
May 28, 2002
Expires: November 2002


  A Session Initiation Protocol (SIP) Event Package for Registrations

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   This document defines a Session Initiation Protocol (SIP) event
   package for registrations. Through its REGISTER method, SIP allows a
   user agent to create, modify, and delete registrations. Registrations
   can also be altered by administrators in order to enforce policy.
   These registrations therefore represent a piece of state in the
   network that can change dynamically. There are many cases where a
   user agent would like to be notified of changes in this state. This
   event package defines a mechanism by which those user agents can
   request and obtain such notifications.








J. Rosenberg                                                  [Page 1]


Internet Draft                 reg-event                    May 28, 2002






                           Table of Contents



   1          Introduction ........................................    3
   2          Terminology .........................................    3
   3          Usage Scenarios .....................................    3
   3.1        Forcing Re-Authentication ...........................    3
   3.2        Composing Presence ..................................    4
   3.3        Welcome Notices .....................................    4
   4          Package Definition ..................................    5
   4.1        Event Package Name ..................................    5
   4.2        Event Package Parameters ............................    5
   4.3        SUBSCRIBE Bodies ....................................    5
   4.4        Subscription Duration ...............................    6
   4.5        NOTIFY Bodies .......................................    6
   4.6        Notifier Processing of SUBSCRIBE Requests ...........    7
   4.7        Notifier Generation of NOTIFY Requests ..............    7
   4.7.1      The Registration State Machine ......................    7
   4.7.2      Applying the state machine ..........................   10
   4.8        Subscriber Processing of NOTIFY Requests ............   10
   4.9        Handling of Forked Requests .........................   10
   4.10       Rate of Notifications ...............................   10
   4.11       State Agents ........................................   11
   5          Registration Information ............................   11
   5.1        Structure of Registration Information ...............   11
   5.2        Computing Registrations from the Document ...........   13
   5.3        Example .............................................   14
   5.4        XML Schema ..........................................   14
   6          Example Call Flow ...................................   16
   7          Security Considerations .............................   19
   8          IANA Considerations .................................   20
   8.1        application/reginfo+xml MIME Registration ...........   20
   8.2        URN Sub-Namespace Registration for
   urn:ietf:params:xml:ns:reginfo .................................   21
   9          Contributors ........................................   21
   10         Acknowledgements ....................................   22
   11         Authors Addresses ...................................   22
   12         Normative References ................................   23
   13         Informative References ..............................   23








J. Rosenberg                                                  [Page 2]


Internet Draft                 reg-event                    May 28, 2002


1 Introduction

   The Session Initiation Protocol (SIP) [1] provides all of the
   functions needed for the establishment and maintenance of
   communications sessions between users. One of the functions it
   provides is a registration operation. A registration is a binding
   between a SIP URI, called an address-of-record, and one or more
   contact URIs. These contact URIs represent additional resources that
   can be contacted in order to reach the user identified by the
   address-of-record. When a proxy receives a request within its domain
   of administration, it uses the Request-URI as an address-of-record,
   and uses the contacts bound to the address-of-record to forward (or
   redirect) the request.

   The SIP REGISTER method provides a way for a user agent to manipulate
   registrations. Contacts can be added or removed, and the current set
   of contacts can be queried. Registrations can also change as a result
   of administrator policy. For example, if a user is suspected of
   fraud, their registration can be deleted so that they cannot receive
   any requests. Registrations also expire after some time if not
   refreshed.

   Registrations therefore represent a dynamic piece of state maintained
   by the network. There are many cases in which user agents would like
   to know about changes to the state of registrations. The SIP Events
   Framework [2] defines a generic framework for subscription to, and
   notification of, events related to SIP systems. The framework defines
   the methods SUBSCRIBE and NOTIFY, and introduces the notion of a
   package. A package is a concrete application of the event framework
   to a particular class of events. Packages have been defined for user
   presence [9], for example. This specification defines a package for
   registration state.

2 Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
   indicate requirement levels for compliant implementations.

3 Usage Scenarios

   There are many applications of this event package. A few are
   documented here for illustrative purposes.

3.1 Forcing Re-Authentication

   It is anticipated that future SIP devices will wireless devices that



J. Rosenberg                                                  [Page 3]


Internet Draft                 reg-event                    May 28, 2002


   will be always-on, and therefore, continually registered to the
   network. Unfortunately, history has shown that these devices can be
   compromised, and therefore, an administrator will want to terminate a
   registration and ask the device to re-register so it can be re-
   authenticated. To do this, the device subscribes to the registration
   event package for the address-of-record that it is registering
   contacts against. When the administrator terminates the registration
   (for example, when fraud is suspected) the registration server sends
   a notification to the device. It can then re-register and re-
   authenticate itself.

3.2 Composing Presence

   An important concept to understand is the relationship between this
   event package and the event package for user presence [9]. User
   presence represents the willingness and ability of a user to
   communicate with other users on the network. It is composed of a set
   of contact addresses that represent the various means for contacting
   the user. Those contact addresses might represent the contact address
   for voice, for example. Typically, the contact address listed for
   voice will be an address-of-record. The status of that contact
   (whether its open or closed) may depend on any number of factors,
   including the state of any registrations against that address-of-
   record. As a result, registration state can be viewed as an input to
   the process which determines the presence document for a user.
   Effectively, registration state is "raw" data, which is combined with
   other information about a user to generate a document that describes
   the user presence.

   In fact, this event package allows for a presence server to be
   separated from a SIP registration server, yet still use registration
   information to construct a presence document. When a presence server
   receives a presence subscription for some user, the presence server
   itself would generate a subscription to the registration server for
   the registration event package. As a result, the presence server
   would learn about the registration state for that user, and it could
   use that information to generate presence documents.

3.3 Welcome Notices

   A common service in current mobile networks are "welcome notices".
   When the user turns on their phone in a foreign country, they receive
   a message that welcomes them to the country, and provides information
   on transportation services, for example.

   In order to implement this service in a SIP system, an application
   server can subscribe to the registration state of the user. When the
   user turns on their phone, the phone will generate a registration.



J. Rosenberg                                                  [Page 4]


Internet Draft                 reg-event                    May 28, 2002


   This will result in a notification being sent to the application that
   the user has registered. The application can then send a SIP MESSAGE
   request [10] to the device, welcoming the user and providing any
   necessary information.

4 Package Definition

   This section fills in the details needed to specify an event package
   as defined in Section 5.4 of [2].

4.1 Event Package Name

   The SIP Events specification requires package definitions to specify
   the name of their package or template-package.

   The name of this package is "reg". As specified in [2], this value
   appears in the Event header present in SUBSCRIBE and NOTIFY requests.

   Example:


   Event: reg



4.2 Event Package Parameters

   The SIP Events specification requires package and template-package
   definitions to specify any package specific parameters of the Event
   header that are used by it.

   No package specific Event header parameters are defined for this
   event package.

4.3 SUBSCRIBE Bodies

   The SIP Events specification requires package or template-package
   definitions to define the usage, if any, of bodies in SUBSCRIBE
   requests.

   A SUBSCRIBE for registration events MAY contain a body. This body
   would serve the purpose of filtering the subscription. The definition
   of such a body is outside the scope of this specification.

   A SUBSCRIBE for the registration package MAY be sent without a body.
   This implies that the default registration filtering policy has been
   requested. The default policy is:




J. Rosenberg                                                  [Page 5]


Internet Draft                 reg-event                    May 28, 2002


        o Notifications are generated every time there is any change in
          the state of any of the registered contacts for the resource
          being subscribed to. Those notifications only contain
          information on the contacts whose state has changed.

        o Notifications triggered from a SUBSCRIBE contain full state
          (the list of all contacts bound to the address-of-record).

   Of course, the server can apply any policy it likes to the
   subscription.

4.4 Subscription Duration

   The SIP Events specification requires package definitions to define a
   default value for subscription durations, and to discuss reasonable
   choices for durations when they are explicitly specified.

   Registration state changes as contacts are created through REGISTER
   requests, and them time out due to lack of refresh. Their rate of
   change is therefore related to the typical registration expiration.
   Since the default expiration for registrations is 3600 seconds, the
   default duration of subscriptions to registration state is also 3600
   seconds. Of course, clients MAY include an Expires header in the
   SUBSCRIBE request asking for a different duration.

4.5 NOTIFY Bodies

   The SIP Events specification requires package definitions to describe
   the allowed set of body types in NOTIFY requests, and to specify the
   default value to be used when there is no Accept header in the
   SUBSCRIBE request.

   The body of a notification of a change in registration state contains
   a registration information document. This document describes some or
   all of the contacts associated with a particular address-of-record.
   All subscribers to registration state MUST support the
   application/reginfo+xml format described in Section 5, and MUST list
   its MIME type, application/reginfo+xml, in any Accept header present
   in the SUBSCRIBE request.

   Other registration information formats might be defined in the
   future. In that case, the subscriptions MAY indicate support for
   other formats. However, they MUST always support and list
   application/reginfo+xml as an allowed format.

   Of course, the notifications generated by the server MUST be in one
   of the formats specified in the Accept header in the SUBSCRIBE
   request. If no Accept header was present, the notifications MUST use



J. Rosenberg                                                  [Page 6]


Internet Draft                 reg-event                    May 28, 2002


   the application/reginfo+xml format described in Section 5.

4.6 Notifier Processing of SUBSCRIBE Requests

   The SIP Events framework specifies that packages should define any
   package-specific processing of SUBSCRIBE requests at a notifier,
   specifically with regards to authentication and authorization.

   Registration state can be sensitive information. Therefore, all
   subscriptions to it SHOULD be authenticated and authorized before
   approval. Authentication MAY be performed using any of the techniques
   available through SIP, including digest, S/MIME, TLS or other
   transport specific mechanisms [1]. Authorization policy is at the
   discretion of the administrator, as always. However, a few
   recommendations can be made.

   It is RECOMMENDED that a user A be allowed to subscribe to their own
   registration state. Such subscriptions are useful when there are many
   devices that represent a user, each of which needs to learn the
   registration state of the other devices. We also anticipate that
   applications and automata will frequently be subscribers to the
   registration state. In those cases, authorization policy will
   typically be provided ahead of time.

4.7 Notifier Generation of NOTIFY Requests

   The SIP Event framework requests that packages specify the conditions
   under which notifications are sent for that package, and how such
   notifications are constructed.

   To determine when a notifier should send notifications of changes in
   registration state, we define a finite state machine (FSM) that
   represents the state of a contact for a particular address-of-record.
   Transitions in this state machine MAY result in the generation of
   notifications. These notifications will carry information on the new
   state and the event which triggered the state change. It is important
   to note that this FSM is just a model of the registration state
   machinery maintained by a server. An implementation would map its own
   state machines to this one in an implementation-specific manner.

4.7.1 The Registration State Machine


   The underlying state machine for a registration is shown in Figure 1.
   The machine is very simple. An instance of this machine is associated
   with each address-of-record. When the first contact is registered to
   that address-of-record, the state machine moves from init to active.
   As long as there is at least one contact bound to the address-of-



J. Rosenberg                                                  [Page 7]


Internet Draft                 reg-event                    May 28, 2002





                           +------------+
                           |            |
                           |    Init    |
                           |            |
                           +------------+
                                  |
                                  V
                           +------------+
                           |            |
                           |   Active   |
                           |            |
                           +------------+
                                  |
                                  V
                           +------------+
                           |            |
                           | Terminated |
                           |            |
                           +------------+







   Figure 1: Registration State Machine


   record, the state machine remains in the active state. When the last
   contact expires or is removed, the registration transitions to
   terminated.


   In addition to this state machine, each registration is associated
   with a set of contacts, each of which is modelled with its own state
   machine. The diagram for the per-contact state machine is shown in
   Figure 2. This FSM is identical to the registration state machine in
   terms of its states, but has many more transition events.

   When a new contact is added, the FSM moves from the init state into
   the active state. There are two ways in which it can become active.
   One is through an actual SIP REGISTER request (correspoding to the
   registered event), and the other is when the contact is created
   administratively, or through some non-SIP means (the created event).
   The FSM remains in the active state so long as the contact is a bound



J. Rosenberg                                                  [Page 8]


Internet Draft                 reg-event                    May 28, 2002






                                 +------+
                                 |      | refreshed
                                 |      |
                                 V      |
    +------------+            +------------+            +------------+
    |            |            |            |            |            |
    |    Init    |----------->|   Active   |----------->| Terminated |
    |            |            |            |            |            |
    +------------+ registered +------------+ expired    +------------+
                   created                   deactivated
                                             probation
                                             unregistered
                                             rejected












   Figure 2: Contact State Machine


   to the address-of-record. When a contact is refreshed through a
   REGISTER request, the FSM stays in the same state, but a refreshed
   event is generated. When the contact is no longer bound to the
   address-of-record, the FSM moves to the terminated state. There are
   several reasons this can happen. The first is an expiration, which
   occurs when the contact was not refreshed by a REGISTER request. The
   second reason is deactivated. This occurs when the administrator has
   removed the contact as a valid binding, but wishes the client to
   attempt to re-register the contact. In contast, the rejected event
   occurs when an active contact is removed by the administrator, but
   re-registrations will not help to re-establish it. This might occur
   if a user does not pay their bills, for example. The probation event
   occurs when an active contact is removed by the administrator, and
   the administrator wants the client to re-register, but to do so at a
   later time. The unregistered event occurs when a REGISTER request is
   received which has set the expiration time of that contact to zero.




J. Rosenberg                                                  [Page 9]


Internet Draft                 reg-event                    May 28, 2002


4.7.2 Applying the state machine

   The server MAY generate a notification to subscribers when any event
   occurs in the state machine. Whether it does or does not is policy
   dependent. However, several guidelines are defined.

   As a general rule, when a subscriber is authorized to receive
   notifications about set of registrations, it is RECOMMENDED that
   notifications contain information about those contacts which have
   changed state (and thus triggered a notification), instead of
   delivering the current state of every contact in all registrations.
   However, notifications triggered as a result of a fetch operation (a
   SUBSCRIBE with Expires of 0) SHOULD result in the full state of all
   contacts for all registrations to be present in the NOTIFY.

4.8 Subscriber Processing of NOTIFY Requests

   The SIP Events framework expects packages to specify how a subscriber
   processes NOTIFY requests in any package specific ways, and in
   particular, how it uses the NOTIFY requests to contruct a coherent
   view of the state of the subscribed resource. Typically, the NOTIFY
   will only contain information for contacts whose state has changed.
   To construct a coherent view of the total state of all registrations,
   the subscriber will need to combine NOTIFYs received over time. The
   details of this process depend on the document format used to convey
   registration state. Section 5 outlines the process for the
   application/reginfo+xml format.

4.9 Handling of Forked Requests

   The SIP Events framework mandates that packages indicate whether or
   not forked SUBSCRIBE requests can install multiple subscriptions.

   Registration state is normally stored in some repository (whether it
   be co-located with a proxy/registrar or in a separate database). As
   such, there is usually a single place where a the contact information
   for a particular address-of-record is resident. This implies that a
   subscription for this information is readily handled by and element
   with access to this repository. There is, therefore, no compelling
   need for a subscription to registration information to fork. As a
   result, a subscriber MUSTNOT create multiple dialogs as a result of a
   single subscription request. The required processing to guarantee
   that only a single dialog is established is described in Section
   5.4.9 of the SIP Events framework [2].

4.10 Rate of Notifications

   The SIP Events framework mandates that packages define a maximum rate



J. Rosenberg                                                 [Page 10]


Internet Draft                 reg-event                    May 28, 2002


   of notifications for their package.

   For reasons of congestion control, it is important that the rate of
   notifications not become excessive. As a result, it is RECOMMENDED
   that the server not generate notifications for a single subscriber at
   a rate faster than once every 5 seconds.

4.11 State Agents

   The SIP Events framework asks packages to consider the role of state
   agents in their design.

   State agents have no role in the handling of this package.

5 Registration Information

5.1 Structure of Registration Information

   Registration information is an XML document [4] that MUST be well-
   formed and SHOULD be valid. Registration information documents MUST
   be based on XML 1.0 and MUST be encoded using UTF-8. This
   specification makes use of XML namespaces for identifying
   registration information documents and document fragments. The
   namespace URI for elements defined by this specification is a URN
   [5], using the namespace identifier 'ietf' defined by [6] and
   extended by [7]. This URN is:


   urn:ietf:params:xml:ns:reginfo



   A registration information document begins with the root element tag
   "reginfo". It consists of any number of "registration" sub-elements,
   each of which is contains the registration state for a particular
   address-of-record. Other elements from different namespaces MAY be
   present for the purposes of extensibility; elements or attributes
   from unknown namespaces MUST be ignored. There are two attributes
   associated with the "reginfo" element, both of which MUST be present:

        version: This attribute allows the recipient of registration
             information documents to properly order them. Versions
             start at 0, and increment by one for each new document sent
             to a subscriber. Versions are scoped within a subscription.
             Versions MUST be representable using a 32 bit integer.

        state: This attribute indicates whether the document contains
             the full registration state, or whether it contains only



J. Rosenberg                                                 [Page 11]


Internet Draft                 reg-event                    May 28, 2002


             information on those registrations which have changed since
             the previous document (partial).

   Note that the document format explicitly allows for conveying
   information on multiple addresses-of-record. This enables
   subscriptions to groups of registrations, where such a group is
   identified by some kind of URI. For example, a domain might define
   sip:allusers@example.com as a subscribable resource that generates
   notifications when the state of any address-of-record in the domain
   changes.

   The "reginfo" element has a list of "registration" sub-elements. The
   "registration" element contains information on a single registration.
   Other elements from different namespaces MAY be present for the
   purposes of extensibility; elements or attributes from unknown
   namespaces MUST be ignored. There are three attributes associated
   with the "registration" element, all of which MUST be present:

        aor: The aor attribute contains a URI which is the address-of-
             record this registration refers to.

        id: The id attribute identifies this registration. It MUST be
             unique amongst all other id attributes present in other
             registration elements conveyed to the subscriber within the
             scope of their subscription.

        state: The state attribute indicates the state of the
             registration. The valid values are "init", "active" and
             "terminated".

   The "registration" element has a list of "contact" sub-elements.
   Other elements from different namespaces MAY be present for the
   purposes of extensibility; elements or attributes from unknown
   namespaces MUST be ignored. There are several attributes associated
   with the "contact" element which MUST be present:

        id: The id attribute identifies this contact. It MUST be unique
             amongst all other id attributes present in other contact
             elements conveyed to the subscriber within the scope of
             their subscription.

        state: The state attribute indicates the state of the contact.
             The valid values are "active" and "terminated".

        event: The event attribute indicates the event which caused the
             contact state machine to go into its current state. Valid
             values are registered, created, refreshed, expired,
             deactivated, probation, unregistered and rejected.



J. Rosenberg                                                 [Page 12]


Internet Draft                 reg-event                    May 28, 2002


   If the event attribute has a value of probation, the "retry-after"
   attribute MUST be present. It contains an unsigned long which
   indicates the amount of seconds after which the owner of the contact
   is expected to retry its registration.

   The optional "duration-registered" attribute conveys the amount of
   time that the contact has been bound to the address-of-record, in
   seconds. The optional "q" attribute conveys the relative priority of
   this contact compared to other registered contacts. The optional
   "params" attribute conveys any contact parameters that have been
   associated with this contact. As an example, contact parameters can
   be specified through the caller preferences extension [11]. The
   optional "callid" attribute contains the current Call-ID carried in
   the REGISTER that was last used to update this contact, and the
   optional "cseq" attribute contains the last CSeq value present in a
   REGISTER request that updated this contact value. The optional
   "display-name" attribute contains the textual display name associated
   with this contact. The xml:lang attribute MAY be present to indicate
   the language of the display-name.

   The value of the contact element is the URI of that contact.

5.2 Computing Registrations from the Document

   Typically, the NOTIFY for registration information will only contain
   information about those contacts whose state has changed. To
   construct a coherent view of the total state of all registration, a
   subscriber will need to combine NOTIFYs received over time. The
   subscriber maintains a table for each registration it receives
   information for. Each registration is uniquely identified by the "id"
   attribute in the "registration" element. Each table contains a row
   for each contact in that registration. Each row is indexed by the
   unique ID for that contact. It is conveyed in the "id" attribute of
   the "contact" element. The contents of each row contain the state of
   that contact as conveyed in the "contact" element. The tables are
   also associated with a version number. The version number MUST be
   initialized with the value of the "version" attribute from the
   "reginfo" element in the first document received. Each time a new
   document is received, the value of the local version number, and the
   "version" attribute in the new document, are compared. If the value
   in the new document is one higher than the local version number, the
   local version number is increased by one, and the document is
   processed. If the value in the document is more than one higher than
   the local version number, the local version number is set to the
   value in the new document, the document is processed, and the
   subscriber SHOULD generate a refresh request to trigger a full state
   notification. If the value in the document is less than the local
   version, the document is discarded without processing.



J. Rosenberg                                                 [Page 13]


Internet Draft                 reg-event                    May 28, 2002


   The processing of the document depends on whether it contains full or
   partial state. If it contains full state, indicated by the value of
   the "state" attribute in the "reginfo" element, the contents of all
   tables associated with this subscription are flushed. They are
   repopulated from the document. A new table is created for each
   "registration" element, and a new row in each table is created for
   each "contact" element. If the reginfo contains partial state, as
   indicated by the value of the "state" attribute in the "reginfo"
   element, the document is used to update the existing tables. For each
   "registration" element, the subscriber checks to see if a table
   exists for that list. This check is done by comparing the value in
   the "id" attribute of the "registration" element with the ID
   associated with the table. If a table doesn't exist for that list,
   one is created. For each "contact" element in the list, the
   subscriber checks to see whether a row exists for that contact. This
   check is done by comparing the ID in the "id" attribute of the
   "contact" element with the ID associated with the row. If the contact
   doesn't exist in the table, a row is added, and its state is set to
   the information from that "contact" element. If the contact does
   exist, its state is updated to be the information from that "contact"
   element. If a row is updated or created, such that its state is now
   terminated, that entry MAY be removed from the table at any time.

5.3 Example

   The following is an example registration information document:


   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
                version="0" state="full">
     <registration aor="sip:user@example.com" id="as9"
                   state="active">
       <contact id="76" state="active" event="registered"
                duration-registered="7322"
                q="0.8">sip:user@pc887.example.com</contact>
       <contact id="77" state="terminated" event="expired"
                duration-registered="3600"
                q="0.5">sip:user@university.edu</contact>
     </registration>
   </reginfo>



5.4 XML Schema

   The following is the schema definition of the reginfo format:




J. Rosenberg                                                 [Page 14]


Internet Draft                 reg-event                    May 28, 2002


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              targetNamespace="urn:ietf:params:xml:ns:reginfo"
              xmlns:tns="urn:ietf:params:xml:ns:reginfo">

   <!-- 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/03/xml.xsd" />

   <xs:element name="reginfo">
      <xs:complexType>
        <xs:sequence>
          <xs:element ref="tns:registration" minOccurs="0"
                       maxOccurs="unbounded"/>
           <xs:any namespace="##other" processContents="lax" minOccurs="0"
                   maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="version" type="xs:nonNegativeInteger"
                       use="required"/>
         <xs:attribute name="state" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:string">
               <xs:enumeration value="full"/>
               <xs:enumeration value="partial"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
     </xs:complexType>
     </xs:element>
     <xs:element name="registration">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="tns:contact" minOccurs="0"
                       maxOccurs="unbounded"/>
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="aor" type="xs:anyURI" use="required"/>
         <xs:attribute name="id" type="xs:string" use="required"/>
         <xs:attribute name="state" use="required">
               <xs:simpleType>
                 <xs:restriction base="xs:string">
                   <xs:enumeration value="init"/>
                   <xs:enumeration value="active"/>
                   <xs:enumeration value="terminated"/>
                 </xs:restriction>
               </xs:simpleType>



J. Rosenberg                                                 [Page 15]


Internet Draft                 reg-event                    May 28, 2002


         </xs:attribute>
       </xs:complexType>
     </xs:element>
     <xs:element name="contact">
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base="xs:anyURI">
             <xs:attribute name="display-name" type="xs:string"/>
             <xs:attribute name="state" use="required">
               <xs:simpleType>
                 <xs:restriction base="xs:string">
                   <xs:enumeration value="active"/>
                   <xs:enumeration value="terminated"/>
                 </xs:restriction>
               </xs:simpleType>
             </xs:attribute>
             <xs:attribute name="event" use="required">
               <xs:simpleType>
                 <xs:restriction base="xs:string">
                   <xs:enumeration value="registered"/>
                   <xs:enumeration value="created"/>
                   <xs:enumeration value="refreshed"/>
                   <xs:enumeration value="expired"/>
                   <xs:enumeration value="deactivated"/>
                   <xs:enumeration value="probation"/>
                   <xs:enumeration value="unregistered"/>
                   <xs:enumeration value="rejected"/>
                 </xs:restriction>
               </xs:simpleType>
             </xs:attribute>
             <xs:attribute name="duration-registered"
                           type="xs:unsignedLong"/>
             <xs:attribute name="retry-after" type="xs:unsignedLong"/>
             <xs:attribute name="id" type="xs:string" use="required"/>
             <xs:attribute name="q" type="xs:string"/>
             <xs:attribute name="params" type="xs:string" />
             <xs:attribute name="callid" type="xs:string" />
             <xs:attribute name="cseq" type="xs:unsignedLong" />
             <xs:attribute ref="xml:lang"/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>
   </xs:schema>



6 Example Call Flow



J. Rosenberg                                                 [Page 16]


Internet Draft                 reg-event                    May 28, 2002




        User              Registrar          Application
          |                   |(1) SUBSCRIBE      |
          |                   |Event:reg          |
          |                   |<------------------|
          |                   |(2) 200 OK         |
          |                   |------------------>|
          |                   |(3) NOTIFY         |
          |                   |------------------>|
          |                   |(4) 200 OK         |
          |                   |<------------------|
          |(5) REGISTER       |                   |
          |------------------>|                   |
          |(6) 200 OK         |                   |
          |<------------------|                   |
          |                   |(7) NOTIFY         |
          |                   |------------------>|
          |                   |(8) 200 OK         |
          |                   |<------------------|
          |(9) MESSAGE        |                   |
          |<--------------------------------------|



   Figure 3: Example Call Flow



   This section provides an example call flow, shown in Figure 3. It
   shows an implementation of the welcome notice application described
   in Section 3.3. First, the application SUBSCRIBEs to the registration
   event package for the desired user (1):


   SUBSCRIBE sip:joe@bar.com SIP/2.0
   Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds7
   From: sip:app.bar.com;tag=123aa9
   To: sip:joe@bar.com
   Call-ID: 9987@app.bar.com
   CSeq: 9887 SUBSCRIBE
   Contact: sip:app.bar.com
   Event: reg
   Max-Forwards: 70



   The registrar (which is acting as the notifier for the registration
   event package) generates a 200 OK to the SUBSCRIBE:



J. Rosenberg                                                 [Page 17]


Internet Draft                 reg-event                    May 28, 2002


   SIP/2.0 200 OK
   Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds7
     ;received=1.2.3.4
   From: sip:app.bar.com;tag=123aa9
   To: sip:joe@bar.com;tag=xyzygg
   Call-ID: 9987@app.bar.com
   CSeq: 9987 SUBSCRIBE
   Contact: sip:server19.bar.com
   Expires: 3600



   The registrar then generates a notification (3) with the current
   state. Since there is no active registration, the state of the
   registration is "init":


   NOTIFY sip:app.bar.com SIP/2.0
   Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaii
   From: sip:joe@bar.com;tag=xyzygg
   To: sip:app.bar.com;tag=123aa9
   Call-ID: 9987@app.bar.com
   CSeq: 1288 NOTIFY
   Contact: sip:server19.bar.com
   Event: reg
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
                version="0" state="full">
     <registration aor="sip:joe@bar.com" id="a7" state="init" />
   </reginfo>



   Later on, the user registers (5):


   REGISTER sip:joe@bar.com SIP/2.0
   Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnaaff
   From: sip:joe@bar.com;tag=99a8s
   To: sip:joe@bar.com
   Call-ID: 88askjda9@pc34.bar.com
   CSeq: 9976 REGISTER
   Contact: sip:joe@pc34.bar.com




J. Rosenberg                                                 [Page 18]


Internet Draft                 reg-event                    May 28, 2002


   This results in a NOTIFY being generated to the application (7):


   NOTIFY sip:app.bar.com SIP/2.0
   Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaij
   From: sip:joe@bar.com;tag=xyzygg
   To: sip:app.bar.com;tag=123aa9
   Call-ID: 9987@app.bar.com
   CSeq: 1289 NOTIFY
   Contact: sip:server19.bar.com
   Event: reg
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
                version="1" state="partial">
     <registration aor="sip:joe@bar.com" id="a7" state="active">
       <contact id="76" state="active" event="registered"
                duration-registered="0">sip:joe@pc34.bar.com</contact>
     </registration>
   </reginfo>



   The application can then sends its instant message to the device (9):


   MESSAGE sip:joe@pc34.bar.com SIP/2.0
   Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds8
   From: sip:app.bar.com;tag=123aa10
   To: sip:joe@bar.com
   Call-ID: 9988@app.bar.com
   CSeq: 82779 MESSAGE
   Max-Forwards: 70
   Content-Type: text/plain
   Content-Length: ...

   Welcome to the bar.com service!



7 Security Considerations

   Registration information is sensitive information. The protocol used
   to distribute it SHOULD ensure privacy, message integrity and
   authentication. Furthermore, the protcol should provide access



J. Rosenberg                                                 [Page 19]


Internet Draft                 reg-event                    May 28, 2002


   controls which restrict who can see the registration information for
   a user.

8 IANA Considerations

   This document registers a new MIME type, application/reginfo+xml, and
   registers a new XML namespace.

8.1 application/reginfo+xml MIME Registration

        MIME media type name: application

        MIME subtype name: reginfo+xml

        Mandatory parameters: none

        Optional parameters: Same as charset parameter application/xml
             as specified in RFC 3023 [8].

        Encoding considerations: Same as encoding considerations of
             application/xml as specified in RFC 3023 [8].

        Security considerations: See Section 10 of RFC 3023 [8] and
             Section 7 of this specification.

        Interoperability considerations: none.

        Published specification: This document.

        Applications which use this media type: This document type is
             being used in notifications to alert SIP user agents that
             their registrations have expired and must be redone.

        Additional Information:

             Magic Number: None

             File Extension: .rif or .xml

             Macintosh file type code: "TEXT"

        Personal and email address for further information: Jonathan
             Rosenberg, <jdrosen@jdrosen.net>

        Intended usage: COMMON

        Author/Change controller: The IETF.




J. Rosenberg                                                 [Page 20]


Internet Draft                 reg-event                    May 28, 2002


8.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:reginfo

   This section registers a new XML namespace, as per the guidelines in
   [7].

        URI: The URI for this namespace is
             urn:ietf:params:xml:ns:reginfo.

        Registrant Contact: IETF, SIMPLE working group,
             <simple@mailman.dynamicsoft.com>, Jonathan Rosenberg
             <jdrosen@jdrosen.net>.

        XML:

             BEGIN
             <?xml version="1.0"?>
             <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                       "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
             <html xmlns="http://www.w3.org/1999/xhtml">
             <head>
               <meta http-equiv="content-type"
                  content="text/html;charset=iso-8859-1"/>
               <title>Registration Information Namespace</title>
             </head>
             <body>
               <h1>Namespace for Registration Information</h1>
               <h2>application/reginfo+xml</h2>
               <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
             </body>
             </html>
             END



9 Contributors

   This draft is based heavily on the registration event package
   originally proposed by Beckmann and Mayer in [12]. They can be
   contacted at:


   Georg Mayer
   Siemens AG
   Hoffmannstr. 51
   Munich  81359
   Germany
   EMail: Georg.Mayer@icn.siemens.de




J. Rosenberg                                                 [Page 21]


Internet Draft                 reg-event                    May 28, 2002


   Mark Beckmann
   Siemens AG
   P.O. Box 100702
   Salzgitter  38207
   Germany
   EMail: Mark.Beckmann@siemens.com



10 Acknowledgements

   We would like to thank Dean Willis for his support.

11 Authors Addresses


   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com




   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an



J. Rosenberg                                                 [Page 22]


Internet Draft                 reg-event                    May 28, 2002


   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

12 Normative References

   [1] J. Rosenberg, H. Schulzrinne, et al.  , "SIP: Session initiation
   protocol," Internet Draft, Internet Engineering Task Force, Feb.
   2002.  Work in progress.

   [2] A. Roach, "SIP-specific event notification," Internet Draft,
   Internet Engineering Task Force, Mar. 2002.  Work in progress.

   [3] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.

   [4] W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The
   XML 1.0 spec can be found at http://www.w3.org/TR/1998/REC-xml-
   19980210.

   [5] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task
   Force, May 1997.

   [6] R. Moats, "A URN namespace for IETF documents," RFC 2648,
   Internet Engineering Task Force, Aug. 1999.

   [7] M. Mealling, "The IANA XML registry," Internet Draft, Internet
   Engineering Task Force, Nov. 2001.  Work in progress.

   [8] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC
   3023, Internet Engineering Task Force, Jan. 2001.

13 Informative References

   [9] J. Rosenberg et al.  , "Session initiation protocol (SIP)
   extensions for presence," Internet Draft, Internet Engineering Task
   Force, Apr. 2002.  Work in progress.

   [10] B. Campbell and J. Rosenberg, "Session initiation protocol
   extension for instant messaging," Internet Draft, Internet
   Engineering Task Force, May 2002.  Work in progress.

   [11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
   callee capabilities," Internet Draft, Internet Engineering Task
   Force, Nov. 2001.  Work in progress.




J. Rosenberg                                                 [Page 23]


Internet Draft                 reg-event                    May 28, 2002


   [12] G. Mayer and M. Beckmann, "Registration event package," Internet
   Draft, Internet Engineering Task Force, May 2002.  Work in progress.

















































J. Rosenberg                                                 [Page 24]