The "spirits-user-prof" event package does not support any additional
parameters to the Event header
6.5. SUBSCRIBE bodies
SUBSCRIBE requests that serve to terminate the subscriptions MAY
contain an empty body; however, SUBSCRIBE requests that establish a
dialog MUST contain a body which encodes two pieces of information:
(1) The set of events that is being subscribed to. A subscriber
MAY subscribe to multiple events in one SUBSCRIBE request, or MAY
issue a different SUBSCRIBE request for each event it is
interested in receiving a notification for. The protocol allows
for both forms of representation. However, note that if one
SUBSCRIBE is used to subscribe to multiple events, then an expiry
for the dialog associated with that subscription affects all such
events.
(2) A list of values of the parameters associated with the event.
Please see Section 6.1 for a list of parameters associated with
each event.
The default body type for SUBSCRIBEs in SPIRITS is denoted by the
MIME type "application/spirits-event+xml". The "Accept" header, if
present, MUST include this MIME type.
6.6. Subscription duration
The duration of a dialog established by a SUBSCRIBE request is
limited to the expiration time negotiated between the subscriber and
notifier when the dialog was established. The subscriber MUST send a
new SUBSCRIBE to refresh the dialog if it is interested in keeping it
alive. A dialog can be terminated by sending a new SUBSCRIBE request
with an "Expires" header value of 0, as outlined in [3].
6.7. NOTIFY bodies
Bodies in NOTIFY requests for the "spirits-user-prof" package are
optional. If present, they MUST be of the MIME type
"application/spirits-event+xml". The body in a NOTIFY request
encapsulates the following pieces of information which can be used by
the subscriber:
(1) The event that resulted in the NOTIFY being generated
(typically, but not always, this will be the same event present in
the corresponding SUBSCRIBE request).
(2) A list of values of the parameters associated with the event
that the NOTIFY is being generated for. Depending on the actual
event, the list of the parameters will vary.
6.8. Notifier processing of SUBSCRIBE requests
When the notifier receives a SUBSCRIBE request, it MUST authenticate
the request and ensure that the subscriber is authorized to access
the resource being subscribed to, in this case, non-call related
cellular events for a mobile phone.
Once the SUBSCRIBE request has been authenticated and authorized, the
notifier interfaces with the SCF over interface D to set marks in the
HLR corresponding to the mobile phone number contained in the
SUBSCRIBE body. The particulars of interface D are outside the scope
of this document; here we simply assume that the notifier is able to
set the appropriate marks in the HLR.
6.9. Notifier generation of NOTIFY requests
If the notifier expects the setting of marks in the HLR to take more
than 200 ms, it MUST send a 202 response to the SUBSCRIBE request
immediately, accepting the subscription. It should then send a
NOTIFY request with an empty body. This NOTIFY request MUST have a
"Subscription-State" header with a value of "pending".
This immediate NOTIFY with an empty body is needed since the
resource identified in the SUBSCRIBE request does not have as yet
a meaningful state.
Once the notifier has successfully interfaced with the SCF, it MUST
send a subsequent NOTIFY request with an empty body and a
"Subscription-State" header with a value of "active."
When the event of interest identified in the SUBSCRIBE request
occurs, the notifier sends out a new NOTIFY request which MUST
contain a body as described in Section 6.7.
6.10. Subscriber processing of NOTIFY requests
The exact steps executed at the subscriber when it receives a NOTIFY
request depend on the nature of the service that is being
implemented. As a generality, the UA associated with the subscriber
should somehow impart this information to the user by visual or
auditory means, if at all possible.
6.11. Handling of forked requests
Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE
request is targeted towards the PSTN, highly irregular behaviors
occur if the request is allowed to fork. The normal SIP DNS lookup
and routing rules [11] should result in a target set with exactly one
element: the notifier.
6.12. Rate of notifications
For reasons of congestion control, it is important that the rate of
notifications not become excessive. For instance, if a subscriber
subscribes to the location update event for a notifier moving through
the cellular network at a high enough velocity, it is entirely
conceivable that the notifier may generate many NOTIFY requests in a
small time frame. Thus, within this package, the location update
event needs an appropriate throttling mechanism.
Whenever a SPIRITS notifier sends a location update NOTIFY, it MUST
start a timer (Tn) with a value of 15 seconds. If a subsequent
location update NOTIFY request needs to be sent out before the timer
has expired, it MUST be discarded. Any future location update NOTIFY
requests MUST be transmitted only if Tn has expired (i.e. 15 seconds
have passed since the last NOTIFY request was send out). If a
location update NOTIFY is send out, Tn should be reset to go off
again in 15 seconds.
6.13. State agents
State agents are not used in SPIRITS.
6.14. Examples
This section contains an example of a SPIRITS service that may be
used to update the presence status of a mobile user. The call flow
is depicted in Figure 4 below.
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Set HLR mark|
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
Figure 4: Sample call flow
In F1 of Figure 4, the subscriber indicates an interest in receiving
a notification when a mobile user registers with the cellular
network. The cellular network notes this event (F2) and confirms the
subscription (F3-F5). When the mobile user turns on her cell phone
and registers with the network, this event is detected (F6). The
cellular network then sends out a notification to the subscriber
informing it of this event (F7-F8).
We present the details of the call flow next.
In F1, the subscriber subscribes to the registration event (REG) of a
cellular phone number.
F1: S->N
SUBSCRIBE sip:myprovider.com SIP/2.0
From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
Expires: 3600
Event: spirits-user-prof
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
The subscription reaches the notifier which authenticates the request
(not shown) and interacts with the SCF to update the subscribers
database for this event. The notifier sends out a successful
response to the subscription:
F3: N->S
SIP/2.0 200 OK
From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
Expires: 3600
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Length: 0
The notifier also sends out a NOTIFY request confirming the
subscription:
F4: N->S
NOTIFY sip:vkg@host.example.com SIP/2.0
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9121 NOTIFY
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Length: 0
The subscriber confirms the receipt of the NOTIFY request:
F5: S->N
SIP/2.0 200 OK
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9121 NOTIFY
Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com>
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
Content-Length: 0
In F6, the mobile user identified by the PSTN number "6302240216"
turns the mobile phone on, thus causing it to register with the
cellular network. The cellular network detects this event, and since
a subscriber has indicated an interest in receiving a notification of
this event, a SIP NOTIFY request is transmitted towards the
subscriber:
F7: N->S
NOTIFY sip:vkg@host.example.com SIP/2.0
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9122 NOTIFY
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: terminated;reason=fired
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
Event: spirits-user-prof
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<Cell-ID>45987</Cell-ID>
</Event>
</spirits-event>
The subscriber receives the notification and acknowledges it by
sending a response:
F8: S->N
SIP/2.0 200 OK
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9122 NOTIFY
Call-ID: 3329as77@host.example.com
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
Content-Length: 0
Note that once the subscriber has received this notification, it can
execute appropriate services. In this particular instance, an
appropriate service may consist of the subscriber acting as a
composer of a presence service and turning the presence status of the
user associated with the phone number "6302240216" to "on". Also
note in F7 that the notifier included a Cell ID in the notification.
The Cell ID can be used as a basis for location specific services;
however, a discussion of such services is out of the scope of this
document.
6.15. Use of URIs to retrieve state
The "spirits-user-prof" package MUST NOT use URIs to retrieve state.
It is expected that most state information for this package is
compact enough to fit in a SIP message. However, to err on the side
of caution, implementations MUST follow the convention outlined in
Section 18.1.1 of [5] and use a congestion controlled transport if
the size of the request is within 200 bytes of the path MTU if known,
or if the request size is larger than 1300 bytes and the path MTU is
unknown.
7. IANA Considerations
This document calls for IANA to:
o register two new SIP Event Packages per [3].
o register a new MIME type per [20].
o register a new namespace URN per [16].
o register a new XML schema per [16].
7.1. Registering event packages
Package Name: spirits-INDPs
Type: package
Contact: Vijay K. Gurbani, vkg@lucent.com
Reference: RFC 3910
Package Name: spirits-user-prof
Type: package
Contact: Vijay K. Gurbani, vkg@lucent.com
Reference: RFC 3910
7.2. Registering MIME type
MIME media type name: application
MIME subtype name: spirits-event+xml
Mandatory parameters: none
Optional parameters: charset (same semantics of charset parameter in
application/xml [9])
Encoding considerations: same as considerations outlined for
application/xml in [9].
Security considerations: Section 10 of [9] and Section 8 of this
document.
Interoperability considerations: none.
Published specifications: this document.
Applications which use this media type: SPIRITS aware entities which
adhere to this document.
Additional information:
Magic number(s): none.
File extension(s): none.
Macintosh file type code(s): none.
Object Identifier(s) or OID(s): none.
Person and email address for further information: Vijay K. Gurbani,
<vkg@lucent.com>
Intended usage: Common
Author/Change controller: The IETF
7.3. Registering URN
URI
urn:ietf:params:xml:ns:spirits-1.0
Description
This is the XML namespace URI for XML elements defined by this
document. Such elements describe the SPIRITS information in the
"application/ spirits-event+xml" content type.
Registrant Contact
IESG.
XML
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=utf-8"/>
<title>Namespace for SPIRITS-related information</title>
</head>
<body>
<h1>Namespace for SPIRITS-related information</h1>
<h2>application/spirits-event+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFC3910</a>.</p>
</body>
</html>
END
7.4. Registering XML schema
URI
urn:ietf:params:xml:schema:spirits-1.0
Description
XML base schema for SPIRITS entities.
Registrant Contact
IESG.
XML
Please see XML schema definition in Section 9 of this document.
8. Security Considerations
This section focuses on security considerations which are unique to
SPIRITS. SIP security mechanisms are discussed in detail in the core
SIP specification [5] and are outside the scope of this document.
SPIRITS security mechanisms are based on and strengthen SIP security
[5], for example, SPIRITS mandates the support of S/MIME. Beyond
that, any other security solutions specified in [5], i.e., TLS or
HTTP Digest authentication, may be utilized by SPIRITS operators.
As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the
following security aspects are applicable to the SPIRITS protocol:
Authentication
Integrity
Confidentiality
Non-repudiation
The SPIRITS architecture in Figure 1 contains 5 interfaces -- A, B,
C, D, and E. Of these, only two -- B and C -- are of interest to
SPIRITS. Interfaces A and E are PINT interfaces and are thus assumed
secured by the PINT RFC [8]. Security for interface D is out of
scope in this document since it deals primarily with the PSTN
infrastructure. We will discuss security aspects on interfaces B and
C predicated on certain assumptions.
A driving assumption for SPIRITS security is that the SPIRITS gateway
is owned by the same PSTN operator that owns the SPIRITS notifier.
Thus, it is attractive to simply relegate security of interface C to
the PSTN operator, and in fact, there are merits to doing just that
since interface C crosses the IP Network and PSTN boundaries.
However, a closer inspection reveals that both interfaces B and C
transmit the SPIRITS protocol; thus, any security arrangement we
arrive at for interface B can be suitably applied to interface C as
well. This makes it possible to secure interface C in case the
SPIRITS gateway is not owned by the same PSTN operator that owns the
SPIRITS notifier.
The ensuing security discussion assumes that the SPIRITS subscriber
is communicating directly to the SPIRITS notifier (and vice-versa)
and specifies a security apparatus for this arrangement. However,
the same apparatus can be used to secure the communication between a
SPIRITS subscriber and an intermediary (like the SPIRITS gateway),
and the same intermediary and the SPIRITS notifier.
Confidentiality of the SPIRITS protocol is essential since the
information carried in the protocol data units is of a sensitive
nature and may lead to privacy concerns if revealed to non-authorized
parties. The communication path between the SPIRITS notifier and the
SPIRITS subscriber should be secured through S/MIME [18] to alleviate
privacy concerns, as is described in the Security Consideration
section of the core SIP specification [5].
S/MIME is an end-to-end security mechanism which encrypts the
SPIRITS bodies for transit across an open network. Intermediaries
need not be cognizant of S/MIME in order to route the messages
(routing headers travel in the clear).
S/MIME provides all the security aspects for SPIRITS outlined at the
beginning of this section: authentication, message integrity,
confidentiality, and non-repudiation. Authentication properties
provided by S/MIME would allow the recipient of a SPIRITS message to
ensure that the SPIRITS payload was generated by an authorized
entity. Encryption would ensure that only those SPIRITS entities
possessing a particular decryption key are capable of inspecting
encapsulated SPIRITS bodies in a SIP request.
All SPIRITS endpoints MUST support S/MIME signatures (CMS SignedData)
and MUST support encryption (CMS EnvelopedData).
If the B and C interfaces are owned by the same PSTN operator, it is
possible that public keys will be installed in the SPIRITS endpoints.
S/MIME supports two methods -- issuerAndSerialNumber and
subjectKeyIdentifier -- of naming the public key needed to validate a
signature. Between these, subjectKeyIdentifier works with X.509
certificates and other schemes as well, while issuerAndSerialNumber
works with X.509 certificates only. If the administrator configures
the necessary public keys, providing integrity through procedural
means, then S/MIME can be used without X.509 certificates.
All requests (and responses) between SPIRITS entities MUST be
encrypted.
When a request arrives at a SPIRITS notifier from a SPIRITS
subscriber, the SPIRITS notifier MUST authenticate the request. The
subscription (or registration) from a SPIRITS subscriber MUST be
rejected if the authentication fails. If the SPIRITS subscriber
successfully authenticated itself to the SPIRITS notifier, the
SPIRITS notifier MUST, at the very least, ensure that the SPIRITS
subscriber is indeed allowed to receive notifications of the events
it is subscribing to.
Note that this document does not proscribe how the SPIRITS
notifier achieves this. In practice, it could be through access
control lists (ACL) that are populated by a service management
system in the PSTN, or through a web interface of some sort.
Requests from the SPIRITS notifier to the SPIRITS subscribers MUST
also be authenticated, lest a malicious party attempts to
fraudulently pose as a SPIRITS notifier to hijack a session.
9. XML schema definition
The SPIRITS payload is specified in XML; this section defines the
base XML schema for documents that make up the SPIRITS payload. All
SPIRITS entities that transport a payload characterized by the MIME
type "application/spirits-event+xml" MUST support documents
corresponding to the base schema below.
Multiple versions of the base schema are not expected; rather, any
additional functionality (e.g., conveying new PSTN events) must be
accomplished through the definition of a new XML namespace and a
corresponding schema. Elements from the new XML namespace will then
co-exist with elements from the base schema in a document.
<xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
Describes SPIRITS events.
</xs:documentation>
</xs:annotation>
<xs:element name="spirits-event" type="tns:SpiritsEventType"/>
<xs:complexType name="SpiritsEventType">
<xs:sequence>
<xs:element name="Event" type="tns:EventType" minOccurs="1"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="EventType">
<xs:sequence>
<xs:element name="CalledPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="CallingPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>