idnits 2.17.1 draft-ietf-simple-presence-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 31, 2003) is 7749 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2246 (ref. '7') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Obsolete informational reference (is this intentional?): RFC 3211 (ref. '14') (Obsoleted by RFC 3369, RFC 3370) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIMPLE WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 draft-ietf-simple-presence-10.txt 6 January 31, 2003 7 Expires: July 2003 9 A Presence Event Package for the Session Initiation Protocol (SIP) 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes the usage of the Session Initiation Protocol 35 (SIP) for subscriptions and notifications of presence. Presence is 36 defined as the willingness and ability of a user to communicate with 37 other users on the network. Historically, presence has been limited 38 to "on-line" and "off-line" indicators; the notion of presence here 39 is broader. Subscriptions and notifications of presence are supported 40 by defining an event package within the general SIP event 41 notification framework. This protocol is also compliant with the 42 Common Presence Profile (CPP) framework. 44 Table of Contents 46 1 Introduction ........................................ 3 47 2 Terminology ......................................... 3 48 3 Definitions ......................................... 3 49 4 Overview of Operation ............................... 5 50 5 Usage of Presence URIs .............................. 6 51 6 Presence Event Package .............................. 8 52 6.1 Package Name ........................................ 8 53 6.2 Event Package Parameters ............................ 8 54 6.3 SUBSCRIBE Bodies .................................... 8 55 6.4 Subscription Duration ............................... 9 56 6.5 NOTIFY Bodies ....................................... 9 57 6.6 Notifier Processing of SUBSCRIBE Requests ........... 10 58 6.6.1 Authentication ...................................... 10 59 6.6.2 Authorization ....................................... 11 60 6.7 Notifier Generation of NOTIFY Requests .............. 12 61 6.8 Subscriber Processing of NOTIFY Requests ............ 13 62 6.9 Handling of Forked Requests ......................... 13 63 6.10 Rate of Notifications ............................... 14 64 6.11 State Agents ........................................ 14 65 6.11.1 Aggregation, Authentication, and Authorization ...... 14 66 6.11.2 Migration ........................................... 15 67 7 Learning Presence State ............................. 16 68 7.1 Co-location ......................................... 16 69 7.2 REGISTER ............................................ 16 70 7.3 Uploading Presence Documents ........................ 17 71 8 Example Message Flow ................................ 17 72 9 Security Considerations ............................. 20 73 9.1 Confidentiality ..................................... 20 74 9.2 Message Integrity and Authenticity .................. 21 75 9.3 Outbound Authentication ............................. 22 76 9.4 Replay Prevention ................................... 22 77 9.5 Denial of Service Attacks Against Third Parties ..... 22 78 9.6 Denial Of Service Attacks Against Servers ........... 23 79 10 IANA Considerations ................................. 23 80 11 Contributors ........................................ 23 81 12 Acknowledgements .................................... 25 82 13 Authors Addresses ................................... 25 83 14 Normative References ................................ 25 84 15 Informative References .............................. 26 86 1 Introduction 88 Presence, also known as presence information, conveys the ability and 89 willingness of a user to communicate across a set of devices. RFC 90 2778 [10] defines a model and terminology for describing systems that 91 provide presence information. In that model, a presence service is a 92 system that accepts, stores, and distributes presence information to 93 interested parties, called watchers. A presence protocol is a 94 protocol for providing a presence service over the Internet or any IP 95 network. 97 This document proposes the usage of the Session Initiation Protocol 98 (SIP) [1] as a presence protocol. This is accomplished through a 99 concrete instantiation of the general event notification framework 100 defined for SIP [2], and as such, makes use of the SUBSCRIBE and 101 NOTIFY methods defined there. Specifically, this document defines an 102 event package, as described in RFC 3265 [2]. SIP is particularly well 103 suited as a presence protocol. SIP location services already contain 104 presence information, in the form of registrations. Furthermore, SIP 105 networks are capable of routing requests from any user on the network 106 to the server that holds the registration state for a user. As this 107 state is a key component of user presence, those SIP networks can 108 allow SUBSCRIBE requests to be routed to the same server. This means 109 that SIP networks can be reused to establish global connectivity for 110 presence subscriptions and notifications. 112 This event package is based on the concept of a presence agent, which 113 is a new logical entity that is capable of accepting subscriptions, 114 storing subscription state, and generating notifications when there 115 are changes in presence. The entity is defined as a logical one, 116 since it is generally co-resident with another entity. 118 This event package is also compliant with the Common Presence Profile 119 (CPP) framework that has been defined in [3]. This allows SIP for 120 presence to easily interwork with other presence systems compliant to 121 CPP. 123 2 Terminology 125 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 126 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 127 and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and 128 indicate requirement levels for compliant implementations. 130 3 Definitions 132 This document uses the terms as defined in RFC 2778 [10]. 133 Additionally, the following terms are defined and/or additionally 134 clarified: 136 Presence User Agent (PUA): A Presence User Agent manipulates 137 presence information for a presentity. This manipulation 138 can be the side effect of some other action (such as 139 sending a SIP REGISTER request to add a new Contact) or can 140 be done explicitly through the publication of presence 141 documents. We explicitly allow multiple PUAs per 142 presentity. This means that a user can have many devices 143 (such as a cell phone and Personal Digital Assistant 144 (PDA)), each of which is independently generating a 145 component of the overall presence information for a 146 presentity. PUAs push data into the presence system, but 147 are outside of it, in that they do not receive SUBSCRIBE 148 messages, or send NOTIFY messages. 150 Presence Agent (PA): A presence agent is a SIP user agent which 151 is capable of receiving SUBSCRIBE requests, responding to 152 them, and generating notifications of changes in presence 153 state. A presence agent must have knowledge of the presence 154 state of a presentity. This means that it must have access 155 to presence data manipulated by PUAs for the presentity. 156 One way to do this is by co-locating the PA with the 157 proxy/registrar. Another way is to co-locate it with the 158 presence user agent of the presentity. However, these are 159 not the only ways, and this specification makes no 160 recommendations about where the PA function should be 161 located. A PA is always addressable with a SIP URI that 162 uniquely identifies the presentity (i.e, 163 sip:joe@example.com). There can be multiple PAs for a 164 particular presentity, each of which handles some subset of 165 the total subscriptions currently active for the 166 presentity. A PA is also a notifier (defined in RFC 3265 167 [2]) that supports the presence event package. 169 Presence Server: A presence server is a physical entity that can 170 act as either a presence agent or as a proxy server for 171 SUBSCRIBE requests. When acting as a PA, it is aware of the 172 presence information of the presentity through some 173 protocol means. When acting as a proxy, the SUBSCRIBE 174 requests are proxied to another entity that may act as a 175 PA. 177 Edge Presence Server: An edge presence server is a presence 178 agent that is co-located with a PUA. It is aware of the 179 presence information of the presentity because it is co- 180 located with the entity that manipulates this presence 181 information. 183 4 Overview of Operation 185 In this section, we present an overview of the operation of this 186 event package. The overview describes behavior that is documented in 187 part here, in part within the SIP event framework [2], and in part in 188 the SIP specification [1], in order to provide clarity on this 189 package for readers only casually familiar with those specifications. 190 However, the detailed semantics of this package require the reader to 191 be familiar with SIP events and the SIP specification itself. 193 When an entity, the subscriber, wishes to learn about presence 194 information from some user, it creates a SUBSCRIBE request. This 195 request identifies the desired presentity in the Request-URI, using a 196 SIP URI, SIPS URI [1] or a presence URI [3]. The SUBSCRIBE request is 197 carried along SIP proxies as any other SIP request would be. In most 198 cases, it eventually arrives at a presence server, which can either 199 generate a response to the request (in which case it acts as the 200 presence agent for the presentity), or proxy it on to an edge 201 presence server. If the edge presence server handles the 202 subscription, it is acting as the presence agent for the presentity. 203 The decision at a presence server about whether to proxy or terminate 204 the SUBSCRIBE is a local matter; however, we describe one way to 205 effect such a configuration, using REGISTER. 207 The presence agent (whether in the presence server or edge presence 208 server) first authenticates the subscription, then authorizes it. The 209 means for authorization are outside the scope of this protocol, and 210 we expect that many mechanisms will be used. If authorized, a 200 OK 211 response is returned. If authorization could not be obtained at this 212 time, the subscription is considered "pending", and a 202 response is 213 returned. In both cases, the PA sends an immediate NOTIFY message 214 containing the state of the presentity and of the subscription. The 215 presentity state may be bogus in the case of a pending subscription, 216 indicating offline no matter what the actual state of the presentity, 217 for example. This is to protect the privacy of the presentity, who 218 may not want to reveal that they have not provided authorization for 219 the subscriber. As the state of the presentity changes, the PA 220 generates NOTIFYs containing those state changes to all subscribers 221 with authorized subscriptions. Changes in the state of the 222 subscription itself can also trigger NOTIFY requests; that state is 223 carried in the Subscription-State header field of the NOTIFY, and 224 would typically indicate whether the subscription is active or 225 pending. 227 The SUBSCRIBE message establishes a "dialog" with the presence agent. 228 A dialog is defined in RFC 3261 [1], and it represents the SIP state 229 between a pair of entities to facilitate peer-to-peer message 230 exchanges. This state includes the sequence numbers for messages in 231 both directions (SUBSCRIBE from the subscriber, NOTIFY from the 232 presence agent), in addition to a route set and remote target URI. 233 The route set is a list of SIP (or SIPS) URIs which identify SIP 234 proxy servers that are to be visited along the path of SUBSCRIBE 235 refreshes or NOTIFY requests. The remote target URI is the SIP or 236 SIPS URI that identifies the target of the message - the subscriber, 237 in the case of NOTIFY, or the presence agent, in the case of a 238 SUBSCRIBE refresh. 240 SIP provides a procedure called record-routing that allows for proxy 241 servers to request to be on the path of NOTIFY messages and SUBSCRIBE 242 refreshes. This is accomplished by inserting a URI into the Record- 243 Route header field in the initial SUBSCRIBE request. 245 The subscription persists for a duration that is negotiated as part 246 of the initial SUBSCRIBE. The subscriber will need to refresh the 247 subscription before its expiration, if they wish to retain the 248 subscription. This is accomplished by sending a SUBSCRIBE refresh 249 within the same dialog established by the initial SUBSCRIBE. This 250 SUBSCRIBE is nearly identical to the initial one, but contains a tag 251 in the To header field, a higher CSeq header field value, and 252 possibly a set of Route header field values that identify the path of 253 proxies the request is to take. 255 The subscriber can terminate the subscription by sending a SUBSCRIBE, 256 within the dialog, with an Expires header field (which indicates 257 duration of the subscription) value of zero. This causes an immediate 258 termination of the subscription. A NOTIFY request is then generated 259 by the presence agent with the most recent state. In fact, behavior 260 of the presence agent for handling a SUBSCRIBE request with Expires 261 of zero is no different than for any other expiration value; pending 262 or authorized SUBSCRIBE requests result in a triggered NOTIFY with 263 the current presentity and subscription state. 265 The presence agent can terminate the subscription at any time. To do 266 so, it sends a NOTIFY request with a Subscription-State header field 267 indicating that the subscription has been terminated. A reason 268 parameter can be supplied which provides the reason. 270 It is also possible to fetch the current presence state, resulting in 271 a one-time notification containing the current state. This is 272 accomplished by sending a SUBSCRIBE request with an immediate 273 expiration. 275 5 Usage of Presence URIs 277 A presentity is identified in the most general way through a presence 278 URI [3], which is of the form pres:user@domain. These URIs are 279 protocol independent. They are resolved to protocol specific URIs, 280 such as a SIP or SIPS URI, through domain-specific mapping policies. 282 It is very possible that a user will have both a SIP (and/or SIPS) 283 URI and a pres URI to identify both themself and other users. This 284 leads to questions about how these URI relate and which are to be 285 used. 287 In some instances, a user starts with one URI format, such as the 288 pres URI, and learns a URI in a different format through some 289 protocol means. As an example, a SUBSCRIBE request sent to a pres URI 290 will result in learning a SIP or SIPS URI for the presentity from the 291 Contact header field of the 200 OK to the SUBSCRIBE request. As 292 another example, a DNS mechanism might be defined that would allow 293 lookup of a pres URI to obtain a SIP or SIPS URI. In cases where one 294 URI is learned from another through protocol means, those means will 295 often provide some kind of scoping that limit the lifetime of the 296 learned URI. DNS, for example, provides a TTL which would limit the 297 scope of the URI. These scopes are very useful to avoid stale or 298 conflicting URIs for identifying the same resource. To ensure that a 299 user can always determine whether a learned URI is still valid, it is 300 RECOMMENDED that systems which provide lookup services for presence 301 URIs have some kind of scoping mechanism. 303 If a subscriber is only aware of the protocol-independent pres URI 304 for a presentity, it follows the procedures defined in [5]. These 305 procedures will result in the placement of the pres URI in the 306 Request-URI of the SIP request, followed by the usage of the DNS 307 procedures defined in [5] to determine the host to send the SIP 308 request to. Of course, a local outbound proxy may alternatively be 309 used, as specified in RFC 3261 [1]. If the subscriber is aware of 310 both the protocol-independent pres URI and the SIP or SIPS URI for 311 the same presentity, and both are valid (as discussed above) it 312 SHOULD use the pres URI format. Of course, if the subscriber only 313 knows the SIP URI for the presentity, that URI is used, and standard 314 RFC 3261 processing will occur. 316 SUBSCRIBE messages also contain logical identifiers that define the 317 originator and recipient of the subscription (the To and From header 318 fields). These headers can take either a pres or SIP URI. When the 319 subscriber is aware of both a pres and SIP URI for its own identity, 320 it SHOULD use the pres URI in the From header field. Similarly, when 321 the subscriber is aware of both a pres and a SIP URI for the desired 322 presentity, it SHOULD use the pres URI in the To header field. 324 The usage of the pres URI instead of the SIP URI within the SIP 325 message supports interoperability through gateways to other CPP- 326 compliant systems. It provides a protocol-independent form of 327 identification which can be passed between systems. Without such an 328 identity, gateways would be forced to map SIP URIs into the 329 addressing format of other protocols. Generally, this is done by 330 converting the SIP URI to the form :@. This is commonly done in email systems, and has 332 many known problems. The usage of the pres URI is a SHOULD, and not a 333 MUST, to allow for cases where it is known that there are no gateways 334 present, or where the usage of the pres URI will cause 335 interoperability problems with SIP components that do not support the 336 pres URI. 338 The Contact, Record-Route and Route fields do not identify logical 339 entities, but rather concrete ones used for SIP messaging. SIP [1] 340 specifies rules for their construction. 342 6 Presence Event Package 344 The SIP event framework [2] defines a SIP extension for subscribing 345 to, and receiving notifications of, events. It leaves the definition 346 of many aspects of these events to concrete extensions, known as 347 event packages. This document qualifies as an event package. This 348 section fills in the information required for all event packages by 349 RFC 3265 [2]. 351 6.1 Package Name 353 The name of this package is "presence". As specified in RFC 3265 [2], 354 this value appears in the Event header field present in SUBSCRIBE and 355 NOTIFY requests. 357 Example: 359 Event: presence 361 6.2 Event Package Parameters 363 The SIP event framework allows event packages to define additional 364 parameters carried in the Event header field. This package, presence, 365 does not define any additional parameters. 367 6.3 SUBSCRIBE Bodies 369 A SUBSCRIBE request MAY contain a body. The purpose of the body 370 depends on its type. Subscriptions will normally not contain bodies. 372 The Request-URI, which identifies the presentity, combined with the 373 event package name, is sufficient for presence. 375 One type of body that can be included in a SUBSCRIBE request is a 376 filter document. These filters request that only certain presence 377 events generate notifications, or would ask for a restriction on the 378 set of data returned in NOTIFY requests. For example, a presence 379 filter might specify that the notifications should only be generated 380 when the status of the user's instant inbox [10] changes. It might 381 also say that the content of these notifications should only contain 382 the status of the instant inbox. Filter documents are not specified 383 in this document, and at the time of writing, are expected to be the 384 subject of future standardization activity. 386 Honoring of these filters is at the policy discretion of the PA. 388 If the SUBSCRIBE request does not contain a filter, this tells the PA 389 that no filter is to be applied. The PA SHOULD send NOTIFY requests 390 at the discretion of its own policy. 392 6.4 Subscription Duration 394 User presence changes as a result of many events. Some examples are: 396 o Turning on and off of a cell phone 398 o Modifying the registration from a softphone 400 o Changing the status on an instant messaging tool 402 These events are usually triggered by human intervention, and occur 403 with a frequency on the order of seconds to hours. As such, 404 subscriptions should have an expiration in the middle of this range, 405 which is roughly one hour. Therefore, the default expiration time for 406 subscriptions within this package is 3600 seconds. As per RFC 3265 407 [2], the subscriber MAY specify an alternate expiration in the 408 Expires header field. 410 6.5 NOTIFY Bodies 412 As described in RFC 3265 [2], the NOTIFY message will contain bodies 413 that describe the state of the subscribed resource. This body is in a 414 format listed in the Accept header field of the SUBSCRIBE, or a 415 package-specific default if the Accept header field was omitted from 416 the SUBSCRIBE. 418 In this event package, the body of the notification contains a 419 presence document. This document describes the presence of the 420 presentity that was subscribed to. All subscribers and notifiers MUST 421 support the "application/cpim-pidf+xml" presence data format 422 described in [6]. The subscribe request MAY contain an Accept header 423 field. If no such header field is present, it has a default value of 424 "application/cpim-pidf+xml". If the header field is present, it MUST 425 include "application/cpim-pidf+xml", and MAY include any other types 426 capable of representing user presence. 428 6.6 Notifier Processing of SUBSCRIBE Requests 430 Based on the proxy routing procedures defined in the SIP 431 specification, the SUBSCRIBE request will arrive at a presence agent 432 (PA). This subsection defines package-specific processing at the PA 433 of a SUBSCRIBE request. General processing rules for requests are 434 covered in Section 8.2 of RFC 3261 [1], in addition to general 435 SUBSCRIBE processing in RFC 3265 [2]. 437 User presence is highly sensitive information. Because the 438 implications of divulging presence information can be severe, strong 439 requirements are imposed on the PA regarding subscription processing, 440 especially related to authentication and authorization. 442 6.6.1 Authentication 444 A presence agent MUST authenticate all subscription requests. This 445 authentication can be done using any of the mechanisms defined in RFC 446 3261 [1]. Note that digest is mandatory to implement, as specified in 447 RFC 3261. 449 In single-domain systems, where the subscribers all have shared 450 secrets with the PA, the combination of digest authentication over 451 Transport Layer Security (TLS) [7] provides a secure and workable 452 solution for authentication. This use case is described in Section 453 26.3.2.1 of RFC 3261 [1]. 455 In inter-domain scenarios, establishing an authenticated identity of 456 the subscriber is harder. It is anticipated that authentication will 457 often be established through transitive trust. SIP mechanisms for 458 network asserted identity can be applied to establish the identity of 459 the subscriber [11]. 461 A presentity MAY choose to represent itself with a SIPS URI. By 462 "represent itself", it means that the user represented by the 463 presentity hands out, on business cards, web pages, and so on, a SIPS 464 URI for their presentity. The semantics associated with this URI, as 465 described in RFC 3261 [1], require TLS usage on each hop between the 466 subscriber and the server in the domain of the URI. This provides 467 additional assurances (but no absolute guarantees) that identity has 468 been verified at each hop. 470 Another mechanism for authentication is S/MIME. Its usage with SIP is 471 described fully in RFC 3261 [1]. It provides an end-to-end 472 authentication mechanism that can be used for a PA to establish the 473 identity of the subscriber. 475 6.6.2 Authorization 477 Once authenticated, the PA makes an authorization decision. A PA MUST 478 NOT accept a subscription unless authorization has been provided by 479 the presentity. The means by which authorization are provided are 480 outside the scope of this document. Authorization may have been 481 provided ahead of time through access lists, perhaps specified in a 482 web page. Authorization may have been provided by means of uploading 483 of some kind of standardized access control list document. Back end 484 authorization servers, such as a DIAMETER [12] server, can also be 485 used. It is also useful to be able to query the user for 486 authorization following the receipt of a subscription request for 487 which no authorization information has been provided. The 488 "watcherinfo" event template package for SIP [8] defines a means by 489 which a presentity can become aware that a user has attempted to 490 subscribe to it, so that it can then provide an authorization 491 decision. 493 Authorization decisions can be very complex. Ultimately, all 494 authorization decisions can be mapped into one of three states: 495 rejected, successful, and pending. Any subscription for which the 496 client is authorized to receive information about some subset of 497 presence state at some points in time is a successful subscription. 498 Any subscription for which the client will never receive any 499 information about any subset of the presence state is a rejected 500 subscription. Any subscription for which it is not yet known whether 501 it is successful or rejected is pending. Generally, a pending 502 subscription occurs when the server cannot obtain authorization at 503 the time of the subscription, but may be able to do so at a later 504 time, perhaps when the presentity becomes available. 506 The appropriate response codes for conveying a successful, rejected, 507 or pending subscription (200, 403 or 603, and 202, respectively) are 508 described in RFC 3265 [2]. 510 If the resource is not in a meaningful state, RFC 3265 [2] allows the 511 body of the initial NOTIFY to be empty. In the case of presence, that 512 NOTIFY MAY contain a presence document. This document would indicate 513 whatever presence state the subscriber has been authorized to see; it 514 is interpreted by the subscriber as the current presence state of the 515 presentity. For pending subscriptions, the state of the presentity 516 SHOULD include some kind of textual note that indicates a pending 517 status. 519 Polite blocking, as described in [13], is possible by generating a 520 200 OK to the subscription even though it has been rejected (or 521 marked pending). Of course, an immediate NOTIFY will still be sent. 522 The contents of the presence document in such a NOTIFY are at the 523 discretion of the implementor, but SHOULD be constructed in such a 524 way as to not reveal to the subscriber that their request has 525 actually been blocked. Typically, this is done by indicating 526 "offline" or equivalent status for a single contact address. 528 6.7 Notifier Generation of NOTIFY Requests 530 RFC 3265 details the formatting and structure of NOTIFY messages. 531 However, packages are mandated to provide detailed information on 532 when to send a NOTIFY, how to compute the state of the resource, how 533 to generate neutral or fake state information, and whether state 534 information is complete or partial. This section describes those 535 details for the presence event package. 537 A PA MAY send a NOTIFY at any time. Typically, it will send one when 538 the state of the presentity changes. The NOTIFY request MAY contain a 539 body indicating the state of the presentity. The times at which the 540 NOTIFY is sent for a particular subscriber, and the contents of the 541 body within that notification, are subject to any rules specified by 542 the authorization policy that governs the subscription. This protocol 543 in no way limits the scope of such policies. As a baseline, a 544 reasonable policy is to generate notifications when the state of any 545 of the presence tuples changes. These notifications would contain the 546 complete and current presence state of the presentity as known to the 547 presence agent. Future extensions can be defined that allow a 548 subscriber to request that the notifications contain changes in 549 presence information only, rather than complete state. 551 In the case of a pending subscription, when final authorization is 552 determined, a NOTIFY can be sent. If the result of the authorization 553 decision was success, a NOTIFY SHOULD be sent and SHOULD contain a 554 presence document with the current state of the presentity. If the 555 subscription is rejected, a NOTIFY MAY be sent. As described in RFC 556 3265 [2], the Subscription-State header field indicates the state of 557 the subscription. 559 The body of the NOTIFY MUST be sent using one of the types listed in 560 the Accept header field in the most recent SUBSCRIBE request, or 561 using the type "application/cpim-pidf+xml" if no Accept header field 562 was present. 564 The means by which the PA learns the state of the presentity are also 565 outside the scope of this recommendation. Registrations can provide a 566 component of the presentity state. However, the means by which a PA 567 uses registrations to construct a presence document are an 568 implementation choice. If a PUA wishes to explicitly inform the 569 presence agent of its presence state, it should explicitly publish 570 the presence document (or its piece of it) rather than attempting to 571 manipulate their registrations to achieve the desired result. 573 For reasons of privacy, it will frequently be necessary to encrypt 574 the contents of the notifications. This can be accomplished using 575 S/MIME. The encryption can be performed using the key of the 576 subscriber as identified in the From field of the SUBSCRIBE request. 577 Similarly, integrity of the notifications is important to 578 subscribers. As such, the contents of the notifications MAY provide 579 authentication and message integrity using S/MIME. Since the NOTIFY 580 is generated by the presence server, which may not have access to the 581 key of the user represented by the presentity, it will frequently be 582 the case that the NOTIFY is signed by a third party. It is 583 RECOMMENDED that the signature be by an authority over the domain of 584 the presentity. In other words, for a user pres:user@example.com, the 585 signator of the NOTIFY SHOULD be the authority for example.com. 587 6.8 Subscriber Processing of NOTIFY Requests 589 RFC 3265 [2] leaves it to event packages to describe the process 590 followed by the subscriber upon receipt of a NOTIFY request, 591 including any logic required to form a coherent resource state. 593 In this specification, each NOTIFY contains either no presence 594 document, or a document representing the complete and coherent state 595 of the presentity. Within a dialog, the presence document in the 596 NOTIFY request with the highest CSeq header field value is the 597 current one. When no document is present in that NOTIFY, the presence 598 document present in the NOTIFY with the next highest CSeq value is 599 used. Extensions which specify the use of partial state for 600 presentities will need to dictate how coherent state is achieved. 602 6.9 Handling of Forked Requests 604 RFC 3265 [2] requires each package to describe handling of forked 605 SUBSCRIBE requests. 607 This specification only allows a single dialog to be constructed as a 608 result of emitting an initial SUBSCRIBE request. This guarantees that 609 only a single PA is generating notifications for a particular 610 subscription to a particular presentity. The result of this is that a 611 presentity can have multiple PAs active, but these should be 612 homogeneous, so that each can generate the same set of notifications 613 for the presentity. Supporting heterogeneous PAs, each of which 614 generates notifications for a subset of the presence data, is complex 615 and difficult to manage. Doing so would require the subscriber to act 616 as the aggregator for presence data. This aggregation function can 617 only reasonably be performed by agents representing the presentity. 618 Therefore, if aggregation is needed, it MUST be done in a PA 619 representing the presentity. 621 Section 4.4.9 of RFC 3265 [2] describes the processing that is 622 required to guarantee the creation of a single dialog in response to 623 a SUBSCRIBE request. 625 6.10 Rate of Notifications 627 RFC 3265 [2] requires each package to specify the maximum rate at 628 which notifications can be sent. 630 A PA SHOULD NOT generate notifications for a single presentity at a 631 rate of more than once every five seconds. 633 6.11 State Agents 635 RFC 3265 [2] requires each package to consider the role of state 636 agents in the package, and if they are used, to specify how 637 authentication and authorization are done. 639 State agents are core to this package. Whenever the PA is not co- 640 located with the PUA for the presentity, the PA is acting as a state 641 agent. It collects presence state from the PUA, and aggregates it 642 into a presence document. Because there can be multiple PUA, a 643 centralized state agent is needed to perform this aggregation. That 644 is why state agents are fundamental to presence. Indeed, they have a 645 specific term that describes them - a presence server. 647 6.11.1 Aggregation, Authentication, and Authorization 649 The means by which aggregation is done in the state agent is purely a 650 matter of policy. The policy will typically combine the desires of 651 the presentity along with the desires of the provider. This draft in 652 no way restricts the set of policies which may be applied. 654 However, there is clearly a need for the state agent to have access 655 to the state of the presentity. This state is manipulated by the PUA. 656 One way in which the state agent can obtain this state is to 657 subscribe to it. As a result, if there were 5 PUA manipulating 658 presence state for a single presentity, the state agent would 659 generate 5 subscriptions, one to each PUA. For this mechanism to be 660 effective, all PUA SHOULD be capable of acting as a PA for the state 661 that they manipulate, and that they authorize subscriptions that can 662 be authenticated as coming from the domain of the presentity. 664 The usage of state agents does not significantly alter the way in 665 which authentication is done by the PA. Any of the SIP authentication 666 mechanisms can be used by a state agent. However, digest 667 authentication will require the state agent to be aware of the shared 668 secret between the presentity and the subscriber. This will require 669 some means to securely transfer the shared secrets from the 670 presentity to the state agent. 672 The usage of state agents does, however, have a signficiant impact on 673 authorization. As stated in Section 6.6, a PA is required to 674 authorize all subscriptions. If no explicit authorization policy has 675 been defined, the PA will need to query the user for authorization. 676 In a presence edge server (where the PUA is co-located with the PUA), 677 this is trivially accomplished. However, when state agents are used 678 (i.e., a presence server), a means is needed to alert the user that 679 an authorization decision is required. This is the reason for the 680 watcherinfo event package [8]. All state agents SHOULD support this 681 event package. 683 6.11.2 Migration 685 On occasion, it makes sense for the PA function to migrate from one 686 server to another. For example, for reasons of scale, the PA function 687 may reside in the presence server when the PUA is not running, but 688 when the PUA connects to the network, the PA migrates subscriptions 689 to it in order to reduce state in the network. The mechanism for 690 accomplishing the migration is described in Section 3.3.5 of RFC 3265 691 [2]. However, packages need to define under what conditions such a 692 migration would take place. 694 A PA MAY choose to migrate subscriptions at any time, through 695 configuration, or through dynamic means. The REGISTER request 696 provides one dynamic means for a presence server to discover that the 697 function can migrate to a PUA. Specifically, if a PUA wishes to 698 indicate support for the PA function, it SHOULD use the caller 699 preferences specification [9] to indicate that it supports the 700 SUBSCRIBE request method and the presence event package. The 701 combination of these two define a PA. Of course, a presence server 702 can always attempt a migration without these explicit hints. If it 703 fails with either a 405 or 489 response code, the server knows that 704 the PUA does not support the PA function. In this case, the server 705 itself will need to act as a PA for that subscription request. Once 706 such a failure has occurred, the server SHOULD NOT attempt further 707 migrations to that PUA for the duration of its registration. However, 708 to avoid the extra traffic generated by these failed requests, a 709 presence server SHOULD support the caller preferences extension. 711 Furthermore, indication of support for the SUBSCRIBE request and the 712 presence event package is not sufficient for migration of 713 subscriptions. A PA SHOULD NOT migrate the subscription if it is 714 composing aggregated presence documents received from multiple PUA. 716 7 Learning Presence State 718 Presence information can be obtained by the PA in many ways. No 719 specific mechanism is mandated by this specification. This section 720 overviews some of the options, for informational purposes only. 722 7.1 Co-location 724 When the PA function is co-located with the PUA, presence is known 725 directly by the PA. 727 7.2 REGISTER 729 A UA uses the SIP REGISTER method to inform the SIP network of its 730 current communications addresses (i.e., Contact addresses). Multiple 731 UA can independently register Contact addresses for the same 732 address-of-record. This registration state represents an important 733 piece of the overall presence information for a presentity. It is an 734 indication of basic reachability for communications. 736 Usage of REGISTER information to construct presence is only possible 737 if the PA has access to the registration database, and can be 738 informed of changes to that database. One way to accomplish that is 739 to co-locate the PA with the registrar. 741 The means by which registration state is converted into presence 742 state is a matter of local policy, and beyond the scope of this 743 specification. However, some general guidelines can be provided. The 744 address-of-record in the registration (the To header field) 745 identifies the presentity. Each registered Contact header field 746 identifies a point of communications for that presentity, which can 747 be modeled using a tuple. Note that the contact address in the tuple 748 need not be the same as the registered contact address. Using an 749 address-of-record instead allows subsequent communications from a 750 watcher to pass through proxies. This is useful for policy processing 751 on behalf of the presentity and the provider. 753 A PUA that uses registrations to manipulate presence state SHOULD 754 make use of the SIP caller preferences extension [9]. This allows the 755 PUA to provide the PA with richer information about itself. For 756 example, the presence of the methods parameter listing the method 757 "MESSAGE" indicates support for instant messaging. 759 The q values from the Contact header field [1] can be used to 760 establish relative priorities amongst the various communications 761 addresses in the Contact header fields. 763 The usage of registrations to obtain presence information increases 764 the requirements for authenticity and integrity of registrations. 765 Therefore, REGISTER requests used by presence user agents MUST be 766 authenticated. 768 7.3 Uploading Presence Documents 770 If a means exists to upload presence documents from PUA to the PA, 771 the PA can act as an aggregator and redistributor of those documents. 772 The PA, in this case, would take the presence documents received from 773 each PUA for the same presentity, and merge the tuples across all of 774 those PUA into a single presence document. Typically, this 775 aggregation would be accomplished through administrator or user 776 defined policies about how the aggregation should be done. 778 The specific means by which a presence document are uploaded to a 779 presence agent are outside the scope of this specification. When a 780 PUA wishes to have direct manipulation of the presence that is 781 distributed to subscribers, direct uploading of presence documents is 782 RECOMMENDED. 784 8 Example Message Flow 786 This message flow illustrates how the presence server can be the 787 responsible for sending notifications for a presentity. This flow 788 assumes that the watcher has previously been authorized to subscribe 789 to this resource at the server. 791 In this flow, the PUA informs the server about the updated presence 792 information through some non-SIP means. 794 When the value of the Content-Length header field is "..." this means 795 that the value should be whatever the computed length of the body is. 797 Watcher Server PUA 798 | F1 SUBSCRIBE | | 799 |------------------>| | 800 | F2 200 OK | | 801 |<------------------| | 802 | F3 NOTIFY | | 803 |<------------------| | 804 | F4 200 OK | | 805 |------------------>| | 806 | | | 807 | | Update presence | 808 | |<------------------ | 809 | | | 810 | F5 NOTIFY | | 811 |<------------------| | 812 | F6 200 OK | | 813 |------------------>| | 815 Message Details 817 F1 SUBSCRIBE watcher->example.com server 819 SUBSCRIBE sip:resource@example.com SIP/2.0 820 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 821 To: 822 From: ;tag=xfg9 823 Call-ID: 2010@watcherhost.example.com 824 CSeq: 17766 SUBSCRIBE 825 Max-Forwards: 70 826 Event: presence 827 Accept: application/cpim-pidf+xml 828 Contact: 829 Expires: 600 830 Content-Length: 0 832 F2 200 OK example.com server->watcher 834 SIP/2.0 200 OK 835 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 836 ;received=192.0.2.1 837 To: ;tag=ffd2 838 From: ;tag=xfg9 839 Call-ID: 2010@watcherhost.example.com 840 CSeq: 17766 SUBSCRIBE 841 Event: presence 842 Expires: 600 843 Contact: sip:server.example.com 844 Content-Length: 0 846 F3 NOTIFY example.com server-> watcher 848 NOTIFY sip:user@watcherhost.example.com SIP/2.0 849 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk 850 From: ;tag=ffd2 851 To: ;tag=xfg9 852 Call-ID: 2010@watcherhost.example.com 853 Event: presence 854 Subscription-State: active;expires=599 855 Max-Forwards: 70 856 CSeq: 8775 NOTIFY 857 Contact: sip:server.example.com 858 Content-Type: application/cpim-pidf+xml 859 Content-Length: .. 861 [PIDF Document] 863 F4 200 OK watcher-> example.com server 865 SIP/2.0 200 OK 866 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk 867 ;received=192.0.2.2 868 From: ;tag=ffd2 869 To: ;tag=xfg9 870 Call-ID: 2010@watcherhost.example.com 871 CSeq: 8775 NOTIFY 872 Content-Length: 0 874 F5 NOTIFY example.com server -> watcher 875 NOTIFY sip:user@watcherhost.example.com SIP/2.0 876 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl 877 From: ;tag=ffd2 878 To: ;tag=xfg9 879 Call-ID: 2010@watcherhost.example.com 880 CSeq: 8776 NOTIFY 881 Event: presence 882 Subscription-State: active;expires=543 883 Max-Forwards: 70 884 Contact: sip:server.example.com 885 Content-Type: application/cpim-pidf+xml 886 Content-Length: ... 888 [New PIDF Document] 890 F6 200 OK 892 SIP/2.0 200 OK 893 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl 894 ;received=192.0.2.2 895 From: ;tag=ffd2 896 To: ;tag=xfg9 897 Call-ID: 2010@watcherhost.example.com 898 CSeq: 8776 NOTIFY 899 Content-Length: 0 901 9 Security Considerations 903 There are numerous security considerations for presence. RFC 2779 904 [13] outlines many of them, and they are discussed above. This 905 section considers them issue by issue. 907 9.1 Confidentiality 909 Confidentiality encompasses many aspects of a presence system: 911 o Subscribers may not want to reveal the fact that they have 912 subscribed to certain users 914 o Users may not want to reveal that they have accepted 915 subscriptions from certain users 917 o Notifications (and fetch results) may contain sensitive data 918 which should not be revealed to anyone but the subscriber 920 Confidentiality is provided through a combination of hop-by-hop 921 encryption and end-to-end encryption. The hop-by-hop mechanisms 922 provide scalable confidentiality services, disable attacks involving 923 traffic analysis, and hide all aspects of presence messages. However, 924 they operate based on transitivity of trust, and they cause message 925 content to be revealed to proxies. The end-to-end mechanisms do not 926 require transitivity of trust, and reveal information only to the 927 desired recipient. However, end-to-end encryption cannot hide all 928 information, and is susceptible to traffic analysis. Strong end-to- 929 end authentication and encryption can be done using public keys, and 930 end-to-end encryption can be done using private keys [14]. Both hop- 931 by-hop and end-to-end mechanisms will likely be needed for complete 932 privacy services. 934 SIP allows any hop by hop encryption scheme, but TLS is mandatory to 935 implement for servers. Therefore, it is RECOMMENDED that TLS [7] be 936 used between elements to provide this function. The details for 937 usage of TLS for server-to-server and client-to-server security are 938 detailed in Section 26.3.2 of RFC 3261 [1]. 940 SIP encryption, using S/MIME, MAY be used end-to-end for the 941 transmission of both SUBSCRIBE and NOTIFY requests. 943 9.2 Message Integrity and Authenticity 945 It is important for the message recipient to ensure that the message 946 contents are actually what was sent by the originator, and that the 947 recipient of the message be able to determine who the originator 948 really is. This applies to both requests and responses of SUBSCRIBE 949 and NOTIFY. NOTIFY requests are particularly important. Without 950 authentication and integrity, presence documents could be forged or 951 modified, fooling the watcher into believing incorrect presence 952 information. 954 RFC 3261 provides many mechanisms to provide these features. In order 955 for the PA to authenticate the watcher, it MAY use HTTP Digest 956 (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP 957 Digest. This is a redundant requirement, however, since all SIP user 958 agents are mandated to support it by RFC 3261. To provide 959 authenticity and integrity services, a watcher MAY use the SIPS 960 scheme when subscribing to the presentity. To support this, all PA 961 MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1 962 of RFC 3261). 964 Furthermore, SMIME MAY be used for integrity and authenticity of 965 SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC 966 3261. 968 9.3 Outbound Authentication 970 When local proxies are used for transmission of outbound messages, 971 proxy authentication is RECOMMENDED. This is useful to verify the 972 identity of the originator, and prevent spoofing and spamming at the 973 originating network. 975 9.4 Replay Prevention 977 Replay attacks can be used by an attacker to fool a watcher into 978 believing an outdated presence state for a presentity. For example, a 979 document describing a presentity as being "offline" can be replayed, 980 fooling watchers into thinking that the user is never online. This 981 may effectively block communications with the presentity. 983 SIP S/MIME can provide message integrity and authentication over SIP 984 request bodies. Watchers and PAs MAY implement S/MIME signatures to 985 prevent these replay attacks. When it is used for that purpose, the 986 presence document carried in the NOTIFY request MUST contain a 987 timestamp. In the case of PIDF, this is accomplished using the 988 timestamp element, as described in Section 6 of [6]. Tuples whose 989 timestamp is older than the timestamp of the most recently received 990 presence document SHOULD be considered stale, and discarded. 992 Finally, HTTP digest authentication (which MUST be implemented by 993 watchers and PAs) MAY be used to prevent replay attacks, when there 994 is a shared secret between the PA and the watcher. In such a case, 995 the watcher can challenge the NOTIFY requests with the auth-int 996 quality of protection. 998 9.5 Denial of Service Attacks Against Third Parties 1000 Denial of Service (DOS) attacks are a critical problem for an open, 1001 inter-domain, presence protocol. Unfortunately, presence is a good 1002 candidate for Distributed DoS (DDOS) attacks because of its 1003 amplification properties. A single SUBSCRIBE message could generate a 1004 nearly unending stream of notifications, so long as a suitably 1005 dynamic source of presence data can be found. Thus, a simple way to 1006 launch an attack against a target is to send subscriptions to a large 1007 number of users, and in the Contact header field (which is where 1008 notifications are sent), place the address of the target. 1010 RFC 3265 provides some mechanisms to mitigate these attacks [2]. If a 1011 NOTIFY is not acknowledged or was not wanted, the subscription that 1012 generated it is removed. This eliminates the amplification properties 1013 of providing false Contact addresses. 1015 Authentication and authorization at the PA can also prevent these 1016 attacks. Typically, authorization policy will not allow subscriptions 1017 from unknown watchers. If the attacks are launched from watchers 1018 unknown to the presentity (a common case), the attacks are mitigated. 1020 9.6 Denial Of Service Attacks Against Servers 1022 Denial of service attacks can also be launched against a presence 1023 agent itself, in order to disrupt service to a community of users. 1024 SIP itself, along with RFC 3265 [2], describes several mechanisms to 1025 mitigate these attacks. 1027 A server can prevent SYN-attack style attacks through a four-way 1028 handshake using digest authentication [1]. Even if the server does 1029 not have a shared secret with the client, it can verify the source IP 1030 address of the request using the "anonymous" user mechanism described 1031 in Section 22.1 of RFC 3261 [1]. SIP also allows a server to instruct 1032 a client to back-off from sending it requests, using the 503 response 1033 code (Section 21.5.4 of RFC 3261 [1]). This can be used to fend off 1034 floods of SUBSCRIBE requests launched as a result of a distributed 1035 denial of service attack. 1037 10 IANA Considerations 1039 This specification registers an event package, based on the 1040 registration procedures defined in RFC 3265 [2]. The following is the 1041 information required for such a registration: 1043 Package Name: presence 1045 Package or Template-Package: This is a package. 1047 Published Document: RFC XXXX (Note to RFC Editor: Please fill in 1048 XXXX with the RFC number of this specification). 1050 Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net. 1052 11 Contributors 1054 The following individuals were part of the initial team that worked 1055 through the technical design of this specification: 1057 Jonathan Lennox 1058 Columbia University 1059 M/S 0401 1060 1214 Amsterdam Ave. 1061 New York, NY 10027-7003 1062 email: lennox@cs.columbia.edu 1064 Robert Sparks 1065 dynamicsoft 1066 5100 Tennyson Parkway 1067 Suite 1200 1068 Plano, Texas 75024 1069 email: rsparks@dynamicsoft.com 1071 Ben Campbell 1072 5100 Tennyson Parkway 1073 Suite 1200 1074 Plano, Texas 75024 1075 email: bcampbell@dynamicsoft.com 1077 Dean Willis 1078 dynamicsoft 1079 5100 Tennyson Parkway 1080 Suite 1200 1081 Plano, Texas 75024 1082 email: dwillis@dynamicsoft.com 1084 Henning Schulzrinne 1085 Columbia University 1086 M/S 0401 1087 1214 Amsterdam Ave. 1088 New York, NY 10027-7003 1089 email: schulzrinne@cs.columbia.edu 1091 Christian Huitema 1092 Microsoft Corporation 1093 One Microsoft Way 1094 Redmond, WA 98052-6399 1095 email: huitema@microsoft.com 1097 Bernard Aboba 1098 Microsoft Corporation 1099 One Microsoft Way 1100 Redmond, WA 98052-6399 1101 email: bernarda@microsoft.com 1103 David Gurle 1104 Microsoft Corporation 1105 One Microsoft Way 1106 Redmond, WA 98052-6399 1107 email: dgurle@microsoft.com 1109 David Oran 1110 Cisco Systems 1111 170 West Tasman Dr. 1112 San Jose, CA 95134 1113 email: oran@cisco.com 1115 12 Acknowledgements 1117 We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy 1118 Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen 1119 Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, Ya-Ching Tan, 1120 Patrik Faltstrom, Allison Mankin and Hisham Khartabil for their 1121 comments and support of this specification. 1123 13 Authors Addresses 1125 Jonathan Rosenberg 1126 dynamicsoft 1127 72 Eagle Rock Avenue 1128 First Floor 1129 East Hanover, NJ 07936 1130 email: jdrosen@dynamicsoft.com 1132 14 Normative References 1134 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1135 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 1136 initiation protocol," RFC 3261, Internet Engineering Task Force, June 1137 2002. 1139 [2] A. B. Roach, "Session initiation protocol (sip)-specific event 1140 notification," RFC 3265, Internet Engineering Task Force, June 2002. 1142 [3] D. H. Crocker and J. Peterson, "Common profile: Presence," 1143 internet draft, Internet Engineering Task Force, Dec. 2002. Work in 1144 progress. 1146 [4] S. Bradner, "Key words for use in rfcs to indicate requirement 1147 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 1149 [5] D. H. Crocker and J. Peterson, "Address resolution for instant 1150 messaging and presence," internet draft, Internet Engineering Task 1151 Force, Dec. 2002. Work in progress. 1153 [6] H. Sugano, S. Fujimoto, et al. , "Common presence and instant 1154 messaging (cpim)presence information data format," internet draft, 1155 Internet Engineering Task Force, Jan. 2003. Work in progress. 1157 [7] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, 1158 Internet Engineering Task Force, Jan. 1999. 1160 [8] J. Rosenberg, "A watcher information event template-package for 1161 the session initiation protocol (SIP)," internet draft, Internet 1162 Engineering Task Force, Dec. 2002. Work in progress. 1164 [9] H. Schulzrinne and J. Rosenberg, "Session initiation protocol 1165 (SIP) caller preferences and callee capabilities," internet draft, 1166 Internet Engineering Task Force, Nov. 2002. Work in progress. 1168 15 Informative References 1170 [10] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and 1171 instant messaging," RFC 2778, Internet Engineering Task Force, Feb. 1172 2000. 1174 [11] J. Peterson, "Enhancements for authenticated identity management 1175 in the session initiation protocol (SIP)," internet draft, Internet 1176 Engineering Task Force, Oct. 2002. Work in progress. 1178 [12] P. Calhoun et al. , "Diameter base protocol," internet draft, 1179 Internet Engineering Task Force, Jan. 2003. Work in progress. 1181 [13] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging 1182 / presence protocol requirements," RFC 2779, Internet Engineering 1183 Task Force, Feb. 2000. 1185 [14] P. Gutmann, "Password-based encryption for CMS," RFC 3211, 1186 Internet Engineering Task Force, Dec. 2001. 1188 Intellectual Property Statement 1190 The IETF takes no position regarding the validity or scope of any 1191 intellectual property or other rights that might be claimed to 1192 pertain to the implementation or use of the technology described in 1193 this document or the extent to which any license under such rights 1194 might or might not be available; neither does it represent that it 1195 has made any effort to identify any such rights. Information on the 1196 IETF's procedures with respect to rights in standards-track and 1197 standards-related documentation can be found in BCP-11. Copies of 1198 claims of rights made available for publication and any assurances of 1199 licenses to be made available, or the result of an attempt made to 1200 obtain a general license or permission for the use of such 1201 proprietary rights by implementors or users of this specification can 1202 be obtained from the IETF Secretariat. 1204 The IETF invites any interested party to bring to its attention any 1205 copyrights, patents or patent applications, or other proprietary 1206 rights which may cover technology that may be required to practice 1207 this standard. Please address the information to the IETF Executive 1208 Director. 1210 Full Copyright Statement 1212 Copyright (c) The Internet Society (2003). All Rights Reserved. 1214 This document and translations of it may be copied and furnished to 1215 others, and derivative works that comment on or otherwise explain it 1216 or assist in its implementation may be prepared, copied, published 1217 and distributed, in whole or in part, without restriction of any 1218 kind, provided that the above copyright notice and this paragraph are 1219 included on all such copies and derivative works. However, this 1220 document itself may not be modified in any way, such as by removing 1221 the copyright notice or references to the Internet Society or other 1222 Internet organizations, except as needed for the purpose of 1223 developing Internet standards in which case the procedures for 1224 copyrights defined in the Internet Standards process must be 1225 followed, or as required to translate it into languages other than 1226 English. 1228 The limited permissions granted above are perpetual and will not be 1229 revoked by the Internet Society or its successors or assigns. 1231 This document and the information contained herein is provided on an 1232 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1233 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1234 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1235 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1236 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.