Internet Engineering Task Force SIPPING WG
Internet Draft J. Rosenberg
dynamicsoft
draft-ietf-sipping-reg-event-00.txt
October 28, 2002
Expires: April 2003
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. As
a result, these registrations 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 October 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 .......................... 9
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 .......................................... 15
6 Example Call Flow ................................... 17
7 Security Considerations ............................. 20
8 IANA Considerations ................................. 20
8.1 SIP Event Package Registration ...................... 20
8.2 application/reginfo+xml MIME Registration ........... 20
8.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:reginfo ................................. 21
9 Changes since draft-rosenberg-sip-reg-event-00.txt
................................................................ 22
10 Contributors ........................................ 22
11 Acknowledgements .................................... 23
12 Authors Addresses ................................... 23
13 Normative References ................................ 24
14 Informative References .............................. 24
J. Rosenberg [Page 2]
Internet Draft reg-event October 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 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 many SIP devices will be wireless devices that
J. Rosenberg [Page 3]
Internet Draft reg-event October 28, 2002
will be always-on, and therefore, continually registered to the
network. Unfortunately, history has shown that these devices can be
compromised. To deal with this, an administrator will want to
terminate or shorten 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 shortens 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. If it
cannot re-authenticate, the expiration will terminate shortly
thereafter.
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 state of 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
J. Rosenberg [Page 4]
Internet Draft reg-event October 28, 2002
server can subscribe to the registration state of the user. When the
user turns on their phone, the phone will generate a registration.
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
J. Rosenberg [Page 5]
Internet Draft reg-event October 28, 2002
requested. The default policy is:
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 then 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 an 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
J. Rosenberg [Page 6]
Internet Draft reg-event October 28, 2002
of the formats specified in the Accept header in the SUBSCRIBE
request.
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 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.
J. Rosenberg [Page 7]
Internet Draft reg-event October 28, 2002
+------------+
| |
| Init |
| |
+------------+
|
V
+------------+
| |
| Active |
| |
+------------+
|
V
+------------+
| |
| Terminated |
| |
+------------+
Figure 1: Registration State Machine
As long as there is at least one contact bound to the address-of-
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).
J. Rosenberg [Page 8]
Internet Draft reg-event October 28, 2002
+------+
| | refreshed
| | shortened
V |
+------------+ +------------+ +------------+
| | | | | |
| Init |----------->| Active |----------->| Terminated |
| | | | | |
+------------+ registered +------------+ expired +------------+
created deactivated
probation
unregistered
rejected
Figure 2: Contact State Machine
The FSM remains in the active state so long as the contact is bound
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. Likewise, when an administrator modifies the
expiration time of a binding (without deleting the binding) to
trigger the contact to re-register and possibly re-authenticate, the
FSM stays in the active state, but a shortened 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 still 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
sets the expiration time of that contact to zero.
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
J. Rosenberg [Page 9]
Internet Draft reg-event October 28, 2002
dependent. However, several guidelines are defined.
As a general rule, when a subscriber is authorized to receive
notifications about a 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 the contact information
for a particular address-of-record is resident. This implies that a
subscription for this information is readily handled by a single
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
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
J. Rosenberg [Page 10]
Internet Draft reg-event October 28, 2002
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 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
information on those registrations which have changed since
the previous document (partial).
Note that the document format explicitly allows for conveying
J. Rosenberg [Page 11]
Internet Draft reg-event October 28, 2002
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, shortened,
expired, deactivated, probation, unregistered and rejected.
If the event attribute has a value of shortened, the "expires"
attribute MUST be present. It contains an unsigned long integer which
indicates the number of seconds remaining until the binding is due to
J. Rosenberg [Page 12]
Internet Draft reg-event October 28, 2002
expire. This attribute MAY be included with any event attribute value
for which the state of the contact is active.
If the event attribute has a value of probation, the "retry-after"
attribute MUST be present. It contains an unsigned long integer 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
J. Rosenberg [Page 13]
Internet Draft reg-event October 28, 2002
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.
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:
sip:user@pc887.example.com
sip:user@university.edu
J. Rosenberg [Page 14]
Internet Draft reg-event October 28, 2002
5.4 XML Schema
The following is the schema definition of the reginfo format:
J. Rosenberg [Page 15]
Internet Draft reg-event October 28, 2002
J. Rosenberg [Page 16]
Internet Draft reg-event October 28, 2002
6 Example Call Flow
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
J. Rosenberg [Page 17]
Internet Draft reg-event October 28, 2002
Contact: sip:app.bar.com
Event: reg
Max-Forwards: 70
Accept: application/reginfo+xml
The registrar (which is acting as the notifier for the registration
event package) generates a 200 OK to the SUBSCRIBE:
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: ...
J. Rosenberg [Page 18]
Internet Draft reg-event October 28, 2002
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
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: ...
sip:joe@pc34.bar.com
The application can then send 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
J. Rosenberg [Page 19]
Internet Draft reg-event October 28, 2002
Max-Forwards: 70
Content-Type: text/plain
Content-Length: ...
Welcome to the bar.com service!
7 Security Considerations
Security considerations for SIP event packages are discussed in RFC
3265 [2], and those considerations apply here.
Registration information is sensitive, potentially private,
information. Subscriptions to this event package SHOULD be
authenticated and authorized according to local policy. Some policy
guidelines are suggested in Section 4.6. In addition, notifications
SHOULD be sent in such a way to ensure confidentiality, message
integrity and verification of subscriber identity, such as sending
subscriptions and notifications using a SIPS URL or protecting the
notification bodies with S/MIME.
8 IANA Considerations
This document registers a new SIP Event Package, a new MIME type
(application/reginfo+xml), and a new XML namespace.
8.1 SIP Event Package Registration
Package name: reg
Type: package
Contact: Jonathan Rosenberg,
Published Specification: RFC XXXX (Note to RFC Editor: Please
fill in XXXX with the RFC number of this specification).
8.2 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].
J. Rosenberg [Page 20]
Internet Draft reg-event October 28, 2002
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,
Intended usage: COMMON
Author/Change controller: The IETF.
8.3 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,
, Jonathan Rosenberg
.
XML:
BEGIN
J. Rosenberg [Page 21]
Internet Draft reg-event October 28, 2002
Registration Information Namespace
Namespace for Registration Information
application/reginfo+xml
See RFCXXXX.
END
9 Changes since draft-rosenberg-sip-reg-event-00.txt
o Added to the contact state machine a "shortened" event which
requests reregistration but keeps the binding state active.
o Added an "expires" parameter, to indicate the number of
seconds remaining for a binding.
o Updated the Security Considerations section.
o An IANA registration template was added for the "reg" package.
10 Contributors
This document 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
Mark Beckmann
Siemens AG
P.O. Box 100702
Salzgitter 38207
Germany
EMail: Mark.Beckmann@siemens.com
J. Rosenberg [Page 22]
Internet Draft reg-event October 28, 2002
Rohan Mahy provided editorial work in order to progress this
specification. His contact address is:
Rohan Mahy
Cisco Systems
170 West Tasman Dr, MS: SJC-21/3/3
Phone: +1 408 526 8570
Email: rohan@cisco.com
11 Acknowledgements
We would like to thank Dean Willis for his support.
12 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
J. Rosenberg [Page 23]
Internet Draft reg-event October 28, 2002
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13 Normative References
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[2] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002.
[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 IETF XML registry," Internet Draft, Internet
Engineering Task Force, July 2002. Work in progress.
[8] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC
3023, Internet Engineering Task Force, Jan. 2001.
14 Informative References
[9] J. Rosenberg, "Session initiation protocol (SIP) extensions for
presence," Internet Draft, Internet Engineering Task Force, May 2002.
Work in progress.
[10] B. Campbell and J. Rosenberg, "Session initiation protocol
extension for instant messaging," Internet Draft, Internet
Engineering Task Force, Sept. 2002. Work in progress.
J. Rosenberg [Page 24]
Internet Draft reg-event October 28, 2002
[11] H. Schulzrinne and J. Rosenberg, "Session initiation protocol
(SIP) caller preferences and callee capabilities," Internet Draft,
Internet Engineering Task Force, July 2002. Work in progress.
[12] G. Mayer and M. Beckmann, "Registration event package," Internet
Draft, Internet Engineering Task Force, May 2002. Work in progress.
J. Rosenberg [Page 25]