for brevity.
Presence Server in dallas.example.net -> Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMEyGjdG1LH
To: <sip:ed@dallas.example.net>;tag=e45TmHTh
From: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 870936068 SUBSCRIBE
Contact: <sip:dallas.example.net>
Expires: 3600
Content-Length: 0
7. In this example, we assume that the server at dallas.example.net
doesn’t have enough authorization information to reject or
accept our subscription. The initial notify, therefore,
contains a "Subscription-State" of "pending". Presumably, the
party responsible for accepting or denying authorization for the
resource is notified of this change; however, those steps are
not included in this call flow for brevity.
Presence Server in dallas.example.net -> Local RLS
NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.dallas.example.net;
branch=z9hG4bKfwpklPxmrW
Max-Forwards: 70
From: <sip:ed@dallas.example.net>;tag=e45TmHTh
To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:dallas.example.net>
Subscription-State: pending;expires=3600
Event: presence
Require: eventlist
Content-Length: 0
8. The local RLS completes the NOTIFY transaction. Note that, at
this point, the Local RLS has new information to report to the
subscriber. Whether it chooses to report the information
immediately or spool it up for later delivery is completely up
to the application. For this example, we assume that the RLS
will wait for a short period of time before doing so, in order
to allow the subscriptions it sent out sufficient time to
provide useful data.
Local RLS -> Presence Server in dallas.example.net
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.dallas.example.net;
branch=z9hG4bKfwpklPxmrW
From: <sip:ed@dallas.example.net>;tag=e45TmHTh
To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Content-Length: 0
9. The Local RLS subscribes to the state of the other non-local
resource.
Local RLS -> RLS in stockholm.example.org
SUBSCRIBE sip:adam-friends@stockholm.example.org SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKFSrAF8CZFL
Max-Forwards: 70
To: <sip:adam-friends@stockholm.example.org>
From: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Identity: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp
bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p
bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8K
Identity-Info: https://vancouver.example.com/cert
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
10. The RLS in stockholm.example.org completes the SUBSCRIBE
transaction. Note that authentication would normally take place
at this point in the call flow. This step is omitted for
brevity.
RLS in stockholm.example.org -> Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKFSrAF8CZFL
To: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
From: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:stockholm.example.org>
Expires: 3600
Content-Length: 0
11. In this example, we assume that the RLS in stockholm.example.org
is also an authority for presence information for the users in
the "stockholm.example.org" domain. The NOTIFY contains an RLMI
document describing the contained buddy list, as well as
presence information for those users. In this particular case,
the RLS in stockholm.example.org has chosen to sign [14] the
body of the NOTIFY message. As described in RFC 3851, signing
is performed by creating a multipart/signed document that has
two parts. The first part is the document to be signed (in this
example, the multipart/related document that describes the list
resource states), while the second part is the actual signature.
RLS in stockholm.example.org -> Local RLS
NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.stockholm.example.org;
branch=z9hG4bKmGL1nyZfQI
Max-Forwards: 70
From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:stockholm.example.org>
Event: presence
Subscription-State: active;expires=3600
Require: eventlist
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
Content-Length: 2038
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <Cvjpeo@stockholm.example.org>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name>
<instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource>
<resource uri="sip:mark@stockholm.example.org">
<name>Mark Edwards</name>
<instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource>
</list>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@stockholm.example.org">
<tuple id="x823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@stockholm.example.org">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature
[PKCS #7 signature here]
--l3WMZaaL8NpQWGnQ4mlU--
12. The Local RLS completes the NOTIFY transaction.
Local RLS -> RLS in stockholm.example.org
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.stockholm.example.org;
branch=z9hG4bKmGL1nyZfQI
From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Content-Length: 0
13. At this point, the Local RLS decides it has collected enough
additional information to warrant sending a new notification to
the user. Although sending a full notification would be
perfectly acceptable, the RLS decides to send a partial
notification instead. The RLMI document contains only
information for the updated resources, as indicated by setting
the "fullState" parameter to "false". To avoid corrupting the
S/MIME signature on the data received from the RLS in
stockholm.example.org, the local RLS copies the entire
multipart/signed body as-is into the notification that it sends.
Local RLS -> Terminal
NOTIFY sip:terminal.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bK4EPlfSFQK1
Max-Forwards: 70
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="<2BEI83@pres.vancouver.example.com>";
boundary="TfZxoxgAvLqgj4wRWPDL"
Content-Length: 2862
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <2BEI83@pres.vancouver.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@pres.vancouver.example.com" version="2"
fullState="false">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:ed@dallas.example.net">
<name>Ed at NET</name>
<instance id="sdlkmeopdf" state="pending"/>
</resource>
<resource uri="sip:adam-friends@stockholm.example.org">
<name xml:lang="en">My Friends at ORG</name>
<name xml:lang="de">Meine Freunde an ORG</name>
<instance id="cmpqweitlp" state="active"
cid="1KQhyE@pres.vancouver.example.com"/>
</resource>
</list>
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <1KQhyE@pres.vancouver.example.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <Cvjpeo@stockholm.example.org>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true">
<name xml:lang="en">Buddy List at ORG</name>
<name xml:lang="de">Liste der Freunde an ORG</name>
<resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name>
<instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource>
<resource uri="sip:mark@stockholm.example.org">
<name>Mark Edwards</name>
<instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource>
</list>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@stockholm.example.org">
<tuple id="x823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@stockholm.example.org">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature
[PKCS #7 signature here]
--l3WMZaaL8NpQWGnQ4mlU--
--TfZxoxgAvLqgj4wRWPDL--
14. The terminal completes the NOTIFY transaction.
Terminal -> Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bK4EPlfSFQK1
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY
Contact: <sip:terminal.vancouver.example.com>
Content-Length: 0
7. Security Considerations
Note that the mechanisms for obtaining state information for
resources in a list are generally left to the RLS implementor. Some
of the security issues below are specific to the circumstance in
which a SIP back-end subscription is used for such a purpose. Non-
SIP mechanisms for obtaining state information of resources in a list
will typically have their own security issues associated with doing
so; however, exhaustively enumerating such access methods is not
possible in this document. Implementors using such mechanisms must
analyze their chosen access methods for relevant security issues.
7.1. Authentication
If back-end subscriptions are required to retrieve resource state
information, the end user is no longer the direct subscriber to the
state of the resource. This means that direct authentication of the
user is no longer possible.
7.1.1. RLS and Subscriber in the Same Domain
It is expected that the most common deployment of RLSes entails that
the subscribers to the RLS will be in the same domain as the RLS.
When this is the case, the RLS then has the ability to act as an
authentication service. The role of authentication service is
defined in "Enhancements for Authenticated Identity Management in the
Session Initiation Protocol (SIP)" [7].
At a high level, under this system, the RLS authenticates the
subscriber and then includes an "Identity" header field in all of the
back-end subscriptions performed on behalf of that authenticated
user. This "Identity" header field cryptographically asserts that
the request has been authorized to be made on behalf of the user
indicated in the "From" header field.
Because the ability to authenticate requests is central to the proper
functioning of the network, any RLS that uses SIP back-end
subscriptions to acquire information about the resources in a
resource list MUST be able to act as an authentication service as
defined in [7], provided that local administrative policy allows it
to do so.
In other words, all RLS implementations that support back-end SIP
subscriptions also must include the ability to be configured to
act as an authentication service. Whether any given administrator
chooses to activate such a feature is completely up to them. Of
course, lacking the ability to act as an identity server, any RLS
so configured will behave as described in the following section,
since it is effectively acting as if it were in a different domain
than the user.
7.1.2. RLS and Subscriber in Different Domains
In the general case, the SIP Authenticated Identity extensions do not
provide a means for the RLS to securely assert that subscriptions are
being performed on the end user’s behalf. Specifically, when the
subscriber and the RLS are in different domains, the RLS will have no
means by which it can vouch for the user’s identity. Mechanisms by
which back-end subscriptions in such circumstances can be
authenticated are left for future study.
Until such general solutions are developed, RLSes that are in a
different domain than the subscriber on whose behalf they are
creating back-end subscriptions SHOULD subscribe to the resources
using their own identity. By doing so, the RLS will generally obtain
only the resource information that is made publicly available.
Absent such general solutions, implementations of subscriber user
agents MAY attempt direct subscriptions to resources in the resource
list when subscribing to an RLS outside of their domain (either
directly or by way of another resource list subscription). The
resources to be subscribed to will be those indicated in the "uri"
attribute of the <resource> elements present in the RLMI document
returned by the RLS. Directly subscribing to the resources allows
proper authentication of the user to take place, which will generally
authorize them to receive more complete state information.
Implementations that choose to perform such direct subscriptions
SHOULD use the data retrieved instead of any information about the
resource obtained via the list subscription.
7.2. Risks of Improper Aggregation
A resource list server typically serves information to multiple
subscribers at once. In many cases, resources may be present in
several lists; additionally, it is quite possible that resource list
servers will have two users subscribe to the same list.
In these cases, misguided RLS implementations may attempt to minimize
network load by maintaining only one back-end subscription to a
resource in a list and presenting the result of such a subscription
to more than one user. Of course, doing so circumvents any
authorization policy that the notifier for the resource maintains.
Keep in mind that authorization is often much more than a simple
binary "allowed/not allowed" decision; resources may render very
different -- and even conflicting -- resource states, depending on
the identity of the subscribing user.
To prevent the transmission of event information to anyone other than
the intended recipient, implementations MUST NOT present the result
of one back-end subscription to more than one user, unless:
a. The RLS has adequate access to the complete authorization policy
associated with the resource to which the back-end subscription
has been made, AND
b. The RLS can and has determined that presenting the information to
more than one user does not violate such policy.
Note that this is a very difficult problem to solve correctly. Even
in the cases where such access is believed possible, this mode of
operation is NOT RECOMMENDED.
7.3. Signing and Sealing
Implementors should keep in mind that any section of the MIME body
may be signed and/or encrypted as necessary. Resource List Servers
should take care not to modify any MIME bodies they receive from any
back-end subscriptions, and should not generally rely on being able
to read them.
In order to facilitate security, resource list servers SHOULD pass
along indication for support of "multipart/signed" and "application/
pkcs7-mime" content types to any SIP back-end subscriptions, if the
subscriber includes them in the initial SUBSCRIBE message. Not doing
so may actually result in resources refusing to divulge state (if
notifier policy requires encryption, but the RLS fails to convey
support), or subscribers discarding valid state (if subscriber policy
requires a signature, but the RLS fails to convey support).
Note that actual implementation of encryption and signing by the RLS
is not necessary to be able to pass through signed and/or encrypted
bodies.
7.4. Infinite Loops
One risk introduced by the ability to nest resource lists is the
possibility of creating lists that ultimately contain themselves as a
sub-list. Detection and handling of such a case is trivial when the
RLS services all the virtual subscriptions internally. When back-end
subscriptions are created to service virtual subscriptions, however,
detection of such situations becomes a more difficult problem.
Implementors of RLSes that create back-end subscriptions MUST
implement safeguards to prevent such nestings from creating an
infinite loop of subscriptions. Typically, such mechanisms will
require support in the back-end subscription protocol. In
particular, applying filters to the back-end subscriptions can be an
effective way to preclude such problems.
8. IANA Considerations
8.1. New SIP Option Tag: eventlist
This section defines a new option tag for the registry established by
Section 27.1 of RFC 3261[1].
Option Tag Name: eventlist
Description: Extension to allow subscriptions to lists of resources.
Published specification: RFC 4662
8.2. New MIME type for Resource List Meta-Information
MIME Media Type Name: application
MIME subtype name: rlmi+xml
Required parameters: None
Optional parameters: charset
See RFC 3023 [12] for a discussion of the charset parameter on
XML-derived MIME types. Since this MIME type is used exclusively
in SIP, the use of UTF-8 encoding is strongly encouraged.
Encoding considerations: 8-bit text
Security considerations: Security considerations specific to uses of
this MIME type are discussed in RFC 4662. RFC 1874 [11] and RFC
3023 [12] discuss security issues common to all uses of XML.
Interoperability considerations: The use of this MIME body is
intended to be generally interoperable. No unique considerations
have been identified.
Published specification: RFC 4662
Applications that use this media type: This media type is used to
convey meta-information for the state of lists of resources within
a Session Initiation Protocol (SIP) subscription.
Additional information:
Magic Number(s): None.
File Extension(s): None.
Macintosh File Type Code(s): None.
Object Identifier(s) or OID(s): None.
Intended usage: Limited Use
Other Information/General Comment: None.
Person to contact for further information:
Name: Adam Roach
E-Mail: adam@estacado.net
Author/Change Controller: The specification of this MIME type is
a work product of the SIMPLE working group and was authored by
Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has
change control over its specification.
8.3. URN Sub-Namespace
URI: urn:ietf:params:xml:ns:rlmi
Description: This is the XML namespace URI for XML elements defined
by RFC 4662 to describe information about subscriptions when such
subscriptions are aggregated within a single SIP subscription. It
is used in the application/rlmi+xml body type.
Registrant Contact:
Name: Adam Roach
E-Mail: adam@estacado.net
Author/Change Controller: The specification of this MIME type is
a work product of the SIMPLE working group and was authored by
Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has
change control over its specification.
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 SIP Event Resource List
Meta-Information</title>
</head>
<body>
<h1>Namespace for SIP Event Resource List
Meta-Information</h1>
<h2>application/rlmi+xml</h2>
<p>See <a href="[http://www.rfc-editor.org/rfc/rfc4662.txt]">
RFC4662</a>.</p>
</body>
</html>
END
9. Acknowledgements
Thanks to Sean Olson for a review of and corrections to the usage of
XML in this protocol.
Thanks also to Hisham Khartabil, Paul Kyzivat, Keith Drage, and
Robert Sparks for their careful reviews of and comments on this
document.
10. References
10.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.