summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3856.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3856.txt')
-rw-r--r--doc/rfc/rfc3856.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc3856.txt b/doc/rfc/rfc3856.txt
new file mode 100644
index 0000000..86a4457
--- /dev/null
+++ b/doc/rfc/rfc3856.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group J. Rosenberg
+Request for Comments: 3856 dynamicsoft
+Category: Standards Track August 2004
+
+
+ A Presence Event Package for the Session Initiation Protocol (SIP)
+
+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 (2004).
+
+Abstract
+
+ This document describes the usage of the Session Initiation Protocol
+ (SIP) for subscriptions and notifications of presence. Presence is
+ defined as the willingness and ability of a user to communicate with
+ other users on the network. Historically, presence has been limited
+ to "on-line" and "off-line" indicators; the notion of presence here
+ is broader. Subscriptions and notifications of presence are
+ supported by defining an event package within the general SIP event
+ notification framework. This protocol is also compliant with the
+ Common Presence Profile (CPP) framework.
+
+Table of Contents
+
+ 1. Introduction ................................................ 2
+ 2. Terminology ................................................. 3
+ 3. Definitions ................................................. 3
+ 4. Overview of Operation ....................................... 4
+ 5. Usage of Presence URIs ...................................... 6
+ 6. Presence Event Package ...................................... 7
+ 6.1. Package Name .......................................... 8
+ 6.2. Event Package Parameters .............................. 8
+ 6.3. SUBSCRIBE Bodies ...................................... 8
+ 6.4. Subscription Duration ................................. 9
+ 6.5. NOTIFY Bodies ......................................... 9
+ 6.6. Notifier Processing of SUBSCRIBE Requests ............. 9
+ 6.6.1. Authentication ................................. 10
+ 6.6.2. Authorization .................................. 10
+ 6.7. Notifier Generation of NOTIFY Requests ................ 11
+
+
+
+Rosenberg Standards Track [Page 1]
+
+RFC 3856 SIP Presence August 2004
+
+
+ 6.8. Subscriber Processing of NOTIFY Requests .............. 13
+ 6.9. Handling of Forked Requests ........................... 13
+ 6.10. Rate of Notifications ................................. 14
+ 6.11. State Agents .......................................... 14
+ 6.11.1. Aggregation, Authentication, and Authorization. 14
+ 6.11.2. Migration ..................................... 15
+ 7. Learning Presence State ..................................... 16
+ 7.1. Co-location ........................................... 16
+ 7.2. REGISTER .............................................. 16
+ 7.3. Uploading Presence Documents .......................... 17
+ 8. Example Message Flow ........................................ 17
+ 9. Security Considerations ..................................... 20
+ 9.1. Confidentiality ....................................... 20
+ 9.2. Message Integrity and Authenticity .................... 21
+ 9.3. Outbound Authentication ............................... 22
+ 9.4. Replay Prevention ..................................... 22
+ 9.5. Denial of Service Attacks Against Third Parties ....... 22
+ 9.6. Denial Of Service Attacks Against Servers ............. 23
+ 10. IANA Considerations ......................................... 23
+ 11. Contributors ................................................ 24
+ 12. Acknowledgements ............................................ 25
+ 13. Normative References ........................................ 25
+ 14. Informative References ...................................... 26
+ 15. Author's Address ............................................ 26
+ 16. Full Copyright Statement .................................... 27
+
+1. Introduction
+
+ Presence, also known as presence information, conveys the ability and
+ willingness of a user to communicate across a set of devices. RFC
+ 2778 [10] defines a model and terminology for describing systems that
+ provide presence information. In that model, a presence service is a
+ system that accepts, stores, and distributes presence information to
+ interested parties, called watchers. A presence protocol is a
+ protocol for providing a presence service over the Internet or any IP
+ network.
+
+ This document proposes the usage of the Session Initiation Protocol
+ (SIP) [1] as a presence protocol. This is accomplished through a
+ concrete instantiation of the general event notification framework
+ defined for SIP [2], and as such, makes use of the SUBSCRIBE and
+ NOTIFY methods defined there. Specifically, this document defines an
+ event package, as described in RFC 3265 [2]. SIP is particularly
+ well suited as a presence protocol. SIP location services already
+ contain presence information, in the form of registrations.
+ Furthermore, SIP networks are capable of routing requests from any
+ user on the network to the server that holds the registration state
+ for a user. As this state is a key component of user presence, those
+
+
+
+Rosenberg Standards Track [Page 2]
+
+RFC 3856 SIP Presence August 2004
+
+
+ SIP networks can allow SUBSCRIBE requests to be routed to the same
+ server. This means that SIP networks can be reused to establish
+ global connectivity for presence subscriptions and notifications.
+
+ This event package is based on the concept of a presence agent, which
+ is a new logical entity that is capable of accepting subscriptions,
+ storing subscription state, and generating notifications when there
+ are changes in presence. The entity is defined as a logical one,
+ since it is generally co-resident with another entity.
+
+ This event package is also compliant with the Common Presence Profile
+ (CPP) framework that has been defined in [3]. This allows SIP for
+ presence to easily interwork with other presence systems compliant to
+ CPP.
+
+2. Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
+ indicate requirement levels for compliant implementations.
+
+3. Definitions
+
+ This document uses the terms as defined in RFC 2778 [10].
+ Additionally, the following terms are defined and/or additionally
+ clarified:
+
+ Presence User Agent (PUA): A Presence User Agent manipulates
+ presence information for a presentity. This manipulation can
+ be the side effect of some other action (such as sending a SIP
+ REGISTER request to add a new Contact) or can be done
+ explicitly through the publication of presence documents. We
+ explicitly allow multiple PUAs per presentity. This means that
+ a user can have many devices (such as a cell phone and Personal
+ Digital Assistant (PDA)), each of which is independently
+ generating a component of the overall presence information for
+ a presentity. PUAs push data into the presence system, but are
+ outside of it, in that they do not receive SUBSCRIBE messages
+ or send NOTIFY messages.
+
+ Presence Agent (PA): A presence agent is a SIP user agent which is
+ capable of receiving SUBSCRIBE requests, responding to them,
+ and generating notifications of changes in presence state. A
+ presence agent must have knowledge of the presence state of a
+ presentity. This means that it must have access to presence
+ data manipulated by PUAs for the presentity. One way to do
+ this is by co-locating the PA with the proxy/registrar.
+
+
+
+Rosenberg Standards Track [Page 3]
+
+RFC 3856 SIP Presence August 2004
+
+
+ Another way is to co-locate it with the presence user agent of
+ the presentity. However, these are not the only ways, and this
+ specification makes no recommendations about where the PA
+ function should be located. A PA is always addressable with a
+ SIP URI that uniquely identifies the presentity (i.e.,
+ sip:joe@example.com). There can be multiple PAs for a
+ particular presentity, each of which handles some subset of the
+ total subscriptions currently active for the presentity. A PA
+ is also a notifier (defined in RFC 3265 [2]) that supports the
+ presence event package.
+
+ Presence Server: A presence server is a physical entity that can
+ act as either a presence agent or as a proxy server for
+ SUBSCRIBE requests. When acting as a PA, it is aware of the
+ presence information of the presentity through some protocol
+ means. When acting as a proxy, the SUBSCRIBE requests are
+ proxied to another entity that may act as a PA.
+
+ Edge Presence Server: An edge presence server is a presence agent
+ that is co-located with a PUA. It is aware of the presence
+ information of the presentity because it is co-located with the
+ entity that manipulates this presence information.
+
+4. Overview of Operation
+
+ In this section, we present an overview of the operation of this
+ event package. The overview describes behavior that is documented in
+ part here, in part within the SIP event framework [2], and in part in
+ the SIP specification [1], in order to provide clarity on this
+ package for readers only casually familiar with those specifications.
+ However, the detailed semantics of this package require the reader to
+ be familiar with SIP events and the SIP specification itself.
+
+ When an entity, the subscriber, wishes to learn about presence
+ information from some user, it creates a SUBSCRIBE request. This
+ request identifies the desired presentity in the Request-URI, using a
+ SIP URI, SIPS URI [1] or a presence (pres) URI [3]. The SUBSCRIBE
+ request is carried along SIP proxies as any other SIP request would
+ be. In most cases, it eventually arrives at a presence server, which
+ can either generate a response to the request (in which case it acts
+ as the presence agent for the presentity), or proxy it on to an edge
+ presence server. If the edge presence server handles the
+ subscription, it is acting as the presence agent for the presentity.
+ The decision at a presence server about whether to proxy or terminate
+ the SUBSCRIBE is a local matter; however, we describe one way to
+ effect such a configuration, using REGISTER.
+
+
+
+
+
+Rosenberg Standards Track [Page 4]
+
+RFC 3856 SIP Presence August 2004
+
+
+ The presence agent (whether in the presence server or edge presence
+ server) first authenticates the subscription, then authorizes it.
+ The means for authorization are outside the scope of this protocol,
+ and we expect that many mechanisms will be used. If authorized, a
+ 200 OK response is returned. If authorization could not be obtained
+ at this time, the subscription is considered "pending", and a 202
+ response is returned. In both cases, the PA sends an immediate
+ NOTIFY message containing the state of the presentity and of the
+ subscription. The presentity state may be bogus in the case of a
+ pending subscription, indicating offline no matter what the actual
+ state of the presentity, for example. This is to protect the privacy
+ of the presentity, who may not want to reveal that they have not
+ provided authorization for the subscriber. As the state of the
+ presentity changes, the PA generates NOTIFYs containing those state
+ changes to all subscribers with authorized subscriptions. Changes in
+ the state of the subscription itself can also trigger NOTIFY
+ requests; that state is carried in the Subscription-State header
+ field of the NOTIFY, and would typically indicate whether the
+ subscription is active or pending.
+
+ The SUBSCRIBE message establishes a "dialog" with the presence agent.
+ A dialog is defined in RFC 3261 [1], and it represents the SIP state
+ between a pair of entities to facilitate peer-to-peer message
+ exchanges. This state includes the sequence numbers for messages in
+ both directions (SUBSCRIBE from the subscriber, NOTIFY from the
+ presence agent), in addition to a route set and remote target URI.
+ The route set is a list of SIP (or SIPS) URIs which identify SIP
+ proxy servers that are to be visited along the path of SUBSCRIBE
+ refreshes or NOTIFY requests. The remote target URI is the SIP or
+ SIPS URI that identifies the target of the message - the subscriber,
+ in the case of NOTIFY, or the presence agent, in the case of a
+ SUBSCRIBE refresh.
+
+ SIP provides a procedure called record-routing that allows for proxy
+ servers to request to be on the path of NOTIFY messages and SUBSCRIBE
+ refreshes. This is accomplished by inserting a URI into the
+ Record-Route header field in the initial SUBSCRIBE request.
+
+ The subscription persists for a duration that is negotiated as part
+ of the initial SUBSCRIBE. The subscriber will need to refresh the
+ subscription before its expiration, if they wish to retain the
+ subscription. This is accomplished by sending a SUBSCRIBE refresh
+ within the same dialog established by the initial SUBSCRIBE. This
+ SUBSCRIBE is nearly identical to the initial one, but contains a tag
+ in the To header field, a higher CSeq header field value, and
+ possibly a set of Route header field values that identify the path of
+ proxies the request is to take.
+
+
+
+
+Rosenberg Standards Track [Page 5]
+
+RFC 3856 SIP Presence August 2004
+
+
+ The subscriber can terminate the subscription by sending a SUBSCRIBE,
+ within the dialog, with an Expires header field (which indicates
+ duration of the subscription) value of zero. This causes an
+ immediate termination of the subscription. A NOTIFY request is then
+ generated by the presence agent with the most recent state. In fact,
+ behavior of the presence agent for handling a SUBSCRIBE request with
+ Expires of zero is no different than for any other expiration value;
+ pending or authorized SUBSCRIBE requests result in a triggered NOTIFY
+ with the current presentity and subscription state.
+
+ The presence agent can terminate the subscription at any time. To do
+ so, it sends a NOTIFY request with a Subscription-State header field
+ indicating that the subscription has been terminated. A reason
+ parameter can be supplied which provides the reason.
+
+ It is also possible to fetch the current presence state, resulting in
+ a one-time notification containing the current state. This is
+ accomplished by sending a SUBSCRIBE request with an immediate
+ expiration.
+
+5. Usage of Presence URIs
+
+ A presentity is identified in the most general way through a presence
+ URI [3], which is of the form pres:user@domain. These URIs are
+ resolved to protocol specific URIs, such as the SIP or SIPS URI,
+ through domain-specific mapping policies maintained on a server.
+
+ It is very possible that a user will have both a SIP (and/or SIPS)
+ URI and a pres URI to identify both themself and other users. This
+ leads to questions about how these URI relate and which are to be
+ used.
+
+ In some instances, a user starts with one URI format, such as the
+ pres URI, and learns a URI in a different format through some
+ protocol means. As an example, a SUBSCRIBE request sent to a pres
+ URI will result in learning a SIP or SIPS URI for the presentity from
+ the Contact header field of the 200 OK to the SUBSCRIBE request. As
+ another example, a DNS mechanism might be defined that would allow
+ lookup of a pres URI to obtain a SIP or SIPS URI. In cases where one
+ URI is learned from another through protocol means, those means will
+ often provide some kind of scoping that limit the lifetime of the
+ learned URI. DNS, for example, provides a TTL which would limit the
+ scope of the URI. These scopes are very useful to avoid stale or
+ conflicting URIs for identifying the same resource. To ensure that a
+ user can always determine whether a learned URI is still valid, it is
+ RECOMMENDED that systems which provide lookup services for presence
+ URIs have some kind of scoping mechanism.
+
+
+
+
+Rosenberg Standards Track [Page 6]
+
+RFC 3856 SIP Presence August 2004
+
+
+ If a subscriber is only aware of the protocol-independent pres URI
+ for a presentity, it follows the procedures defined in [5]. These
+ procedures will result in the placement of the pres URI in the
+ Request-URI of the SIP request, followed by the usage of the DNS
+ procedures defined in [5] to determine the host to send the SIP
+ request to. Of course, a local outbound proxy may alternatively be
+ used, as specified in RFC 3261 [1]. If the subscriber is aware of
+ both the protocol-independent pres URI and the SIP or SIPS URI for
+ the same presentity, and both are valid (as discussed above) it
+ SHOULD use the pres URI format. Of course, if the subscriber only
+ knows the SIP URI for the presentity, that URI is used, and standard
+ RFC 3261 processing will occur. When the pres URI is used, any
+ proxies along the path of the SUBSCRIBE request which do not
+ understand the URI scheme will reject the request. As such, it is
+ expected that many systems will be initially deployed that only
+ provide users with a SIP URI.
+
+ SUBSCRIBE messages also contain logical identifiers that define the
+ originator and recipient of the subscription (the To and From header
+ fields). These headers can take either a pres or SIP URI. When the
+ subscriber is aware of both a pres and SIP URI for its own identity,
+ it SHOULD use the pres URI in the From header field. Similarly, when
+ the subscriber is aware of both a pres and a SIP URI for the desired
+ presentity, it SHOULD use the pres URI in the To header field.
+
+ The usage of the pres URI instead of the SIP URI within the SIP
+ message supports interoperability through gateways to other
+ CPP-compliant systems. It provides a protocol-independent form of
+ identification which can be passed between systems. Without such an
+ identity, gateways would be forced to map SIP URIs into the
+ addressing format of other protocols. Generally, this is done by
+ converting the SIP URI to the form <foreign-protocol-scheme>:<encoded
+ SIP URI>@<gateway>. This is commonly done in email systems, and has
+ many known problems. The usage of the pres URI is a SHOULD, and not
+ a MUST, to allow for cases where it is known that there are no
+ gateways present, or where the usage of the pres URI will cause
+ interoperability problems with SIP components that do not support the
+ pres URI.
+
+ The Contact, Record-Route and Route fields do not identify logical
+ entities, but rather concrete ones used for SIP messaging. SIP [1]
+ specifies rules for their construction.
+
+6. Presence Event Package
+
+ The SIP event framework [2] defines a SIP extension for subscribing
+ to, and receiving notifications of, events. It leaves the definition
+ of many aspects of these events to concrete extensions, known as
+
+
+
+Rosenberg Standards Track [Page 7]
+
+RFC 3856 SIP Presence August 2004
+
+
+ event packages. This document qualifies as an event package. This
+ section fills in the information required for all event packages by
+ RFC 3265 [2].
+
+6.1. Package Name
+
+ The name of this package is "presence". As specified in RFC 3265
+ [2], this value appears in the Event header field present in
+ SUBSCRIBE and NOTIFY requests.
+
+ Example:
+
+ Event: presence
+
+6.2. Event Package Parameters
+
+ The SIP event framework allows event packages to define additional
+ parameters carried in the Event header field. This package,
+ presence, does not define any additional parameters.
+
+6.3. SUBSCRIBE Bodies
+
+ A SUBSCRIBE request MAY contain a body. The purpose of the body
+ depends on its type. Subscriptions will normally not contain bodies.
+
+ The Request-URI, which identifies the presentity, combined with the
+ event package name, is sufficient for presence.
+
+ One type of body that can be included in a SUBSCRIBE request is a
+ filter document. These filters request that only certain presence
+ events generate notifications, or would ask for a restriction on the
+ set of data returned in NOTIFY requests. For example, a presence
+ filter might specify that the notifications should only be generated
+ when the status of the user's instant inbox [10] changes. It might
+ also say that the content of these notifications should only contain
+ the status of the instant inbox. Filter documents are not specified
+ in this document, and at the time of writing, are expected to be the
+ subject of future standardization activity.
+
+ Honoring of these filters is at the policy discretion of the PA.
+
+ If the SUBSCRIBE request does not contain a filter, this tells the PA
+ that no filter is to be applied. The PA SHOULD send NOTIFY requests
+ at the discretion of its own policy.
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 8]
+
+RFC 3856 SIP Presence August 2004
+
+
+6.4. Subscription Duration
+
+ User presence changes as a result of many events. Some examples are:
+
+ o Turning on and off of a cell phone
+
+ o Modifying the registration from a softphone
+
+ o Changing the status on an instant messaging tool
+
+ These events are usually triggered by human intervention, and occur
+ with a frequency on the order of seconds to hours. As such,
+ subscriptions should have an expiration in the middle of this range,
+ which is roughly one hour. Therefore, the default expiration time
+ for subscriptions within this package is 3600 seconds. As per RFC
+ 3265 [2], the subscriber MAY specify an alternate expiration in the
+ Expires header field.
+
+6.5. NOTIFY Bodies
+
+ As described in RFC 3265 [2], the NOTIFY message will contain bodies
+ that describe the state of the subscribed resource. This body is in
+ a format listed in the Accept header field of the SUBSCRIBE, or a
+ package-specific default if the Accept header field was omitted from
+ the SUBSCRIBE.
+
+ In this event package, the body of the notification contains a
+ presence document. This document describes the presence of the
+ presentity that was subscribed to. All subscribers and notifiers
+ MUST support the "application/pidf+xml" presence data format
+ described in [6]. The subscribe request MAY contain an Accept header
+ field. If no such header field is present, it has a default value of
+ "application/pidf+xml". If the header field is present, it MUST
+ include "application/pidf+xml", and MAY include any other types
+ capable of representing user presence.
+
+6.6. Notifier Processing of SUBSCRIBE Requests
+
+ Based on the proxy routing procedures defined in the SIP
+ specification, the SUBSCRIBE request will arrive at a presence agent
+ (PA). This subsection defines package-specific processing at the PA
+ of a SUBSCRIBE request. General processing rules for requests are
+ covered in Section 8.2 of RFC 3261 [1], in addition to general
+ SUBSCRIBE processing in RFC 3265 [2].
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 9]
+
+RFC 3856 SIP Presence August 2004
+
+
+ User presence is highly sensitive information. Because the
+ implications of divulging presence information can be severe, strong
+ requirements are imposed on the PA regarding subscription processing,
+ especially related to authentication and authorization.
+
+6.6.1. Authentication
+
+ A presence agent MUST authenticate all subscription requests. This
+ authentication can be done using any of the mechanisms defined in RFC
+ 3261 [1]. Note that digest is mandatory to implement, as specified
+ in RFC 3261.
+
+ In single-domain systems, where the subscribers all have shared
+ secrets with the PA, the combination of digest authentication over
+ Transport Layer Security (TLS) [7] provides a secure and workable
+ solution for authentication. This use case is described in Section
+ 26.3.2.1 of RFC 3261 [1].
+
+ In inter-domain scenarios, establishing an authenticated identity of
+ the subscriber is harder. It is anticipated that authentication will
+ often be established through transitive trust. SIP mechanisms for
+ network asserted identity can be applied to establish the identity of
+ the subscriber [11].
+
+ A presentity MAY choose to represent itself with a SIPS URI. By
+ "represent itself", it means that the user represented by the
+ presentity hands out, on business cards, web pages, and so on, a SIPS
+ URI for their presentity. The semantics associated with this URI, as
+ described in RFC 3261 [1], require TLS usage on each hop between the
+ subscriber and the server in the domain of the URI. This provides
+ additional assurances (but no absolute guarantees) that identity has
+ been verified at each hop.
+
+ Another mechanism for authentication is S/MIME. Its usage with SIP
+ is described fully in RFC 3261 [1]. It provides an end-to-end
+ authentication mechanism that can be used for a PA to establish the
+ identity of the subscriber.
+
+6.6.2. Authorization
+
+ Once authenticated, the PA makes an authorization decision. A PA
+ MUST NOT accept a subscription unless authorization has been provided
+ by the presentity. The means by which authorization are provided are
+ outside the scope of this document. Authorization may have been
+ provided ahead of time through access lists, perhaps specified in a
+ web page. Authorization may have been provided by means of uploading
+ of some kind of standardized access control list document. Back end
+ authorization servers, such as a DIAMETER [12] server, can also be
+
+
+
+Rosenberg Standards Track [Page 10]
+
+RFC 3856 SIP Presence August 2004
+
+
+ used. It is also useful to be able to query the user for
+ authorization following the receipt of a subscription request for
+ which no authorization information has been provided. The
+ "watcherinfo" event template package for SIP [8] defines a means by
+ which a presentity can become aware that a user has attempted to
+ subscribe to it, so that it can then provide an authorization
+ decision.
+
+ Authorization decisions can be very complex. Ultimately, all
+ authorization decisions can be mapped into one of three states:
+ rejected, successful, and pending. Any subscription for which the
+ client is authorized to receive information about some subset of
+ presence state at some points in time is a successful subscription.
+ Any subscription for which the client will never receive any
+ information about any subset of the presence state is a rejected
+ subscription. Any subscription for which it is not yet known whether
+ it is successful or rejected is pending. Generally, a pending
+ subscription occurs when the server cannot obtain authorization at
+ the time of the subscription, but may be able to do so at a later
+ time, perhaps when the presentity becomes available.
+
+ The appropriate response codes for conveying a successful, rejected,
+ or pending subscription (200, 403 or 603, and 202, respectively) are
+ described in RFC 3265 [2].
+
+ If the resource is not in a meaningful state, RFC 3265 [2] allows the
+ body of the initial NOTIFY to be empty. In the case of presence,
+ that NOTIFY MAY contain a presence document. This document would
+ indicate whatever presence state the subscriber has been authorized
+ to see; it is interpreted by the subscriber as the current presence
+ state of the presentity. For pending subscriptions, the state of the
+ presentity SHOULD include some kind of textual note that indicates a
+ pending status.
+
+ Polite blocking, as described in [13], is possible by generating a
+ 200 OK to the subscription even though it has been rejected (or
+ marked pending). Of course, an immediate NOTIFY will still be sent.
+ The contents of the presence document in such a NOTIFY are at the
+ discretion of the implementor, but SHOULD be constructed in such a
+ way as to not reveal to the subscriber that their request has
+ actually been blocked. Typically, this is done by indicating
+ "offline" or equivalent status for a single contact address.
+
+6.7. Notifier Generation of NOTIFY Requests
+
+ RFC 3265 details the formatting and structure of NOTIFY messages.
+ However, packages are mandated to provide detailed information on
+ when to send a NOTIFY, how to compute the state of the resource, how
+
+
+
+Rosenberg Standards Track [Page 11]
+
+RFC 3856 SIP Presence August 2004
+
+
+ to generate neutral or fake state information, and whether state
+ information is complete or partial. This section describes those
+ details for the presence event package.
+
+ A PA MAY send a NOTIFY at any time. Typically, it will send one when
+ the state of the presentity changes. The NOTIFY request MAY contain
+ a body indicating the state of the presentity. The times at which
+ the NOTIFY is sent for a particular subscriber, and the contents of
+ the body within that notification, are subject to any rules specified
+ by the authorization policy that governs the subscription. This
+ protocol in no way limits the scope of such policies. As a baseline,
+ a reasonable policy is to generate notifications when the state of
+ any of the presence tuples changes. These notifications would
+ contain the complete and current presence state of the presentity as
+ known to the presence agent. Future extensions can be defined that
+ allow a subscriber to request that the notifications contain changes
+ in presence information only, rather than complete state.
+
+ In the case of a pending subscription, when final authorization is
+ determined, a NOTIFY can be sent. If the result of the authorization
+ decision was success, a NOTIFY SHOULD be sent and SHOULD contain a
+ presence document with the current state of the presentity. If the
+ subscription is rejected, a NOTIFY MAY be sent. As described in RFC
+ 3265 [2], the Subscription-State header field indicates the state of
+ the subscription.
+
+ The body of the NOTIFY MUST be sent using one of the types listed in
+ the Accept header field in the most recent SUBSCRIBE request, or
+ using the type "application/pidf+xml" if no Accept header field was
+ present.
+
+ The means by which the PA learns the state of the presentity are also
+ outside the scope of this recommendation. Registrations can provide
+ a component of the presentity state. However, the means by which a
+ PA uses registrations to construct a presence document are an
+ implementation choice. If a PUA wishes to explicitly inform the
+ presence agent of its presence state, it should explicitly publish
+ the presence document (or its piece of it) rather than attempting to
+ manipulate their registrations to achieve the desired result.
+
+ For reasons of privacy, it will frequently be necessary to encrypt
+ the contents of the notifications. This can be accomplished using
+ S/MIME. The encryption can be performed using the key of the
+ subscriber as identified in the From field of the SUBSCRIBE request.
+ Similarly, integrity of the notifications is important to
+ subscribers. As such, the contents of the notifications MAY provide
+ authentication and message integrity using S/MIME. Since the NOTIFY
+ is generated by the presence server, which may not have access to the
+
+
+
+Rosenberg Standards Track [Page 12]
+
+RFC 3856 SIP Presence August 2004
+
+
+ key of the user represented by the presentity, it will frequently be
+ the case that the NOTIFY is signed by a third party. It is
+ RECOMMENDED that the signature be by an authority over the domain of
+ the presentity. In other words, for a user pres:user@example.com,
+ the signator of the NOTIFY SHOULD be the authority for example.com.
+
+6.8. Subscriber Processing of NOTIFY Requests
+
+ RFC 3265 [2] leaves it to event packages to describe the process
+ followed by the subscriber upon receipt of a NOTIFY request,
+ including any logic required to form a coherent resource state.
+
+ In this specification, each NOTIFY contains either no presence
+ document, or a document representing the complete and coherent state
+ of the presentity. Within a dialog, the presence document in the
+ NOTIFY request with the highest CSeq header field value is the
+ current one. When no document is present in that NOTIFY, the
+ presence document present in the NOTIFY with the next highest CSeq
+ value is used. Extensions which specify the use of partial state for
+ presentities will need to dictate how coherent state is achieved.
+
+6.9. Handling of Forked Requests
+
+ RFC 3265 [2] requires each package to describe handling of forked
+ SUBSCRIBE requests.
+
+ This specification only allows a single dialog to be constructed as a
+ result of emitting an initial SUBSCRIBE request. This guarantees
+ that only a single PA is generating notifications for a particular
+ subscription to a particular presentity. The result of this is that
+ a presentity can have multiple PAs active, but these should be
+ homogeneous, so that each can generate the same set of notifications
+ for the presentity. Supporting heterogeneous PAs, each of which
+ generates notifications for a subset of the presence data, is complex
+ and difficult to manage. Doing so would require the subscriber to
+ act as the aggregator for presence data. This aggregation function
+ can only reasonably be performed by agents representing the
+ presentity. Therefore, if aggregation is needed, it MUST be done in
+ a PA representing the presentity.
+
+ Section 4.4.9 of RFC 3265 [2] describes the processing that is
+ required to guarantee the creation of a single dialog in response to
+ a SUBSCRIBE request.
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 13]
+
+RFC 3856 SIP Presence August 2004
+
+
+6.10. Rate of Notifications
+
+ RFC 3265 [2] requires each package to specify the maximum rate at
+ which notifications can be sent.
+
+ A PA SHOULD NOT generate notifications for a single presentity at a
+ rate of more than once every five seconds.
+
+6.11. State Agents
+
+ RFC 3265 [2] requires each package to consider the role of state
+ agents in the package, and if they are used, to specify how
+ authentication and authorization are done.
+
+ State agents are core to this package. Whenever the PA is not
+ co-located with the PUA for the presentity, the PA is acting as a
+ state agent. It collects presence state from the PUA, and aggregates
+ it into a presence document. Because there can be multiple PUA, a
+ centralized state agent is needed to perform this aggregation. That
+ is why state agents are fundamental to presence. Indeed, they have a
+ specific term that describes them - a presence server.
+
+6.11.1. Aggregation, Authentication, and Authorization
+
+ The means by which aggregation is done in the state agent is purely a
+ matter of policy. The policy will typically combine the desires of
+ the presentity along with the desires of the provider. This document
+ in no way restricts the set of policies which may be applied.
+
+ However, there is clearly a need for the state agent to have access
+ to the state of the presentity. This state is manipulated by the
+ PUA. One way in which the state agent can obtain this state is to
+ subscribe to it. As a result, if there were 5 PUA manipulating
+ presence state for a single presentity, the state agent would
+ generate 5 subscriptions, one to each PUA. For this mechanism to be
+ effective, all PUA SHOULD be capable of acting as a PA for the state
+ that they manipulate, and that they authorize subscriptions that can
+ be authenticated as coming from the domain of the presentity.
+
+ The usage of state agents does not significantly alter the way in
+ which authentication is done by the PA. Any of the SIP
+ authentication mechanisms can be used by a state agent. However,
+ digest authentication will require the state agent to be aware of the
+ shared secret between the presentity and the subscriber. This will
+ require some means to securely transfer the shared secrets from the
+ presentity to the state agent.
+
+
+
+
+
+Rosenberg Standards Track [Page 14]
+
+RFC 3856 SIP Presence August 2004
+
+
+ The usage of state agents does, however, have a significant impact on
+ authorization. As stated in Section 6.6, a PA is required to
+ authorize all subscriptions. If no explicit authorization policy has
+ been defined, the PA will need to query the user for authorization.
+ In a presence edge server (where the PUA is co-located with the PUA),
+ this is trivially accomplished. However, when state agents are used
+ (i.e., a presence server), a means is needed to alert the user that
+ an authorization decision is required. This is the reason for the
+ watcherinfo event template-package [8]. All state agents SHOULD
+ support the watcherinfo template-package.
+
+6.11.2. Migration
+
+ On occasion, it makes sense for the PA function to migrate from one
+ server to another. For example, for reasons of scale, the PA
+ function may reside in the presence server when the PUA is not
+ running, but when the PUA connects to the network, the PA migrates
+ subscriptions to it in order to reduce state in the network. The
+ mechanism for accomplishing the migration is described in Section
+ 3.3.5 of RFC 3265 [2]. However, packages need to define under what
+ conditions such a migration would take place.
+
+ A PA MAY choose to migrate subscriptions at any time, through
+ configuration, or through dynamic means. The REGISTER request
+ provides one dynamic means for a presence server to discover that the
+ function can migrate to a PUA. Specifically, if a PUA wishes to
+ indicate support for the PA function, it SHOULD use the callee
+ capabilities specification [9] to indicate that it supports the
+ SUBSCRIBE request method and the presence event package. The
+ combination of these two define a PA. Of course, a presence server
+ can always attempt a migration without these explicit hints. If it
+ fails with either a 405 or 489 response code, the server knows that
+ the PUA does not support the PA function. In this case, the server
+ itself will need to act as a PA for that subscription request. Once
+ such a failure has occurred, the server SHOULD NOT attempt further
+ migrations to that PUA for the duration of its registration.
+ However, to avoid the extra traffic generated by these failed
+ requests, a presence server SHOULD support the callee capabilities
+ extension.
+
+ Furthermore, indication of support for the SUBSCRIBE request and the
+ presence event package is not sufficient for migration of
+ subscriptions. A PA SHOULD NOT migrate the subscription if it is
+ composing aggregated presence documents received from multiple PUA.
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 15]
+
+RFC 3856 SIP Presence August 2004
+
+
+7. Learning Presence State
+
+ Presence information can be obtained by the PA in many ways. No
+ specific mechanism is mandated by this specification. This section
+ overviews some of the options, for informational purposes only.
+
+7.1. Co-location
+
+ When the PA function is co-located with the PUA, presence is known
+ directly by the PA.
+
+7.2. REGISTER
+
+ A UA uses the SIP REGISTER method to inform the SIP network of its
+ current communications addresses (i.e., Contact addresses). Multiple
+ UA can independently register Contact addresses for the same
+ address-of-record. This registration state represents an important
+ piece of the overall presence information for a presentity. It is an
+ indication of basic reachability for communications.
+
+ Usage of REGISTER information to construct presence is only possible
+ if the PA has access to the registration database, and can be
+ informed of changes to that database. One way to accomplish that is
+ to co-locate the PA with the registrar.
+
+ The means by which registration state is converted into presence
+ state is a matter of local policy, and beyond the scope of this
+ specification. However, some general guidelines can be provided.
+ The address-of-record in the registration (the To header field)
+ identifies the presentity. Each registered Contact header field
+ identifies a point of communications for that presentity, which can
+ be modeled using a tuple. Note that the contact address in the tuple
+ need not be the same as the registered contact address. Using an
+ address-of-record instead allows subsequent communications from a
+ watcher to pass through proxies. This is useful for policy
+ processing on behalf of the presentity and the provider.
+
+ A PUA that uses registrations to manipulate presence state SHOULD
+ make use of the SIP callee capabilities extension [9]. This allows
+ the PUA to provide the PA with richer information about itself. For
+ example, the presence of the methods parameter listing the method
+ "MESSAGE" indicates support for instant messaging.
+
+ The q values from the Contact header field [1] can be used to
+ establish relative priorities amongst the various communications
+ addresses in the Contact header fields.
+
+
+
+
+
+Rosenberg Standards Track [Page 16]
+
+RFC 3856 SIP Presence August 2004
+
+
+ The usage of registrations to obtain presence information increases
+ the requirements for authenticity and integrity of registrations.
+ Therefore, REGISTER requests used by presence user agents MUST be
+ authenticated.
+
+7.3. Uploading Presence Documents
+
+ If a means exists to upload presence documents from PUA to the PA,
+ the PA can act as an aggregator and redistributor of those documents.
+ The PA, in this case, would take the presence documents received from
+ each PUA for the same presentity, and merge the tuples across all of
+ those PUA into a single presence document. Typically, this
+ aggregation would be accomplished through administrator or user
+ defined policies about how the aggregation should be done.
+
+ The specific means by which a presence document is uploaded to a
+ presence agent are outside the scope of this specification. When a
+ PUA wishes to have direct manipulation of the presence that is
+ distributed to subscribers, direct uploading of presence documents is
+ RECOMMENDED.
+
+8. Example Message Flow
+
+ This message flow illustrates how the presence server can be
+ responsible for sending notifications for a presentity. This flow
+ assumes that the watcher has previously been authorized to subscribe
+ to this resource at the server.
+
+ In this flow, the PUA informs the server about the updated presence
+ information through some non-SIP means.
+
+ When the value of the Content-Length header field is "..." this means
+ that the value should be whatever the computed length of the body is.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 17]
+
+RFC 3856 SIP Presence August 2004
+
+
+ Watcher Server PUA
+ | F1 SUBSCRIBE | |
+ |------------------>| |
+ | F2 200 OK | |
+ |<------------------| |
+ | F3 NOTIFY | |
+ |<------------------| |
+ | F4 200 OK | |
+ |------------------>| |
+ | | |
+ | | Update presence |
+ | |<------------------ |
+ | | |
+ | F5 NOTIFY | |
+ |<------------------| |
+ | F6 200 OK | |
+ |------------------>| |
+
+
+ Message Details
+
+ F1 SUBSCRIBE watcher->example.com server
+
+ SUBSCRIBE sip:resource@example.com SIP/2.0
+ Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
+ To: <sip:resource@example.com>
+ From: <sip:user@example.com>;tag=xfg9
+ Call-ID: 2010@watcherhost.example.com
+ CSeq: 17766 SUBSCRIBE
+ Max-Forwards: 70
+ Event: presence
+ Accept: application/pidf+xml
+ Contact: <sip:user@watcherhost.example.com>
+ Expires: 600
+ Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 18]
+
+RFC 3856 SIP Presence August 2004
+
+
+ F2 200 OK example.com server->watcher
+
+ SIP/2.0 200 OK
+ Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
+ ;received=192.0.2.1
+ To: <sip:resource@example.com>;tag=ffd2
+ From: <sip:user@example.com>;tag=xfg9
+ Call-ID: 2010@watcherhost.example.com
+ CSeq: 17766 SUBSCRIBE
+ Expires: 600
+ Contact: sip:server.example.com
+ Content-Length: 0
+
+ F3 NOTIFY example.com server-> watcher
+
+ NOTIFY sip:user@watcherhost.example.com SIP/2.0
+ Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
+ From: <sip:resource@example.com>;tag=ffd2
+ To: <sip:user@example.com>;tag=xfg9
+ Call-ID: 2010@watcherhost.example.com
+ Event: presence
+ Subscription-State: active;expires=599
+ Max-Forwards: 70
+ CSeq: 8775 NOTIFY
+ Contact: sip:server.example.com
+ Content-Type: application/pidf+xml
+ Content-Length: ...
+
+ [PIDF Document]
+
+ F4 200 OK watcher-> example.com server
+
+ SIP/2.0 200 OK
+ Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
+ ;received=192.0.2.2
+ From: <sip:resource@example.com>;tag=ffd2
+ To: <sip:user@example.com>;tag=xfg9
+ Call-ID: 2010@watcherhost.example.com
+ CSeq: 8775 NOTIFY
+ Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 19]
+
+RFC 3856 SIP Presence August 2004
+
+
+ F5 NOTIFY example.com server -> watcher
+
+ NOTIFY sip:user@watcherhost.example.com SIP/2.0
+ Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
+ From: <sip:resource@example.com>;tag=ffd2
+ To: <sip:user@example.com>;tag=xfg9
+ Call-ID: 2010@watcherhost.example.com
+ CSeq: 8776 NOTIFY
+ Event: presence
+ Subscription-State: active;expires=543
+ Max-Forwards: 70
+ Contact: sip:server.example.com
+ Content-Type: application/pidf+xml
+ Content-Length: ...
+
+ [New PIDF Document]
+
+ F6 200 OK
+
+ SIP/2.0 200 OK
+ Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
+ ;received=192.0.2.2
+ From: <sip:resource@example.com>;tag=ffd2
+ To: <sip:user@example.com>;tag=xfg9
+ Call-ID: 2010@watcherhost.example.com
+ CSeq: 8776 NOTIFY
+ Content-Length: 0
+
+9. Security Considerations
+
+ There are numerous security considerations for presence. RFC 2779
+ [13] outlines many of them, and they are discussed above. This
+ section considers them issue by issue.
+
+9.1. Confidentiality
+
+ Confidentiality encompasses many aspects of a presence system:
+
+ o Subscribers may not want to reveal the fact that they have
+ subscribed to certain users
+
+ o Users may not want to reveal that they have accepted
+ subscriptions from certain users
+
+ o Notifications (and fetch results) may contain sensitive data
+ which should not be revealed to anyone but the subscriber
+
+
+
+
+
+Rosenberg Standards Track [Page 20]
+
+RFC 3856 SIP Presence August 2004
+
+
+ Confidentiality is provided through a combination of hop-by-hop
+ encryption and end-to-end encryption. The hop-by-hop mechanisms
+ provide scalable confidentiality services, disable attacks involving
+ traffic analysis, and hide all aspects of presence messages.
+ However, they operate based on transitivity of trust, and they cause
+ message content to be revealed to proxies. The end-to-end mechanisms
+ do not require transitivity of trust, and reveal information only to
+ the desired recipient. However, end-to-end encryption cannot hide
+ all information, and is susceptible to traffic analysis. Strong
+ end-to-end authentication and encryption can be done using public
+ keys, and end-to-end encryption can be done using private keys [14].
+ Both hop-by-hop and end-to-end mechanisms will likely be needed for
+ complete privacy services.
+
+ SIP allows any hop by hop encryption scheme, but TLS is mandatory to
+ implement for servers. Therefore, it is RECOMMENDED that TLS [7] be
+ used between elements to provide this function. The details for
+ usage of TLS for server-to-server and client-to-server security are
+ detailed in Section 26.3.2 of RFC 3261 [1].
+
+ SIP encryption, using S/MIME, MAY be used end-to-end for the
+ transmission of both SUBSCRIBE and NOTIFY requests.
+
+9.2. Message Integrity and Authenticity
+
+ It is important for the message recipient to ensure that the message
+ contents are actually what was sent by the originator, and that the
+ recipient of the message be able to determine who the originator
+ really is. This applies to both requests and responses of SUBSCRIBE
+ and NOTIFY. NOTIFY requests are particularly important. Without
+ authentication and integrity, presence documents could be forged or
+ modified, fooling the watcher into believing incorrect presence
+ information.
+
+ RFC 3261 provides many mechanisms to provide these features. In
+ order for the PA to authenticate the watcher, it MAY use HTTP Digest
+ (Section 22 of RFC 3261). As a result, all watchers MUST support
+ HTTP Digest. This is a redundant requirement, however, since all SIP
+ user agents are mandated to support it by RFC 3261. To provide
+ authenticity and integrity services, a watcher MAY use the SIPS
+ scheme when subscribing to the presentity. To support this, all PA
+ MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1
+ of RFC 3261).
+
+ Furthermore, SMIME MAY be used for integrity and authenticity of
+ SUBSCRIBE and NOTIFY requests. This is described in Section 23 of
+ RFC 3261.
+
+
+
+
+Rosenberg Standards Track [Page 21]
+
+RFC 3856 SIP Presence August 2004
+
+
+9.3. Outbound Authentication
+
+ When local proxies are used for transmission of outbound messages,
+ proxy authentication is RECOMMENDED. This is useful to verify the
+ identity of the originator, and prevent spoofing and spamming at the
+ originating network.
+
+9.4. Replay Prevention
+
+ Replay attacks can be used by an attacker to fool a watcher into
+ believing an outdated presence state for a presentity. For example,
+ a document describing a presentity as being "offline" can be
+ replayed, fooling watchers into thinking that the user is never
+ online. This may effectively block communications with the
+ presentity.
+
+ SIP S/MIME can provide message integrity and authentication over SIP
+ request bodies. Watchers and PAs MAY implement S/MIME signatures to
+ prevent these replay attacks. When it is used for that purpose, the
+ presence document carried in the NOTIFY request MUST contain a
+ timestamp. In the case of PIDF, this is accomplished using the
+ timestamp element, as described in Section 6 of [6]. Tuples whose
+ timestamp is older than the timestamp of the most recently received
+ presence document SHOULD be considered stale, and discarded.
+
+ Finally, HTTP digest authentication (which MUST be implemented by
+ watchers and PAs) MAY be used to prevent replay attacks, when there
+ is a shared secret between the PA and the watcher. In such a case,
+ the watcher can challenge the NOTIFY requests with the auth-int
+ quality of protection.
+
+9.5. Denial of Service Attacks Against Third Parties
+
+ Denial of Service (DOS) attacks are a critical problem for an open,
+ inter-domain, presence protocol. Unfortunately, presence is a good
+ candidate for Distributed DoS (DDOS) attacks because of its
+ amplification properties. A single SUBSCRIBE message could generate
+ a nearly unending stream of notifications, so long as a suitably
+ dynamic source of presence data can be found. Thus, a simple way to
+ launch an attack against a target is to send subscriptions to a large
+ number of users, and in the Contact header field (which is where
+ notifications are sent), place the address of the target. RFC 3265
+ provides some mechanisms to mitigate these attacks [2]. If a NOTIFY
+ is not acknowledged or was not wanted, the subscription that
+ generated it is removed. This eliminates the amplification
+ properties of providing false Contact addresses.
+
+
+
+
+
+Rosenberg Standards Track [Page 22]
+
+RFC 3856 SIP Presence August 2004
+
+
+ Authentication and authorization at the PA can also prevent these
+ attacks. Typically, authorization policy will not allow
+ subscriptions from unknown watchers. If the attacks are launched
+ from watchers unknown to the presentity (a common case), the attacks
+ are mitigated.
+
+9.6. Denial Of Service Attacks Against Servers
+
+ Denial of service attacks can also be launched against a presence
+ agent itself, in order to disrupt service to a community of users.
+ SIP itself, along with RFC 3265 [2], describes several mechanisms to
+ mitigate these attacks.
+
+ A server can prevent SYN-attack style attacks through a four-way
+ handshake using digest authentication [1]. Even if the server does
+ not have a shared secret with the client, it can verify the source IP
+ address of the request using the "anonymous" user mechanism described
+ in Section 22.1 of RFC 3261 [1]. SIP also allows a server to
+ instruct a client to back-off from sending it requests, using the 503
+ response code (Section 21.5.4 of RFC 3261 [1]). This can be used to
+ fend off floods of SUBSCRIBE requests launched as a result of a
+ distributed denial of service attack.
+
+10. IANA Considerations
+
+ This specification registers an event package, based on the
+ registration procedures defined in RFC 3265 [2]. The following is
+ the information required for such a registration:
+
+ Package Name: presence
+
+ Package or Template-Package: This is a package.
+
+ Published Document: RFC 3856
+
+ Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 23]
+
+RFC 3856 SIP Presence August 2004
+
+
+11. Contributors
+
+ The following individuals were part of the initial team that worked
+ through the technical design of this specification:
+
+ Jonathan Lennox
+ Columbia University
+ M/S 0401
+ 1214 Amsterdam Ave.
+ New York, NY 10027-7003
+
+ EMail: lennox@cs.columbia.edu
+
+ Robert Sparks
+ dynamicsoft
+ 5100 Tennyson Parkway
+ Suite 1200
+ Plano, Texas 75024
+
+ EMail: rsparks@dynamicsoft.com
+
+ Ben Campbell
+
+ EMail: ben@nostrum.com
+
+ Dean Willis
+ dynamicsoft
+ 5100 Tennyson Parkway
+ Suite 1200
+ Plano, Texas 75024
+
+ EMail: dwillis@dynamicsoft.com
+
+ Henning Schulzrinne
+ Columbia University
+ M/S 0401
+ 1214 Amsterdam Ave.
+ New York, NY 10027-7003
+
+ EMail: schulzrinne@cs.columbia.edu
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 24]
+
+RFC 3856 SIP Presence August 2004
+
+
+ Christian Huitema
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+
+ EMail: huitema@microsoft.com
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+
+ EMail: bernarda@microsoft.com
+
+ David Gurle
+ Reuters Corporation
+
+ EMail: David.Gurle@reuters.com
+
+ David Oran
+ Cisco Systems
+ 170 West Tasman Dr.
+ San Jose, CA 95134
+
+ EMail: oran@cisco.com
+
+12. Acknowledgements
+
+ We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy
+ Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen
+ Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, Ya-Ching Tan,
+ Patrik Faltstrom, Allison Mankin and Hisham Khartabil for their
+ comments and support of this specification.
+
+13. Normative References
+
+ [1] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+ Session Initiation Protocol", RFC 3261, June 2002.
+
+ [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
+ Notification", RFC 3265, June 2002.
+
+ [3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
+ August 2004.
+
+ [4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Rosenberg Standards Track [Page 25]
+
+RFC 3856 SIP Presence August 2004
+
+
+ [5] Peterson, J., "Address Resolution for Instant Messaging and
+ Presence", RFC 3861, August 2004.
+
+ [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
+ J. Peterson, "Presence Information Data Format (PIDF)", RFC
+ 3863, August 2004.
+
+ [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+ [8] Rosenberg, J., "A Watcher Information Event Template-Package for
+ the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
+
+ [9] Schulzrinne, H. Rosenberg, J., and P. Kyzivat, "Indicating User
+ Agent Capabilities in the Session Initiation Protocol (SIP)",
+ RFC 3840, August 2004.
+
+14. Informative References
+
+ [10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
+ Instant Messaging", RFC 2778, February 2000.
+
+ [11] Peterson, J., "Enhancements for Authenticated Identity
+ Management in the Session Initiation Protocol (SIP)", Work in
+ Progress, May 2004.
+
+ [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
+ "Diameter Base Protocol", RFC 3588, September 2003.
+
+ [13] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
+ Messaging / Presence Protocol Requirements", RFC 2779, February
+ 2000.
+
+ [14] Gutmann, P., "Password-Based Encryption for CMS", RFC 3211,
+ December 2001.
+
+15. Author's Address
+
+ Jonathan Rosenberg
+ dynamicsoft
+ 600 Lanidex Plaza
+ Parsippany, NJ 07054
+
+ EMail: jdrosen@dynamicsoft.com
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 26]
+
+RFC 3856 SIP Presence August 2004
+
+
+16. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 27]
+