A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists
RFC 4662
Network Working Group A. B. Roach
Request for Comments: 4662 B. Campbell
Category: Standards Track Estacado Systems
J. Rosenberg
Cisco Systems
August 2006
A Session Initiation Protocol (SIP) Event Notification Extension
for Resource Lists
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document presents an extension to the Session Initiation
Protocol (SIP)-Specific Event Notification mechanism for subscribing
to a homogeneous list of resources. Instead of sending a SUBSCRIBE
for each resource individually, the subscriber can subscribe to an
entire list and then receive notifications when the state of any of
the resources in the list changes.
Roach, et al. Standards Track [Page 1]
RFC 4662 SIP Event Lists August 2006
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of Operation ...........................................4
4. Operation of List Subscriptions .................................5
4.1. Negotiation of Support for Resource Lists ..................6
4.2. Subscription Duration ......................................7
4.3. NOTIFY Bodies ..............................................7
4.4. RLS Processing of SUBSCRIBE Requests .......................7
4.5. RLS Generation of NOTIFY Requests ..........................7
4.6. Subscriber Processing of NOTIFY Requests ...................9
4.7. Handling of Forked Requests ...............................10
4.8. Rate of Notifications .....................................10
5. Using multipart/related to Convey Aggregate State ..............10
5.1. XML Syntax ................................................11
5.2. List Attributes ...........................................13
5.3. Resource Attributes .......................................14
5.4. Name Attributes ...........................................14
5.5. Instance Attributes .......................................14
5.6. Constructing Coherent Resource State ......................16
5.6.1. Processing Full State Notifications ................17
5.6.2. Processing Partial State Notifications .............17
6. Example ........................................................18
7. Security Considerations ........................................31
7.1. Authentication ............................................31
7.1.1. RLS and Subscriber in the Same Domain ..............31
7.1.2. RLS and Subscriber in Different Domains ............32
7.2. Risks of Improper Aggregation .............................33
7.3. Signing and Sealing .......................................33
7.4. Infinite Loops ............................................34
8. IANA Considerations ............................................34
8.1. New SIP Option Tag: eventlist .............................34
8.2. New MIME type for Resource List Meta-Information ..........34
8.3. URN Sub-Namespace .........................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
Roach, et al. Standards Track [Page 2]
RFC 4662 SIP Event Lists August 2006
1. Introduction
The SIP-specific event notification mechanism [2] allows a user (the
subscriber) to request to be notified of changes in the state of a
particular resource. This is accomplished by the subscriber
generating a SUBSCRIBE request for the resource, which is processed
by a notifier that represents the resource.
In many cases, a subscriber has a list of resources they are
interested in. Without some aggregating mechanism, this will require
the subscriber to generate a SUBSCRIBE request for each resource
about which they want information. For environments in which
Show full document text