< draft-ietf-simple-event-list-06.txt   draft-ietf-simple-event-list-07.txt >
Network Working Group A. B. Roach Network Working Group A. B. Roach
Internet-Draft B. Campbell Internet-Draft B. Campbell
Expires: April 22, 2005 Estacado Systems Expires: June 15, 2005 Estacado Systems
J. Rosenberg J. Rosenberg
Cisco Systems Cisco Systems
October 22, 2004 December 15, 2004
A Session Initiation Protocol (SIP) Event Notification Extension for A Session Initiation Protocol (SIP) Event Notification Extension for
Resource Lists Resource Lists
draft-ietf-simple-event-list-06 draft-ietf-simple-event-list-07
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 4 of RFC3667. By submitting this Internet- all provisions of Section 4 of RFC3667. By submitting this Internet-
Draft, each author represents that any applicable patent or other IPR Draft, each author represents that any applicable patent or other IPR
claims of which he or she is aware have been or will be disclosed, claims of which he or she is aware have been or will be disclosed,
and any of which he or she become aware will be disclosed, in and any of which he or she become aware will be disclosed, in
accordance with RFC 3668. accordance with RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2005. This Internet-Draft will expire on June 15, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document presents an extension to the Session Initiation This document presents an extension to the Session Initiation
Protocol (SIP)-Specific Event Notification mechanism for subscribing Protocol (SIP)-Specific Event Notification mechanism for subscribing
to a homogeneous list of resources. Instead of the subscriber to a homogeneous list of resources. Instead of the subscriber
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 6 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 6
4. Operation of List Subscriptions . . . . . . . . . . . . . . 7 4. Operation of List Subscriptions . . . . . . . . . . . . . . 7
4.1 Negotiation of Support for Resource Lists . . . . . . . . . 7 4.1 Negotiation of Support for Resource Lists . . . . . . . . . 7
4.2 Subscription Duration . . . . . . . . . . . . . . . . . . . 8 4.2 Subscription Duration . . . . . . . . . . . . . . . . . . . 8
4.3 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 RLS Processing of SUBSCRIBE Requests . . . . . . . . . . . . 8 4.4 RLS Processing of SUBSCRIBE Requests . . . . . . . . . . . . 8
4.5 RLS Generation of NOTIFY requests . . . . . . . . . . . . . 9 4.5 RLS Generation of NOTIFY requests . . . . . . . . . . . . . 9
4.6 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 10 4.6 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 10
4.7 Handling of Forked Requests . . . . . . . . . . . . . . . . 11 4.7 Handling of Forked Requests . . . . . . . . . . . . . . . . 11
4.8 Rate of Notifications . . . . . . . . . . . . . . . . . . . 11 4.8 Rate of Notifications . . . . . . . . . . . . . . . . . . . 11
5. Using multipart/related to Convey Aggregate State . . . . . 12 5. Using multipart/related to Convey Aggregate State . . . . . 13
5.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 14 5.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 15 5.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 16
5.4 Name Attributes . . . . . . . . . . . . . . . . . . . . . . 15 5.4 Name Attributes . . . . . . . . . . . . . . . . . . . . . . 16
5.5 Instance Attributes . . . . . . . . . . . . . . . . . . . . 15 5.5 Instance Attributes . . . . . . . . . . . . . . . . . . . . 16
5.6 Constructing Coherent Resource State . . . . . . . . . . . . 17 5.6 Constructing Coherent Resource State . . . . . . . . . . . . 18
5.6.1 Processing Full State Notifications . . . . . . . . . . . . 18 5.6.1 Processing Full State Notifications . . . . . . . . . . . . 19
5.6.2 Processing Partial State Notifications . . . . . . . . . . . 18 5.6.2 Processing Partial State Notifications . . . . . . . . . . . 19
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . 34
7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 32 7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34
7.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 32 7.1.1 RLS and Subscriber in the Same Domain . . . . . . . . . . . 34
7.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 33 7.1.2 RLS and Subscriber in Different Domains . . . . . . . . . . 35
7.4 Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . 33 7.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 7.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 36
8.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 35 7.4 Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . 36
8.2 New MIME type for Resource List Meta-Information . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
8.3 URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . . 36 8.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 38
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 8.2 New MIME type for Resource List Meta-Information . . . . . . 38
Normative References . . . . . . . . . . . . . . . . . . . . 39 8.3 URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . . 39
Non-Normative References . . . . . . . . . . . . . . . . . . 40 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 Normative References . . . . . . . . . . . . . . . . . . . . 42
A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Informative References . . . . . . . . . . . . . . . . . . . 43
A.1 Changes since -05 . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
A.2 Changes since -04 . . . . . . . . . . . . . . . . . . . . . 42 A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.3 Changes since -03 . . . . . . . . . . . . . . . . . . . . . 42 A.1 Changes since -06 . . . . . . . . . . . . . . . . . . . . . 45
A.4 Changes since -02 . . . . . . . . . . . . . . . . . . . . . 42 A.2 Changes since -05 . . . . . . . . . . . . . . . . . . . . . 45
A.5 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 43 A.3 Changes since -04 . . . . . . . . . . . . . . . . . . . . . 45
A.6 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 43 A.4 Changes since -03 . . . . . . . . . . . . . . . . . . . . . 45
B. Intellectual Property Statement . . . . . . . . . . . . . . 44 A.5 Changes since -02 . . . . . . . . . . . . . . . . . . . . . 46
Full Copyright Statement . . . . . . . . . . . . . . . . . . 45 A.6 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 46
A.7 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 46
B. Intellectual Property Statement . . . . . . . . . . . . . . 47
Full Copyright Statement . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
The SIP-specific event notification mechanism [2] allows a user (the The SIP-specific event notification mechanism [2] allows a user (the
subscriber) to request to be notified of changes in the state of a subscriber) to request to be notified of changes in the state of a
particular resource. This is accomplished by having the subscriber particular resource. This is accomplished by having the subscriber
generate a SUBSCRIBE request for the resource, which is processed by generate a SUBSCRIBE request for the resource, which is processed by
a notifier that represents the resource. a notifier that represents the resource.
In many cases, a subscriber has a list of resources they are In many cases, a subscriber has a list of resources they are
skipping to change at page 8, line 13 skipping to change at page 8, line 13
messages within that subscription. messages within that subscription.
Use of "Require: eventlist" in NOTIFY messages is applied by the Use of "Require: eventlist" in NOTIFY messages is applied by the
notifier to satisfy the RFC3261 requirement that a UAC MUST insert notifier to satisfy the RFC3261 requirement that a UAC MUST insert
a Require header field into a request if the UAC wishes to insist a Require header field into a request if the UAC wishes to insist
that a UAS understand an extension in order to process the that a UAS understand an extension in order to process the
request. Because the NOTIFY would not be usable without applying request. Because the NOTIFY would not be usable without applying
the eventlist option, the notifier is obligated to include it. the eventlist option, the notifier is obligated to include it.
Including "eventlist" in a "Require" header field in a SUBSCRIBE Including "eventlist" in a "Require" header field in a SUBSCRIBE
request serves no purpose, and is consequently NOT RECOMMENDED. request serves no purpose except breaking interoperability in certain
cases, and is consequently NOT RECOMMENDED.
Sending of "Supported: eventlist" in a NOTIFY message is meaningless
and silly. Implementations SHOULD NOT include "Supported: eventlist"
in any requests except for SUBSCRIBE.
There is nothing in a SIP URI which indicates whether it represents a There is nothing in a SIP URI which indicates whether it represents a
list of resources or a single resource. Therefore, if a subscriber list of resources or a single resource. Therefore, if a subscriber
sends a request to a URI that represents a list resource, but does sends a request to a URI that represents a list resource, but does
not include a Supported header field listing the "eventlist" token, not include a Supported header field listing the "eventlist" token,
the notifier will typically return a 421 (Extension Required) the notifier will typically return a 421 (Extension Required)
response code. RFC 3261 [1] advises servers to avoid returning a response code. RFC 3261 [1] advises servers to avoid returning a
421, and instead, attempt to process the request without the 421, and instead, attempt to process the request without the
extension. However, in this case, the URI fundamentally represents a extension. However, in this case, the URI fundamentally represents a
list resource, and therefore, the subscription cannot proceed without list resource, and therefore, the subscription cannot proceed without
skipping to change at page 9, line 15 skipping to change at page 9, line 19
4.5 RLS Generation of NOTIFY requests 4.5 RLS Generation of NOTIFY requests
This specification leaves the choice about how and when to generate This specification leaves the choice about how and when to generate
NOTIFY requests at the discretion of the implementor. One of the NOTIFY requests at the discretion of the implementor. One of the
value propositions of the RLS is the means by which it aggregates, value propositions of the RLS is the means by which it aggregates,
rate limits, or optimizes the way in which notifications are rate limits, or optimizes the way in which notifications are
generated. As a baseline behavior, the RLS MAY generate a NOTIFY to generated. As a baseline behavior, the RLS MAY generate a NOTIFY to
the RLS subscriber whenever the state of any resource on the list the RLS subscriber whenever the state of any resource on the list
changes. changes.
It is important to understand that any given subscription is a
subscription to either a single resource, or to a list of resources.
This nature (single resource versus list of resources) cannot change
during the duration of a single subscription. In particular, this
means that RLSes MUST NOT send NOTIFY messages which do not contain
RLMI for a subscription if they have previously sent NOTIFY messages
in that subscription containing RLMI. Similarly, RLSes MUST NOT send
NOTIFY messages which do contain RLMI for a subscription if they have
previously sent NOTIFY messages in that subscription which do not.
List representations necessarily contain RLMI documents for two
reasons. Importantly, they identify the resource to which event
state corresponds. Many state syntaxes do not fully identify the
resource to which the state applies, or may identify the resource
in a different way than it is represented in the list; for
example, PIDF documents may contain resource URIs which are not
identical to the URI used to retrieve them. Further, RLMI
documents serve to disambiguate multiple instances of a single
resource.
See Section 5 for a detailed definition of the syntax used to convey See Section 5 for a detailed definition of the syntax used to convey
the state of resource lists. For the purposes of the following the state of resource lists. For the purposes of the following
discussion, it is important to know that the overall list contains discussion, it is important to know that the overall list contains
zero or more resources, and that the resources contains zero or more zero or more resources, and that the resources contains zero or more
instances. Each instance has a state associated with it (pending, instances. Each instance has a state associated with it (pending,
active, or terminating), representing the state of the virtual active, or terminating), representing the state of the virtual
subscription. subscription.
Notifications contain a multipart document, the first part of which Notifications contain a multipart document, the first part of which
always contains meta-information about the list (e.g. membership, always contains meta-information about the list (e.g. membership,
skipping to change at page 13, line 20 skipping to change at page 14, line 20
<xs:any minOccurs="0" maxOccurs="unbounded" /> <xs:any minOccurs="0" maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
<xs:attribute name="id" type="xs:string" use="required" /> <xs:attribute name="id" type="xs:string" use="required" />
<xs:attribute name="state" use="required"> <xs:attribute name="state" use="required">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="active" /> <xs:enumeration value="active" />
<xs:enumeration value="pending" /> <xs:enumeration value="pending" />
<xs:enumeration value="terminated" /> <xs:enumeration value="terminated" />
</xs:restriction> </xs:restriction>
</xs:attribute> </xs:attribute>
<xs:attribute name="reason" type="xs:string" use="optional" /> <xs:attribute name="reason" type="xs:string"
use="optional" />
<xs:attribute name="cid" type="xs:string" use="optional" /> <xs:attribute name="cid" type="xs:string" use="optional" />
<xs:anyAttribute /> <xs:anyAttribute />
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="name"> <xs:element name="name">
<xs:complexType> <xs:complexType>
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute name="language" type="xs:string" use="optional" /> <xs:attribute name="language" type="xs:string"
use="optional" />
</xs:extension"> </xs:extension">
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
An example of a document formatted using this schema follows. An example of a document formatted using this schema follows.
<?xml version="1.0"?> <?xml version="1.0"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" <list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@lists.example.com" version="7" uri="sip:adam-friends@lists.vancouver.example.com"
fullState="true"> version="7" fullState="true">
<name language="en">Buddy List</name> <name language="en">Buddy List</name>
<name language="fr">Liste d'amis</name> <name language="fr">Liste d'amis</name>
<resource uri="sip:bob@example.com> <resource uri="sip:bob@vancouver.example.com>
<name>Bob Smith</name> <name>Bob Smith</name>
<instance id="juwigmtboe" state="active" <instance id="juwigmtboe" state="active"
cid="12345.aaa@example.com"/> cid="12345.aaa@vancouver.example.com"/>
</resource> </resource>
<resource uri="sip:dave@example.com"> <resource uri="sip:dave@vancouver.example.com">
<name>Dave Jones</name> <name>Dave Jones</name>
<instance id="hqzsuxtfyq" state="active" <instance id="hqzsuxtfyq" state="active"
cid="12345.aab@example.com"/> cid="12345.aab@vancouver.example.com"/>
</resource> </resource>
<resource uri="sip:jim@example.com"> <resource uri="sip:jim@vancouver.example.com">
<name>Jim</name> <name>Jim</name>
<instance id="oflzxqzuvg" state="terminated" reason="rejected" /> <instance id="oflzxqzuvg" state="terminated"
reason="rejected" />
</resource> </resource>
<resource uri="sip:ed@example.com"> <resource uri="sip:ed@vancouver.example.com">
<name>Ed</name> <name>Ed</name>
<instance id="grqhzsppxb" state="pending"/> <instance id="grqhzsppxb" state="pending"/>
</resource> </resource>
</list> </list>
5.2 List Attributes 5.2 List Attributes
The <list> element present in a list notification MUST contain three The <list> element present in a list notification MUST contain three
attributes. attributes.
skipping to change at page 16, line 40 skipping to change at page 17, line 42
conveying state. The cid attribute is the Content-ID for the conveying state. The cid attribute is the Content-ID for the
corresponding section in the multipart body. corresponding section in the multipart body.
The cid attribute MUST refer only to top-level parts of the The cid attribute MUST refer only to top-level parts of the
multipart/related document for which the RLMI document in which it multipart/related document for which the RLMI document in which it
appears is the root. appears is the root.
For example, consider a multipart/related document containing For example, consider a multipart/related document containing
three parts; we'll label these parts A, B, and C. Part A is type three parts; we'll label these parts A, B, and C. Part A is type
application/rlmi+xml, part B is type multipart/related, and part C application/rlmi+xml, part B is type multipart/related, and part C
is type application/cpim-pidf+xml. Part B is in turn a document is type application/pidf+xml. Part B is in turn a document
containing three parts: D, E, and F. Part D is of type containing three parts: D, E, and F. Part D is of type
application/rlmi+xml, and parts E and F are of type application/ application/rlmi+xml, and parts E and F are of type application/
cpim-pidf+xml. pidf+xml.
+-------------------------------------------+ +-------------------------------------------+
| Top Level Document: multipart/related | | Top Level Document: multipart/related |
| | | |
| +---------------------------------------+ | | +---------------------------------------+ |
| | Part A: application/rlmi+xml | | | | Part A: application/rlmi+xml | |
| +---------------------------------------+ | | +---------------------------------------+ |
| | Part B: multipart/related | | | | Part B: multipart/related | |
| | | | | | | |
| | +-----------------------------------+ | | | | +-----------------------------------+ | |
| | | Part D: application/rlmi+xml | | | | | | Part D: application/rlmi+xml | | |
| | +-----------------------------------+ | | | | +-----------------------------------+ | |
| | | Part E: application/cpim-pidf+xml | | | | | | Part E: application/pidf+xml | | |
| | +-----------------------------------+ | | | | +-----------------------------------+ | |
| | | Part F: application/cpim-pidf+xml | | | | | | Part F: application/pidf+xml | | |
| | +-----------------------------------+ | | | | +-----------------------------------+ | |
| | | | | | | |
| +---------------------------------------+ | | +---------------------------------------+ |
| | Part C: application/cpim-pidf+xml | | | | Part C: application/pidf+xml | |
| +---------------------------------------+ | | +---------------------------------------+ |
| | | |
+-------------------------------------------+ +-------------------------------------------+
Any "cid" attributes in document A must refer only to parts B or Any "cid" attributes in document A must refer only to parts B or
C. Referring to parts D, E, or F would be illegal. Similarly, C. Referring to parts D, E, or F would be illegal. Similarly,
Any "cid" attributes in document D must refer only to parts E or Any "cid" attributes in document D must refer only to parts E or
F. Referring to any other parts would be illegal. F. Referring to any other parts would be illegal.
Also note that the subscription durations of any back-end Also note that the subscription durations of any back-end
skipping to change at page 19, line 14 skipping to change at page 20, line 14
6. Example 6. Example
This section gives an example call flow. It is not normative. If a This section gives an example call flow. It is not normative. If a
conflict arises between this call flow and the normative behavior conflict arises between this call flow and the normative behavior
described in this or any other document, the normative descriptions described in this or any other document, the normative descriptions
are to be followed. are to be followed.
In this particular example, we request a subscription to a nested In this particular example, we request a subscription to a nested
presence list. The subscriber's address-of-record is presence list. The subscriber's address-of-record is
"sip:adam@example.com", and the name of the nested list resource that "sip:adam@vancouver.example.com", and the name of the nested list
we are subscribing to is called "sip:adam-buddies@pres.example.com". resource that we are subscribing to is called "sip:adam-
The underlying event package is "presence", described by [7]. buddies@pres.vancouver.example.com". The underlying event package is
"presence", described by [8].
In this example, the RLS has information to service some of the In this example, the RLS has information to service some of the
resources on the list, but must consult other servers to retrieve resources on the list, but must consult other servers to retrieve
information for others. The implementation of the RLS in this information for others. The implementation of the RLS in this
example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such
information. information.
Terminal pres.example.com pres.example.org Terminal pres.vancouver.example.com pres.stockholm.example.org
| | pres.example.net | | | pres.dallas.example.net |
1 |---SUBSCRIBE--->| | | 1 |---SUBSCRIBE--->| | |
2 |<-----200-------| | | 2 |<-----200-------| | |
3 |<----NOTIFY-----| | | 3 |<----NOTIFY-----| | |
4 |------200------>| | | 4 |------200------>| | |
5 | |---SUBSCRIBE--->| | 5 | |---SUBSCRIBE--->| |
6 | |<-----200-------| | 6 | |<-----200-------| |
7 | |<----NOTIFY-----| | 7 | |<----NOTIFY-----| |
8 | |------200------>| | 8 | |------200------>| |
9 | |------------SUBSCRIBE----------->| 9 | |------------SUBSCRIBE----------->|
10| |<--------------200---------------| 10| |<--------------200---------------|
11| |<-------------NOTIFY-------------| 11| |<-------------NOTIFY-------------|
12| |---------------200-------------->| 12| |---------------200-------------->|
13|<----NOTIFY-----| | | 13|<----NOTIFY-----| | |
14|------200------>| | | 14|------200------>| | |
1. We initiate the subscription by sending a SUBSCRIBE message to 1. We initiate the subscription by sending a SUBSCRIBE message to
our local RLS. (There is no reason that the RLS we contact has our local RLS. (There is no reason that the RLS we contact has
to be in our domain, of course). Note that we must advertise to be in our domain, of course). Note that we must advertise
support for application/rlmi+xml and multipart/related because support for application/rlmi+xml and multipart/related because
we support the eventlist extension, and we must advertise we support the eventlist extension, and we must advertise
application/cpim-pidf+xml because we are requesting a application/pidf+xml because we are requesting a subscription to
subscription to presence. presence.
Terminal -> Local RLS Terminal -> Local RLS
SUBSCRIBE sip:adam-buddies@pres.example.com SIP/2.0 SUBSCRIBE sip:adam-buddies@pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL Via: SIP/2.0/TCP terminal.vancouver.example.com;
branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70 Max-Forwards: 70
To: <sip:adam-buddies@pres.example.com> To: <sip:adam-buddies@pres.vancouver.example.com>
From: <sip:adam@example.com>;tag=ie4hbb8t From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 322723822 SUBSCRIBE CSeq: 322723822 SUBSCRIBE
Contact: <sip:terminal.example.com> Contact: <sip:terminal.vancouver.example.com>
Event: presence Event: presence
Expires: 7200 Expires: 7200
Supported: eventlist Supported: eventlist
Accept: application/cpim-pidf+xml Accept: application/pidf+xml
Accept: application/rlmi+xml Accept: application/rlmi+xml
Accept: multipart/related Accept: multipart/related
Accept: multipart/signed Accept: multipart/signed
Accept: application/pkcs7-mime Accept: application/pkcs7-mime
Content-Length: 0 Content-Length: 0
2. The Local RLS completes the SUBSCRIBE transaction. Note that 2. The Local RLS completes the SUBSCRIBE transaction. Note that
authentication and authorization would normally take place at authentication and authorization would normally take place at
this point in the call flow. Those steps are omitted for this point in the call flow. Those steps are omitted for
brevity. brevity.
Local RLS -> Terminal Local RLS -> Terminal
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL Via: SIP/2.0/TCP terminal.vancouver.example.com;
To: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq branch=z9hG4bKwYb6QREiCL
From: <sip:adam@example.com>;tag=ie4hbb8t To: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
Call-ID: cdB34qLToC@terminal.example.com From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 322723822 SUBSCRIBE CSeq: 322723822 SUBSCRIBE
Contact: <sip:pres.example.com> Contact: <sip:pres.vancouver.example.com>
Expires: 7200 Expires: 7200
Require: eventlist Require: eventlist
Content-Length: 0 Content-Length: 0
3. As is required by RFC 3265 [2], the RLS sends a NOTIFY 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY
immediately upon accepting the subscription. In this example, immediately upon accepting the subscription. In this example,
we are assuming that the local RLS is also an authority for we are assuming that the local RLS is also an authority for
presence information for the users in the "example.com" domain. presence information for the users in the
The NOTIFY contains an RLMI document describing the entire buddy "vancouver.example.com" domain. The NOTIFY contains an RLMI
list (initial notifies require full state), as well as presence document describing the entire buddy list (initial notifies
information for the users about which it already knows. Note require full state), as well as presence information for the
that, since the RLS has not yet retrieved information for some users about which it already knows. Note that, since the RLS
of the entries on the list, those <resource> elements contain no has not yet retrieved information for some of the entries on the
<instance> elements. list, those <resource> elements contain no <instance> elements.
Local RLS -> Terminal Local RLS -> Terminal
NOTIFY sip:terminal.example.com SIP/2.0 NOTIFY sip:terminal.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMgRenTETmm
Max-Forwards: 70 Max-Forwards: 70
From: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@example.com>;tag=ie4hbb8t To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935768 NOTIFY CSeq: 997935768 NOTIFY
Contact: <sip:pres.example.com> Contact: <sip:pres.vancouver.example.com>
Event: presence Event: presence
Subscription-State: active;expires=7200 Subscription-State: active;expires=7200
Require: eventlist Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml"; Content-Type: multipart/related;type="application/rlmi+xml";
start="<nXYxAE@pres.example.com>";boundary="50UBfW7LSCVLtggUPe5z" start="<nXYxAE@pres.vancouver.example.com>";
boundary="50UBfW7LSCVLtggUPe5z"
Content-Length: 1560 Content-Length: 1560
--50UBfW7LSCVLtggUPe5z --50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@pres.example.com> Content-ID: <nXYxAE@pres.vancouver.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8" Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" <list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@pres.example.com" version="1" uri="sip:adam-friends@pres.vancouver.example.com"
fullState="true"> version="1" fullState="true">
<name language="en">Buddy List at COM</name> <name language="en">Buddy List at COM</name>
<name language="de">Liste der Freunde an COM</name> <name language="de">Liste der Freunde an COM</name>
<resource uri="sip:bob@example.com""> <resource uri="sip:bob@vancouver.example.com"">
<name>Bob Smith</name> <name>Bob Smith</name>
<instance id="juwigmtboe" state="active" <instance id="juwigmtboe" state="active"
cid="bUZBsM@pres.example.com"/> cid="bUZBsM@pres.vancouver.example.com"/>
</resource> </resource>
<resource uri="sip:dave@example.com"> <resource uri="sip:dave@vancouver.example.com">
<name>Dave Jones</name> <name>Dave Jones</name>
<instance id="hqzsuxtfyq" state="active" <instance id="hqzsuxtfyq" state="active"
cid="ZvSvkz@pres.example.com"/> cid="ZvSvkz@pres.vancouver.example.com"/>
</resource> </resource>
<resource uri="sip:ed@example.net"> <resource uri="sip:ed@dallas.example.net">
<name>Ed at NET</name> <name>Ed at NET</name>
</resource> </resource>
<resource uri="sip:adam-friends@example.org"> <resource uri="sip:adam-friends@stockholm.example.org">
<name language="en">My Friends at ORG</name> <name language="en">My Friends at ORG</name>
<name language="de">Meine Freunde an ORG</name> <name language="de">Meine Freunde an ORG</name>
</resource> </resource>
</list> </list>
--50UBfW7LSCVLtggUPe5z --50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <bUZBsM@pres.example.com> Content-ID: <bUZBsM@pres.vancouver.example.com>
Content-Type: application/cpim-pidf+xml;charset="UTF-8" Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:bob@example.com"> entity="sip:bob@vancouver.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<status> <status>
<basic>open</basic> <basic>open</basic>
</status> </status>
<contact priority="1.0">sip:bob@example.com</contact> <contact priority="1.0">sip:bob@vancouver.example.com</contact>
</tuple> </tuple>
</presence> </presence>
--50UBfW7LSCVLtggUPe5z --50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <ZvSvkz@pres.example.com> Content-ID: <ZvSvkz@pres.vancouver.example.com>
Content-Type: application/cpim-pidf+xml;charset="UTF-8" Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:dave@example.com"> entity="sip:dave@vancouver.example.com">
<tuple id="slie74"> <tuple id="slie74">
<status> <status>
<basic>closed</basic> <basic>closed</basic>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--50UBfW7LSCVLtggUPe5z-- --50UBfW7LSCVLtggUPe5z--
4. The terminal completes the transaction. 4. The terminal completes the transaction.
Terminal -> Local RLS Terminal -> Local RLS
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm Via: SIP/2.0/TCP pres.vancouver.example.com;
From: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq branch=z9hG4bKMgRenTETmm
To: <sip:adam@example.com>;tag=ie4hbb8t From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
Call-ID: cdB34qLToC@terminal.example.com To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935768 NOTIFY CSeq: 997935768 NOTIFY
Contact: <sip:terminal.example.com> Contact: <sip:terminal.vancouver.example.com>
Content-Length: 0 Content-Length: 0
5. In order to service the subscription, the local RLS subscribes 5. In order to service the subscription, the local RLS subscribes
to the state of the resources. In this step, the RLS attempts to the state of the resources. In this step, the RLS attempts
to subscribe to the presence state of the resource to subscribe to the presence state of the resource
"sip:ed@example.net". Since the local RLS knows how to receive "sip:ed@dallas.example.net". Since the local RLS knows how to
notifications for list subscriptions, it includes the receive notifications for list subscriptions, it includes the
"Supported: eventlist" header field in its request. Although "Supported: eventlist" header field in its request. Although
the linkage between this subscription and the one sent by the the linkage between this subscription and the one sent by the
terminal is left up to the application, this message terminal is left up to the application, this message
demonstrates some reasonable behavior by including "Accept" demonstrates some reasonable behavior by including "Accept"
header fields for all of the body types it knows the subscriber header fields for all of the body types it knows the subscriber
(Terminal) supports. This is safe to do, since the local RLS (Terminal) supports. This is safe to do, since the local RLS
will only pass these formats through to the subscriber, and does will only pass these formats through to the subscriber, and does
not need to actually understand them. not need to actually understand them.
Local RLS -> Presence Server in example.net Local RLS -> Presence Server in dallas.example.net
SUBSCRIBE sip:ed@example.net SIP/2.0 SUBSCRIBE sip:ed@dallas.example.net SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMEyGjdG1LH
Max-Forwards: 70 Max-Forwards: 70
To: <sip:ed@example.net> To: <sip:ed@dallas.example.net>
From: <sip:pres.example.com>;tag=aM5icQu9 From: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 870936068 SUBSCRIBE CSeq: 870936068 SUBSCRIBE
Contact: <sip:pres.example.com> Contact: <sip:pres.vancouver.example.com>
Identity: Tm8sIHRoaXMgaXNuJ3QgYSByZWFsIGNlcnQuIFlvdSBvn
Zpb3VzbHkgaGF2ZSB0aW1lIHRvIGtpbGwuIEkKc3VnZ2V
zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8K
Identity-Info: https://vancouver.example.com/cert
Event: presence Event: presence
Expires: 3600 Expires: 3600
Supported: eventlist Supported: eventlist
Accept: application/cpim-pidf+xml Accept: application/pidf+xml
Accept: application/rlmi+xml Accept: application/rlmi+xml
Accept: multipart/related Accept: multipart/related
Accept: multipart/signed Accept: multipart/signed
Accept: application/pkcs7-mime Accept: application/pkcs7-mime
Content-Length: 0 Content-Length: 0
6. The Presence Server in example.net completes the SUBSCRIBE
transaction. Note that authentication would normally take place
at this point in the call flow. Those steps are omitted for
brevity.
Presence Server in example.net -> Local RLS 6. The Presence Server in dallas.example.net completes the
SUBSCRIBE transaction. Note that authentication would normally
take place at this point in the call flow. Those steps are
omitted for brevity.
Presence Server in dallas.example.net -> Local RLS
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH Via: SIP/2.0/TCP pres.vancouver.example.com;
To: <sip:ed@example.net>;tag=e45TmHTh branch=z9hG4bKMEyGjdG1LH
From: <sip:pres.example.com>;tag=aM5icQu9 To: <sip:ed@dallas.example.net>;tag=e45TmHTh
Call-ID: Ugwz5ARxNw@pres.example.com From: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 870936068 SUBSCRIBE CSeq: 870936068 SUBSCRIBE
Contact: <sip:example.net> Contact: <sip:dallas.example.net>
Expires: 3600 Expires: 3600
Content-Length: 0 Content-Length: 0
7. In this example, we assume that the server at example.net 7. In this example, we assume that the server at dallas.example.net
doesn't have enough authorization information to reject or doesn't have enough authorization information to reject or
accept our subscription. The initial notify, therefore, accept our subscription. The initial notify, therefore,
contains a "Subscription-State" of "pending". Presumably, the contains a "Subscription-State" of "pending". Presumably, the
party responsible for accepting or denying authorization for the party responsible for accepting or denying authorization for the
resource is notified of this change; however, those steps are resource is notified of this change; however, those steps are
not included in this call flow for brevity. not included in this call flow for brevity.
Presence Server in example.net -> Local RLS Presence Server in dallas.example.net -> Local RLS
NOTIFY sip:pres.example.com SIP/2.0 NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW Via: SIP/2.0/TCP pres.dallas.example.net;
branch=z9hG4bKfwpklPxmrW
Max-Forwards: 70 Max-Forwards: 70
From: <sip:ed@example.net>;tag=e45TmHTh From: <sip:ed@dallas.example.net>;tag=e45TmHTh
To: <sip:pres.example.com>;tag=aM5icQu9 To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY CSeq: 1002640632 NOTIFY
Contact: <sip:example.net> Contact: <sip:dallas.example.net>
Subscription-State: pending;expires=3600 Subscription-State: pending;expires=3600
Event: presence Event: presence
Require: eventlist Require: eventlist
Content-Length: 0 Content-Length: 0
8. The local RLS completes the NOTIFY transaction. Note that, at 8. The local RLS completes the NOTIFY transaction. Note that, at
this point, the Local RLS has new information to report to the this point, the Local RLS has new information to report to the
subscriber. Whether it chooses to report the information subscriber. Whether it chooses to report the information
immediately or spool it up for later delivery is completely up immediately or spool it up for later delivery is completely up
to the application. For this example, we assume that the RLS to the application. For this example, we assume that the RLS
will wait for a short period of time before doing so, in order will wait for a short period of time before doing so, in order
to allow the subscriptions it sent out sufficient time to to allow the subscriptions it sent out sufficient time to
provide useful data. provide useful data.
Local RLS -> Presence Server in example.net Local RLS -> Presence Server in dallas.example.net
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW Via: SIP/2.0/TCP pres.dallas.example.net;
From: <sip:ed@example.net>;tag=e45TmHTh branch=z9hG4bKfwpklPxmrW
To: <sip:pres.example.com>;tag=aM5icQu9 From: <sip:ed@dallas.example.net>;tag=e45TmHTh
Call-ID: Ugwz5ARxNw@pres.example.com To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY CSeq: 1002640632 NOTIFY
Contact: <sip:pres.example.com> Contact: <sip:pres.vancouver.example.com>
Content-Length: 0 Content-Length: 0
9. The Local RLS subscribes to the state of the other non-local 9. The Local RLS subscribes to the state of the other non-local
resource. resource.
Local RLS -> RLS in example.org Local RLS -> RLS in stockholm.example.org
SUBSCRIBE sip:adam-friends@example.org SIP/2.0 SUBSCRIBE sip:adam-friends@stockholm.example.org SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKFSrAF8CZFL
Max-Forwards: 70 Max-Forwards: 70
To: <sip:adam-friends@example.org> To: <sip:adam-friends@stockholm.example.org>
From: <sip:pres.example.com>;tag=a12eztNf From: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE CSeq: 980774491 SUBSCRIBE
Contact: <sip:pres.example.com> Contact: <sip:pres.vancouver.example.com>
Identity: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp
bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p
bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8K
Identity-Info: https://vancouver.example.com/cert
Event: presence Event: presence
Expires: 3600 Expires: 3600
Supported: eventlist Supported: eventlist
Accept: application/cpim-pidf+xml Accept: application/pidf+xml
Accept: application/rlmi+xml Accept: application/rlmi+xml
Accept: multipart/related Accept: multipart/related
Accept: multipart/signed Accept: multipart/signed
Accept: application/pkcs7-mime Accept: application/pkcs7-mime
Content-Length: 0 Content-Length: 0
10. The RLS in example.org completes the SUBSCRIBE transaction. 10. The RLS in stockholm.example.org completes the SUBSCRIBE
Note that authentication and would normally take place at this transaction. Note that authentication and would normally take
point in the call flow. Those steps are omitted for brevity. place at this point in the call flow. Those steps are omitted
for brevity.
RLS in example.org -> Local RLS RLS in stockholm.example.org -> Local RLS
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL Via: SIP/2.0/TCP pres.vancouver.example.com;
To: <sip:adam-friends@example.org>;tag=JenZ40P3 branch=z9hG4bKFSrAF8CZFL
From: <sip:pres.example.com>;tag=a12eztNf To: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
Call-ID: kBq5XhtZLN@pres.example.com From: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE CSeq: 980774491 SUBSCRIBE
Contact: <sip:example.org> Contact: <sip:stockholm.example.org>
Expires: 3600 Expires: 3600
Content-Length: 0 Content-Length: 0
11. In this example, we are assuming that the RLS in example.org is 11. In this example, we are assuming that the RLS in
also an authority for presence information for the users in the stockholm.example.org is also an authority for presence
"example.org" domain. The NOTIFY contains an RLMI document information for the users in the "stockholm.example.org" domain.
describing the contained buddy list, as well as presence The NOTIFY contains an RLMI document describing the contained
information for those users. In this particular case, the RLS buddy list, as well as presence information for those users. In
in example.org has chosen to sign [14] the body of the NOTIFY this particular case, the RLS in stockholm.example.org has
message. As described in RFC 3851, signing is performed by chosen to sign [14] the body of the NOTIFY message. As
creating a multipart/signed document which has two parts. The described in RFC 3851, signing is performed by creating a
first part is the document to be signed (in this example, the multipart/signed document which has two parts. The first part
multipart/related document that describes the list resource is the document to be signed (in this example, the multipart/
states), while the second part is the actual signature. related document that describes the list resource states), while
the second part is the actual signature.
RLS in example.org -> Local RLS RLS in stockholm.example.org -> Local RLS
NOTIFY sip:pres.example.com SIP/2.0 NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI Via: SIP/2.0/TCP pres.stockholm.example.org;
branch=z9hG4bKmGL1nyZfQI
Max-Forwards: 70 Max-Forwards: 70
From: <sip:adam-friends@example.org>;tag=JenZ40P3 From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
To: <sip:pres.example.com>;tag=a12eztNf To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY CSeq: 294444656 NOTIFY
Contact: <sip:example.org> Contact: <sip:stockholm.example.org>
Event: presence Event: presence
Subscription-State: active;expires=3600 Subscription-State: active;expires=3600
Require: eventlist Require: eventlist
Content-Type: multipart/signed; Content-Type: multipart/signed;
protocol="application/pkcs7-signature"; protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
Content-Length: 2038 Content-Length: 2038
--l3WMZaaL8NpQWGnQ4mlU --l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@example.org> Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml"; Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@example.org>";boundary="tuLLl3lDyPZX0GMr2YOo" start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo --tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <Cvjpeo@example.org> Content-ID: <Cvjpeo@stockholm.example.org>
Content-Type: application/rlmi+xml;charset="UTF-8" Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" <list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@example.org" version="1" uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true"> fullState="true">
<name language="en">Buddy List at COM</name> <name language="en">Buddy List at COM</name>
<name language="de">Liste der Freunde an COM</name> <name language="de">Liste der Freunde an COM</name>
<resource uri="sip:joe@example.org"> <resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name> <name>Joe Thomas</name>
<instance id="1" state="active" cid="mrEakg@example.org"/> <instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource> </resource>
<resource uri="sip:mark@example.org"> <resource uri="sip:mark@stockholm.example.org">
<name>Mark Edwards</name> <name>Mark Edwards</name>
<instance id="1" state="active" cid="KKMDmv@example.org"/> <instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource> </resource>
</list> </list>
--tuLLl3lDyPZX0GMr2YOo --tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <mrEakg@example.org> Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/cpim-pidf+xml;charset="UTF-8" Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@example.org"> entity="sip:joe@stockholm.example.org">
<tuple id="7823a4"> <tuple id="7823a4">
<status> <status>
<basic>open</basic> <basic>open</basic>
</status> </status>
<contact priority="1.0">sip:joe@example.org</contact> <contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple> </tuple>
</presence> </presence>
--tuLLl3lDyPZX0GMr2YOo --tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@example.org> Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/cpim-pidf+xml;charset="UTF-8" Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@example.org"> entity="sip:mark@stockholm.example.org">
<tuple id="398075"> <tuple id="398075">
<status> <status>
<basic>closed</basic> <basic>closed</basic>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--tuLLl3lDyPZX0GMr2YOo-- --tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU --l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@example.org> Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature Content-Type: application/pkcs7-signature
[PKCS #7 signature here] [PKCS #7 signature here]
--l3WMZaaL8NpQWGnQ4mlU-- --l3WMZaaL8NpQWGnQ4mlU--
12. The Local RLS completes the NOTIFY transaction. 12. The Local RLS completes the NOTIFY transaction.
Local RLS -> RLS in example.org Local RLS -> RLS in stockholm.example.org
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI Via: SIP/2.0/TCP pres.stockholm.example.org;
From: <sip:adam-friends@example.org>;tag=JenZ40P3 branch=z9hG4bKmGL1nyZfQI
To: <sip:pres.example.com>;tag=a12eztNf From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
Call-ID: kBq5XhtZLN@pres.example.com To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY CSeq: 294444656 NOTIFY
Contact: <sip:pres.example.com> Contact: <sip:pres.vancouver.example.com>
Content-Length: 0 Content-Length: 0
13. At this point, the Local RLS decides it has collected enough 13. At this point, the Local RLS decides it has collected enough
additional information to warrant sending a new notification to additional information to warrant sending a new notification to
the user. Although sending a full notification would be the user. Although sending a full notification would be
perfectly acceptable, the RLS decides to send a partial perfectly acceptable, the RLS decides to send a partial
notification instead. The RLMI document contains only notification instead. The RLMI document contains only
information for the updated resources, as indicated by setting information for the updated resources, as indicated by setting
the "fullState" parameter to "false". To avoid corrupting the the "fullState" parameter to "false". To avoid corrupting the
S/MIME signature on the data received from the RLS in S/MIME signature on the data received from the RLS in
example.org, the local RLS copies the entire multipart/signed stockholm.example.org, the local RLS copies the entire
body as-is into the notification that it sends. multipart/signed body as-is into the notification that it sends.
Local RLS -> Terminal Local RLS -> Terminal
NOTIFY sip:terminal.example.com SIP/2.0 NOTIFY sip:terminal.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bK4EPlfSFQK1
Max-Forwards: 70 Max-Forwards: 70
From: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@example.com>;tag=ie4hbb8t To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY CSeq: 997935769 NOTIFY
Contact: <sip:pres.example.com> Contact: <sip:pres.vancouver.example.com>
Event: presence Event: presence
Subscription-State: active;expires=7200 Subscription-State: active;expires=7200
Require: eventlist Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml"; Content-Type: multipart/related;type="application/rlmi+xml";
start="<2BEI83@pres.example.com>";boundary="TfZxoxgAvLqgj4wRWPDL" start="<2BEI83@pres.vancouver.example.com>";
boundary="TfZxoxgAvLqgj4wRWPDL"
Content-Length: 2862 Content-Length: 2862
--TfZxoxgAvLqgj4wRWPDL --TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <2BEI83@pres.example.com> Content-ID: <2BEI83@pres.vancouver.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8" Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" <list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@pres.example.com" version="2" uri="sip:adam-friends@pres.vancouver.example.com" version="2"
fullState="false"> fullState="false">
<name language="en">Buddy List at COM</name> <name language="en">Buddy List at COM</name>
<name language="de">Liste der Freunde an COM</name> <name language="de">Liste der Freunde an COM</name>
<resource uri="sip:ed@example.net"> <resource uri="sip:ed@dallas.example.net">
<name>Ed at NET</name> <name>Ed at NET</name>
<instance id="sdlkmeopdf" state="pending"/> <instance id="sdlkmeopdf" state="pending"/>
</resource> </resource>
<resource uri="sip:adam-friends@example.org"> <resource uri="sip:adam-friends@stockholm.example.org">
<name language="en">My Friends at ORG</name> <name language="en">My Friends at ORG</name>
<name language="de">Meine Freunde an ORG</name> <name language="de">Meine Freunde an ORG</name>
<instance id="cmpqweitlp" state="active" <instance id="cmpqweitlp" state="active"
cid="1KQhyE@pres.example.com"/> cid="1KQhyE@pres.vancouver.example.com"/>
</resource> </resource>
</list> </list>
--TfZxoxgAvLqgj4wRWPDL --TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <1KQhyE@pres.example.com> Content-ID: <1KQhyE@pres.vancouver.example.com>
Content-Type: multipart/signed; Content-Type: multipart/signed;
protocol="application/pkcs7-signature"; protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
--l3WMZaaL8NpQWGnQ4mlU --l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@example.org> Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml"; Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@example.org>";boundary="tuLLl3lDyPZX0GMr2YOo" start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo --tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <Cvjpeo@example.org> Content-ID: <Cvjpeo@stockholm.example.org>
Content-Type: application/rlmi+xml;charset="UTF-8" Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" <list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@example.org" version="1" uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true"> fullState="true">
<name language="en">Buddy List at ORG</name> <name language="en">Buddy List at ORG</name>
<name language="de">Liste der Freunde an ORG</name> <name language="de">Liste der Freunde an ORG</name>
<resource uri="sip:joe@example.org"> <resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name> <name>Joe Thomas</name>
<instance id="1" state="active" cid="mrEakg@example.org"/> <instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource> </resource>
<resource uri="sip:mark@example.org"> <resource uri="sip:mark@stockholm.example.org">
<name>Mark Edwards</name> <name>Mark Edwards</name>
<instance id="1" state="active" cid="KKMDmv@example.org"/> <instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource> </resource>
</list> </list>
--tuLLl3lDyPZX0GMr2YOo --tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <mrEakg@example.org> Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/cpim-pidf+xml;charset="UTF-8" Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@example.org"> entity="sip:joe@stockholm.example.org">
<tuple id="7823a4"> <tuple id="7823a4">
<status> <status>
<basic>open</basic> <basic>open</basic>
</status> </status>
<contact priority="1.0">sip:joe@example.org</contact> <contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple> </tuple>
</presence> </presence>
--tuLLl3lDyPZX0GMr2YOo --tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@example.org> Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/cpim-pidf+xml;charset="UTF-8" Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@example.org"> entity="sip:mark@stockholm.example.org">
<tuple id="398075"> <tuple id="398075">
<status> <status>
<basic>closed</basic> <basic>closed</basic>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--tuLLl3lDyPZX0GMr2YOo-- --tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU --l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@example.org> Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature Content-Type: application/pkcs7-signature
[PKCS #7 signature here] [PKCS #7 signature here]
--l3WMZaaL8NpQWGnQ4mlU-- --l3WMZaaL8NpQWGnQ4mlU--
--TfZxoxgAvLqgj4wRWPDL-- --TfZxoxgAvLqgj4wRWPDL--
14. The terminal completes the NOTIFY transaction. 14. The terminal completes the NOTIFY transaction.
Terminal -> Local RLS Terminal -> Local RLS
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 Via: SIP/2.0/TCP pres.vancouver.example.com;
From: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq branch=z9hG4bK4EPlfSFQK1
To: <sip:adam@example.com>;tag=ie4hbb8t From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
Call-ID: cdB34qLToC@terminal.example.com To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY CSeq: 997935769 NOTIFY
Contact: <sip:terminal.example.com> Contact: <sip:terminal.vancouver.example.com>
Content-Length: 0 Content-Length: 0
7. Security Considerations 7. Security Considerations
Note that the mechanisms for obtaining state information for Note that the mechanisms for obtaining state information for
resources in a list are generally left to the RLS implementor. Some resources in a list are generally left to the RLS implementor. Some
of the security issues below are specific to the the circumstance of the security issues below are specific to the the circumstance
that a SIP back-end subscription is used for such a purpose. Non-SIP that a SIP back-end subscription is used for such a purpose. Non-SIP
mechanisms for obtaining state information of resources in a list mechanisms for obtaining state information of resources in a list
will typically have their own security issues associated with doing will typically have their own security issues associated with doing
so; however, exhaustively enumerating such access methods is not so; however, exhaustively enumerating such access methods is not
possible in this document. Implementors using such mechanisms must possible in this document. Implementors using such mechanisms must
analyze their chosen access methods for relevant security issues. analyze their chosen access methods for relevant security issues.
7.1 Authentication 7.1 Authentication
If back-end subscriptions are required to retrieve resource state If back-end subscriptions are required to retrieve resource state
information, the end user is no longer the direct subscriber to the information, the end user is no longer the direct subscriber to the
state of the resource. If the notifier for the resource demands end- state of the resource. This means that direct authentication of the
to-end authentication, the RLS will need to be provided appropriate user is no longer possible.
credentials to access those resources (e.g. shared secrets for
Digest authentication). This requires a certain level of trust
between the user and their RLS. This specification does not describe
any particular means of providing such credentials to the RLS (such
as uploading a shared secret). However, any such upload mechanism
MUST ensure privacy of the key data; using HTTPS [15] to fill out a
form is a reasonable method. Any upload mechanism MUST also seek the
explicit consent of the user before transferring any user secrets
used for authentication.
Open Issue: The IESG has requested that this specification define 7.1.1 RLS and Subscriber in the Same Domain
or cite a mandatory-to-implement mechanism for transfer of such
credentials.
If the notifier for the resource is using a transitive trust model to It is expected that the most common deployment of RLSes entails the
validate the subscriber, then this works well with the RLS concept subscribers to the RLS being in the same domain as the RLS. When
and back-end subscriptions. The RLS would authenticate the this is the case, the RLS then has the ability to act as an
subscriber, and then MAY use the SIP extensions for authenticated authenication service. The role of authentication service is defined
identity assertion [8] to provide an authenticated identity to the in "Enhancements for Authenticated Identity Management in the Session
notifiers for the resource. 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 which 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 them
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 which are in a
different domain than the subscriber on whose behalf they are
creating back-end susbcriptions SHOULD subscribe to the resources
using their own identity. By doing so, the RLS will generally obtain
only the resource information which is made publicly available.
Absent such general solutions, implemenations of subscriber user
agents MAY attempt direct subscriptions to resources in the resouce
list when subscribing to an RLS outside of their domain (either
directly or by way of another resource list subscription). The
resouces to be subscribed to will be those indicated in the 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 which choose to perform such direct subscriptions
SHOULD use the data retrieved directly to the exclusion of any
information about the resource obtained via the list subscription.
7.2 Risks of Improper Aggregation 7.2 Risks of Improper Aggregation
A resource list server typically serves information to multiple A resource list server typically serves information to multiple
subscribers at once. In many cases, resources may be present in subscribers at once. In many cases, resources may be present in
several lists; additionally, it is quite possible that resource list several lists; additionally, it is quite possible that resource list
servers will have two users subscribe to the same list. servers will have two users subscribe to the same list.
In these cases, misguided RLS implementations may attempt to minimize In these cases, misguided RLS implementations may attempt to minimize
network load by maintaining only one back-end subscription to a network load by maintaining only one back-end subscription to a
skipping to change at page 37, line 8 skipping to change at page 40, line 8
Author/Change Controller: The specification of this MIME type is a Author/Change Controller: The specification of this MIME type is a
work product of the SIMPLE working group, and was authored by work product of the SIMPLE working group, and was authored by
Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has
change control over its specification. change control over its specification.
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=utf-8"/> content="text/html;charset=utf-8"/>
<title>Namespace for SIP Event Resource List <title>Namespace for SIP Event Resource List
Meta-Information</title> Meta-Information</title>
</head> </head>
<body> <body>
<h1>Namespace for SIP Event Resource List <h1>Namespace for SIP Event Resource List
Meta-Information</h1> Meta-Information</h1>
skipping to change at page 40, line 5 skipping to change at page 42, line 28
[4] Levinson, E., "The MIME Multipart/Related Content-type", RFC [4] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998. 2387, August 1998.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC [6] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995. 1766, March 1995.
Non-Normative References [7] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", draft-
ietf-sip-identity-03 (work in progress), September 2004.
[7] Rosenberg, J., "A Presence Event Package for the Session Informative References
Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Peterson, J., "Enhancements for Authenticated Identity [8] Rosenberg, J., "A Presence Event Package for the Session
Management in the Session Initiation Protocol (SIP)", draft- Initiation Protocol (SIP)", RFC 3856, August 2004.
ietf-sip-identity-03 (work in progress), September 2004.
[9] Olson, S., "A Mechanism for Content Indirection in Session [9] Olson, S., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", draft-ietf-sip-content- Initiation Protocol (SIP) Messages", draft-ietf-sip-content-
indirect-mech-04 (work in progress), July 2004. indirect-mech-04 (work in progress), July 2004.
[10] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, [10] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004. August 2004.
[11] Levinson, E., "SGML Media Types", RFC 1874, December 1995. [11] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
skipping to change at page 41, line 4 skipping to change at page 43, line 39
[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Authors' Addresses Authors' Addresses
Adam Roach Adam Roach
Estacado Systems Estacado Systems
US US
EMail: adam@estacado.net EMail: adam@estacado.net
Ben Campbell Ben Campbell
Estacado Systems Estacado Systems
US US
EMail: ben@estacado.net EMail: ben@estacado.net
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054-2711 Parsippany, NJ 07054-2711
US US
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@cisco.com
Appendix A. Changes Appendix A. Changes
Note that this section will be removed before publication as an RFC. Note that this section will be removed before publication as an RFC.
A.1 Changes since -05 A.1 Changes since -06
o Substantial reworking of section on authentication; now requires
SIP Identity extension for RLSes that use SIP back-end
subscriptions. Examples updated to reflect this change.
o Fixed CPIM mime type everywhere.
A.2 Changes since -05
o Added open issue regarding transfer of user secrets to the RLS. o Added open issue regarding transfer of user secrets to the RLS.
o Removed all references to multipart/encrypted. Replaced with o Removed all references to multipart/encrypted. Replaced with
application/pkcs7-mime, to align with RFC 3261 and RFC 3851. application/pkcs7-mime, to align with RFC 3261 and RFC 3851.
o Formally restricted state attribute in schema to reflect the three o Formally restricted state attribute in schema to reflect the three
valid values outlined in the text valid values outlined in the text
o Changed "name" from an attribute to an element for both <list> and o Changed "name" from an attribute to an element for both <list> and
<resource> elements. This allows for multiple names to be <resource> elements. This allows for multiple names to be
present, each with an appropriate language tag. present, each with an appropriate language tag.
o Minor editorial updates. o Minor editorial updates.
A.2 Changes since -04 A.3 Changes since -04
o Removed references to P-Asserted-Identity mechanism. o Removed references to P-Asserted-Identity mechanism.
o Removed some leftover cruft from the section on constructing o Removed some leftover cruft from the section on constructing
coherent resource state. coherent resource state.
A.3 Changes since -03 A.4 Changes since -03
o Changed Content-Encoding in examples from 8bit to binary. o Changed Content-Encoding in examples from 8bit to binary.
o Adjusted formatting to comply with RFC 2223. o Adjusted formatting to comply with RFC 2223.
A.4 Changes since -02 A.5 Changes since -02
o Added discussion in security section about infinite loops. o Added discussion in security section about infinite loops.
o Fixed several places where the document said "one or more" instead o Fixed several places where the document said "one or more" instead
of "zero or more", when referring to the number of resources that of "zero or more", when referring to the number of resources that
can appear in a list and the number of instances that can appear can appear in a list and the number of instances that can appear
in a resource. in a resource.
o Tiny editorial cleanup (mostly spelling gaffes). o Tiny editorial cleanup (mostly spelling gaffes).
A.5 Changes since -01 A.6 Changes since -01
o Several editorial updates. Change "collection" to "list" o Several editorial updates. Change "collection" to "list"
everywhere. everywhere.
o Added terminology section. o Added terminology section.
o Added restriction that cid attributes can only point to documents o Added restriction that cid attributes can only point to documents
at the same level as the RLMI document in which they appear. at the same level as the RLMI document in which they appear.
o Clarified description of how to construct resource state by o Clarified description of how to construct resource state by
splitting discussion of full state notifications apart from splitting discussion of full state notifications apart from
discussion of partial-state notifications. discussion of partial-state notifications.
A.6 Changes since -00 A.7 Changes since -00
o Removed text in several places which went into detail about o Removed text in several places which went into detail about
specific implementations which used SIP SUB/NOT for back-end specific implementations which used SIP SUB/NOT for back-end
subscriptions. Some of this text will probably be published later subscriptions. Some of this text will probably be published later
as part of an implementors' guide. as part of an implementors' guide.
o Removed specific semantics for "Event" header field parameters and o Removed specific semantics for "Event" header field parameters and
SUBSCRIBE bodies. These will be defined on a per-package basis, SUBSCRIBE bodies. These will be defined on a per-package basis,
probably by the filtering work. probably by the filtering work.
 End of changes. 144 change blocks. 
276 lines changed or deleted 390 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/