idnits 2.17.1 draft-olson-simple-publish-02.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. == There is 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There is 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 475 has weird spacing: '... where proxy...' == Line 518 has weird spacing: '... where proxy...' -- 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 (February 27, 2003) is 7729 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: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-pidf-07 -- Possible downref: Normative reference to a draft: ref. '6' Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE B. Campbell 3 Internet-Draft dynamicsoft 4 Expires: August 28, 2003 S. Olson 5 Microsoft 6 J. Peterson 7 NeuStar, Inc. 8 J. Rosenberg 9 dynamicsoft 10 B. Stucker 11 Nortel Networks, Inc. 12 February 27, 2003 14 SIMPLE Presence Publication Mechanism 15 draft-olson-simple-publish-02 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 28, 2003. 40 Copyright Notice 42 Copyright (C) The Internet Society (2003). All Rights Reserved. 44 Abstract 46 This document describes an extension to the Session Initiation 47 Protocol (SIP) for publishing event state used within the framework 48 for SIP Event Notification. The first application of this extension 49 is targeted at the publication of presence information. 51 The method described in this document allows event information to be 52 published to a presence agent on behalf of a user. This method can 53 be extended to support publication of other event state, but it is 54 not intended to be a general-purpose mechanism for transport of 55 arbitrary data as there are better suited mechanisms for this purpose 56 (ftp, http, etc.) This method is intended to be a simple, 57 light-weight mechanism that employs SIP in order to support SIMPLE 58 services. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Constructing the PUBLISH Request . . . . . . . . . . . . . 6 65 4. Requirements of the body of a PUBLISH request . . . . . . 8 66 5. Creating Initial Publication Soft-State . . . . . . . . . 9 67 6. Setting the Expiration Interval of Event State . . . . . . 10 68 7. Removing Event State . . . . . . . . . . . . . . . . . . . 11 69 8. Querying the Current Event State . . . . . . . . . . . . . 12 70 9. Refreshing Event State . . . . . . . . . . . . . . . . . . 13 71 10. Processing PUBLISH Requests . . . . . . . . . . . . . . . 14 72 11. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 11.1 New Method . . . . . . . . . . . . . . . . . . . . . . . . 17 74 11.2 New Response Code . . . . . . . . . . . . . . . . . . . . 18 75 11.2.1 "494 Out Of Sync" Response Code . . . . . . . . . . . . . 19 76 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 13. IANA Considerations . . . . . . . . . . . . . . . . . . . 28 78 14. Security Considerations . . . . . . . . . . . . . . . . . 29 79 15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 30 80 Normative References . . . . . . . . . . . . . . . . . . . 31 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31 82 Intellectual Property and Copyright Statements . . . . . . 33 84 1. Introduction 86 The focus of this specification is to provide a framework for the 87 publication of event state from a UA to a entity that is responsible 88 for compositing this event state and distributing that state to 89 interested parties through the SUBSCRIBE/NOTIFY mechanism. This 90 specification fills a current gap in the event notification framework 91 to allow for a client to push its state to the state agent that acts 92 on its behalf. It is the intention of this framework to allow any 93 event state for which there is an appropriate event package (as 94 defined in RFC 3265 [2]) to be published. 96 The first application of this mechanism is the publication of 97 presence state by a PUA to a presence compositor which has a tightly 98 coupled relationship to the PA. The requirements and model for 99 presence publication are documented in [4]. This specification will 100 address each of these requirments. 102 To accomplish this task a new SIP method, PUBLISH, is defined. 103 PUBLISH is analogous to REGISTER in that it allows a UA to add, 104 modify, and remove state in another entity which manages this state 105 on behalf of a user. The user may in turn have multiple UAs or 106 endpoints. Each endpoint may publish its own unique state and 107 through a subscription to that event discover the event state of the 108 other endpoints for a user. PUBLISH is defined to create soft-state 109 in the state agent; this state has a defined lifetime and will expire 110 after a negotiated amount of time. Local policy at the compositor 111 may in turn define hard-state for this event package. That is, the 112 steady-state of this event package in the absence of any other 113 soft-state provided through the PUBLISH method. In the generic 114 sense, a UAC which publishes event state is labelled an Event 115 Publication Agent (EPA). For presence in particular, this is the 116 familiar PUA role as defined in [7]. The entity which processes the 117 PUBLISH request is known as a Event State Compositor (ESC). For 118 presence in particular, this is the familiar PA role. 120 Event state publication inherently involves at least two parties: the 121 source of the publication and the target of the publication. The 122 source of the publication is naturally represented as an 123 address-of-record (AOR). For some types of event state, namely 124 presence, the target of the publication may not sufficiently be 125 represented by an address-of-record (AOR) alone. Rather, the target 126 is a combination of both an AOR and a unique identifier which acts to 127 represent one of N possible sections of an overall event state for 128 that AOR. In this specification, these sections are referred to as 129 event state segments. In the context of presence publication, the 130 event state segment is nothing more than the presence tuple 131 associated with the presentity (AOR). It is the role of the 132 compositor to aggregate these segments into a complete event state 133 which is presented to the subscribers of that event state. This 134 composition logic is a matter of local policy. For some event 135 packages, there is no natural decomposition of event state into these 136 segments and for these packages, an AOR is sufficient to identify the 137 target of the publish. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [3]. 145 In addition to the terminology of RFC 3265 [2], this document 146 introduces some new concepts: 148 Event Publication Agent (EPA): The UAC which issues a PUBLISH 149 request to publish event state. 151 Event State Compositor (ESC): The UAS which processes PUBLISH 152 requests and composites the event state. It is assumed that there 153 is a tight coupling between the ESC which receives the PUBLISH 154 requests and the state agent which issues appropriate NOTIFY 155 requests based on this change in event state. The interface 156 between these two components is out-of-scope for this 157 specification. 159 Event State Segment: The EPA may publish event state that is 160 divided into individual segments. For the presence publication 161 case, these segments are the individual tuples in the presence 162 document. In the generic case, this document will refer to these 163 segments as event state segments. 165 3. Constructing the PUBLISH Request 167 PUBLISH requests create, remove, and modify event state. A PUBLISH 168 request can create new event state in the state agent, associating 169 this event state with an address-of-record and optionally with a 170 unique identifier for segments of event state being published. 171 Publication on behalf of a particular address-of-record may also be 172 performed by a suitably authorized third party. To determine the 173 current published state for a particular address-of-record, the 174 client MAY create a subscription for this address-of-record and event 175 package using the SUBSCRIBE/NOTIFY mechanism of RFC3265. 177 Note that in the case the event state is segmented, each segment 178 logically represents an independent publication that may be added, 179 removed, modified, and expired separately. For presence publication, 180 this means each tuple in the PIDF document in the PUBLISH request is 181 logically a separate publication that may be manipulated 182 independently even though they are grouped together in the same PIDF 183 document initially. 185 Except as noted, the construction of the PUBLISH request and the 186 behavior of clients sending a PUBLISH request is identical to the 187 general UAC behavior described in Section 8.1 and Section 17.1 of RFC 188 3261 [1]. 190 A PUBLISH request does not establish a dialog. A UAC MAY include a 191 Route header field in a PUBLISH request based on a pre-existing route 192 set as described in Section 8.1 of RFC3261. The Record-Route header 193 field has no meaning in PUBLISH requests or responses, and MUST be 194 ignored if present. In particular, the UAC MUST NOT create a new 195 route set based on the presence or absence of a Record-Route header 196 field in any response to a PUBLISH request. The PUBLISH request MUST 197 NOT contain a Contact header. 199 The following header fields MUST be included in a PUBLISH request: 201 Request-URI: The Request-URI initially contains the address-of-record 202 whose publication is to be created, removed, or modified. Unlike 203 the REGISTER request, the Request-URI SHOULD contain a SIP(S) URI 204 with a username. The address-of-record MUST be a SIP URI or SIPS 205 URI. 207 To: The To header field contains the address of record whose 208 publication is to be created, removed, or modified. The To header 209 field and the Request-URI field are typically the same. This 210 address-of-record MUST be a SIP URI or SIPS URI. 212 From: The From header field contains the address-of-record of the 213 person responsible for the publication. The value is the same as 214 the To header field unless the request is a third- party 215 publication. 217 Call-ID: All publications from an EPA MAY use the same Call-ID header 218 field value for publications sent to a particular state agent. 220 CSeq: An EPA MUST increment the CSeq value by one for each PUBLISH 221 request with the same Call-ID. Unlike REGISTER requests, the 222 Call-ID and CSeq are not directly used for ordering of PUBLISH 223 requests. 225 Event: PUBLISH requests MUST contain a single Event header field. 226 This value indicates the event package which this request is 227 publishing state for. 229 Expires: PUBLISH requests SHOULD contain a single Expires header 230 field. This value indicates the lifetime of the event state being 231 published by this request. A special value of "0" indicates the 232 removal of any prior soft-state established by a prior PUBLISH 233 request from this UAC. 235 The body of the PUBLISH request contains the event state that the 236 client wishes to publish. The content format and semantics are 237 dependent on the event package identified in the Event header. Any 238 event package which makes use of the PUBLISH mechanism MUST describe 239 these semantics and MUST prescribe a default, mandatory to implement 240 format. This document defines the semantics of the presence 241 publication requests (event package "presence") when the CPIM PIDF 242 [5] presence document format is used. 244 4. Requirements of the body of a PUBLISH request 246 In order to satisfy the requirements of [4], the body of the PUBLISH 247 request must fulfill several requirements as well. Any application 248 of the PUBLISH mechanism for a given event package MUST support a 249 Content-Type which fulfills these requirements. For presence 250 publication, it will be demonstrated how these requirements may be 251 fulfilled using the CPIM PIDF presence format in [5] within a PUBLISH 252 request. A PUA which uses PUBLISH to publish presence state to the 253 PA MUST support the CPIM PIDF presence format. 255 The content type MUST provide a way to indicate an ordering of 256 publication requests. For example, the timestamp element in PIDF 257 provides a temporal ordering of presence state changes that allows 258 the Event State Compositor (ESC) to properly order PUBLISH 259 requests. When used as the content of a PUBLISH request, the PUA 260 MUST supply a timestamp element for every presence tuple present 261 in the PIDF document. 263 The content type MUST provide a way to publish partial state for 264 an event package. The intention is to allow each device or client 265 for an address-of-record to publish event state independently. To 266 accomplish this, the event state that is published by these 267 devices must be allowed to be only a portion of the complete state 268 that the state agent advertises for that AOR. For example, a PUA 269 can publish presence state for just a subset of the tuples that 270 may be composited into the presence document that watchers receive 271 in a NOTIFY. The mechanism by which the ESC aggregates this 272 information is a matter of local policy. 274 If the content type allows for event state segments to be 275 represented, the content type MUST provide a means to uniquely 276 identify each unique segment. For example, the CPIM PIDF presence 277 document provides a tuple ID to distinguish the segments of the 278 presence document associated with the encompassing presentity. 280 As with any other SIP message, the PUBLISH mechanism MAY use the 281 content indirection mechanism defined in [6]. There are no 282 additional requirements or restrictions on content indirection as 283 applied to the PUBLISH request. Content indirection is a useful 284 mechanism for communicating large event state information that cannot 285 be carried directly within the SIP signaling (PUBLISH request). 287 5. Creating Initial Publication Soft-State 289 The PUBLISH request created by the EPA and sent to the Event State 290 Compositor (ESC) establishes soft-state in the state agent for the 291 event package indicated in the request and bound to the 292 address-of-record in the To header of the request. Additionally, the 293 PUBLISH request may publish event state that is further sub-divided 294 into segments of event state that may be manipulated independently. 295 As an example, presence publication using the CPIM PIDF format may 296 manipulate individual tuples related to a common presentity. 298 Once the initial PUBLISH request has been processed by the ESC, the 299 EPA MAY send subsequent PUBLISH requests to refresh, modify, or 300 delete the publication state established by the first PUBLISH 301 request. These operations will be described in subsequent sections. 303 EPAs MUST NOT send a new PUBLISH request (not a re-transmission) 304 until they have received a final response from the state agent for 305 the previous one or the previous PUBLISH request has timed out. 307 6. Setting the Expiration Interval of Event State 309 When a client sends a PUBLISH request, it SHOULD suggest an 310 expiration interval that indicates how long the client would like the 311 publication to be valid. The actual duration of the soft state is 312 defined by local policy at the ESC. The expiration value is 313 presented in the Expires header of the PUBLISH request. If an 314 Expires header is not present, the client is indicating its desire 315 for the server to choose. It is RECOMMENDED that the PA use a value 316 of 3600 seconds (1 hour) for this default expiration value in the 317 case of presence publication. The default value is generally event 318 package specific. 320 7. Removing Event State 322 PUBLISH establishes soft state which expires unless refreshed. This 323 event state may also be explicitly removed. A UA requests the 324 immediate removal of event state by specifying an Expires value of 325 "0" in the PUBLISH request. Such a request SHOULD NOT contain any 326 body. UAs which support PUBLISH SHOULD support this mechanism for 327 explicitly removing event state. 329 8. Querying the Current Event State 331 The response to a PUBLISH request indicates whether the request was 332 successful or not. In general, the body of a such response will be 333 empty unless the event package defines explicit meaning for such a 334 body. There is no such meaning for a response to a presence 335 publication when the document format used is CPIM PIDF. 337 To query the event state that the state agent in fact publishes, the 338 client may SUBSCRIBE to the event package for which it has sent a 339 PUBLISH, indicating the same address-of-record in the To header. An 340 Expires header value of "0" may be used in this SUBSCRIBE request to 341 do a one-time fetch of this event state as defined in RFC3265. 343 9. Refreshing Event State 345 Each EPA is responsible for refreshing the publications that it has 346 previously established. An EPA MAY choose to refresh the publication 347 established by another EPA for the same address-of-record. The 348 authorization policy of the ESC. 350 The 200 (OK) response from the state agent MUST contain an Expires 351 header indicating the expiration time interval for the publication. 352 The EPA then issues a PUBLISH request for each of its publications 353 before the expiration interval has elapsed. 355 If an EPA receives a 423 (Interval Too Brief) response to a PUBLISH 356 request, it MAY retry the publication after changing the expiration 357 interval in the Expires header to be equal to or greater than the 358 expiration interval within the Min-Expires header field of the 359 423(Interval Too Brief) response. 361 10. Processing PUBLISH Requests 363 The Event State Compositor (ESC) is a UAS that responds to PUBLISH 364 requests and maintains a list of publications for a given 365 address-of-record. The ESC MUST ignore the Record-Route header field 366 if it is included in a PUBLISH request. The ESC MUST NOT include a 367 Record-Route header field in any response to a PUBLISH request. 369 The ESC has to know (for example, through configuration) the set of 370 domain(s) for which it maintains event state. PUBLISH requests MUST 371 be processed in the order that they are received. PUBLISH requests 372 MUST also be processed atomically, meaning that a particular PUBLISH 373 request is either processed completely or not at all. 375 When receiving a PUBLISH request, the ESC follows these steps: 377 1. The ESC inspects the Request-URI to determine whether this 378 request is for a domain supported by the ESC. If not, the ESC 379 SHOULD proxy the request to the addressed domain. 381 2. To guarantee that the ESC supports any necessary extensions, the 382 ESC MUST process the Require header field values as described for 383 UASs in Section 8.2.2 of RFC3261. 385 3. An ESC SHOULD authenticate the UAC. Mechanisms for the 386 authentication of SIP user agents are described in Section 22 of 387 RFC3261. 389 4. The ESC SHOULD determine if the authenticated user is authorized 390 to publish for this address-of-record. If the authenticated user 391 is not authorized to publish, the ESC MUST return a 403 392 (Forbidden). This authorization may take into account 3rd party 393 publication of event state. 395 5. The ESC extracts the address-of-record from the To header field 396 of the request. If the address-of-record is not valid for the 397 domain in the Request-URI, the ESC MUST send a 404 (Not Found) 398 response and skip the remaining steps. The URI MUST then be 399 converted to a canonical form. To do that, all URI parameters 400 MUST be removed (including the user-param), and any escaped 401 characters MUST be converted to their unescaped form. The result 402 serves as an index into the list of publications. 404 6. The ESC examines the Event header of the PUBLISH request. If the 405 Event header is missing or contains an event package which the 406 ESC does not support, the ESC MUST respond to the PUBLISH request 407 with a 489 (Bad Event) response. 409 7. The ESC now processes the Expires header value from the PUBLISH 410 request. 412 * If the request has an Expires header field, that value MUST be 413 taken as the requested expiration. 415 * Else, a locally-configured default value MUST be taken as the 416 requested expiration. 418 * The ESC MAY choose an expiration less than the requested 419 expiration interval. If and only if the requested expiration 420 interval is greater than zero AND less than a ESC-configured 421 minimum, the ESC MAY reject the publication with a response of 422 423 (Interval Too Brief). This response MUST contain a 423 Min-Expires header field that states the minimum expiration 424 interval the ESC is willing to honor. It then skips the 425 remaining steps. 427 8. The ESC may then process the body of the PUBLISH request (the 428 actual event state) 430 * For each publication, the ESC will record the target of the 431 publication (To URI), the source of the publication (From 432 URI), and the version of the publication. This version 433 information must be present in the body of the PUBLISH 434 request. In the presence publication application, this 435 information will come from the timestamp element associated 436 with each presence tuple. 438 * If the version of the event state present in the PUBLISH 439 request is older than the current version known by the ESC, 440 the ESC MUST return a 494 (Out of Sync) response and MUST NOT 441 update the event state for this AOR. This is to handle 442 out-of-order or stale PUBLISH requests. To recover from this 443 error, the client SHOULD determine the current version of the 444 event state at the server by sending a SUBSCRIBE request to 445 the server and re-issue the PUBLISH request if the event state 446 changes again. 448 * The processing of the PUBLISH request must be atomic. If 449 internal errors (such as the inability to access a back-end 450 database) occur before processing is complete, no portion of 451 the PUBLISH document must be published and the ESC MUST fail 452 with a 500 (Server Error) response. 454 9. The ESC returns a 200 (OK) response. The response MUST contain 455 an Expires header indicating the expiration interval chosen by 456 the ESC. The state agent associated with this ESC may then issue 457 appropriate NOTIFY requests to any watchers of this event state. 458 The timing between the receipt of the PUBLISH request and the 459 issuance of NOTIFY requests is implementation dependent and may 460 vary according to throttling policies at the state agent. 462 11. Syntax 464 11.1 New Method 466 The following is the BNF definition for the PUBLISH method. As with 467 all other SIP methods, the method name is case sensitive. 469 PUBLISHm = %x50.55.42.4C.49.53.48 ; PUBLISH in caps. 471 Tables 1 and 2 extend Tables 2 and 3 of RFC 3261 [1] by adding an 472 additional column, defining the header fields that can be used in 473 PUBLISH requests and responses. 475 Header Field where proxy PUBLISH 476 __________________________________________ 477 Accept R - 478 Accept 2xx - 479 Accept 415 m* 480 Accept-Encoding R - 481 Accept-Encoding 2xx - 482 Accept-Encoding 415 m* 483 Accept-Language R - 484 Accept-Language 2xx - 485 Accept-Language 415 m* 486 Alert-Info R - 487 Alert-Info 180 - 488 Allow R o 489 Allow 2xx o 490 Allow r o 491 Allow 405 m 492 Authentication-Info 2xx o 493 Authorization R o 494 Call-ID c r m 495 Call-Info ar o 496 Contact R - 497 Contact 1xx - 498 Contact 2xx - 499 Contact 3xx o 500 Contact 485 o 501 Content-Disposition o 502 Content-Encoding o 503 Content-Language o 504 Content-Length ar t 505 Content-Type * 506 CSeq c r m 507 Date a o 508 Event a m 509 Error-Info 300-699 a o 510 Expires o 511 From c r m 512 In-Reply-To R o 513 Max-Forwards R amr m 514 Organization ar o 516 Table 1: Summary of header fields, A--O 518 Header Field where proxy PUBLISH 519 __________________________________________ 521 Priority R ar o 522 Proxy-Authenticate 407 ar m 523 Proxy-Authenticate 401 ar o 524 Proxy-Authorization R dr o 525 Proxy-Require R ar o 526 Record-Route ar - 527 Reply-To o 528 Require ar c 529 Retry-After 404,413,480,486 o 530 500,503 o 531 600,603 o 532 Route R adr o 533 Server r o 534 Subject R o 535 Timestamp o 536 To c(1) r m 537 Unsupported 420 o 538 User-Agent o 539 Via R amr m 540 Via rc dr m 541 Warning r o 542 WWW-Authenticate 401 ar m 543 WWW-Authenticate 407 ar o 545 Table 2: Summary of header fields, P--Z 547 11.2 New Response Code 548 11.2.1 "494 Out Of Sync" Response Code 550 The 494 event response is added to the "Client-Error" header field 551 definition. "494 Out of Sync" is used to indicate that the server 552 detected that the event state that the client is trying to publish is 553 out of sync (stale) relative to the event state that the server has. 554 The version information in the PUBLISH body is older than the version 555 information that the server maintains for the corresponding event and 556 AOR. 558 12. Examples 560 The following section shows an example of the usage of the PUBLISH 561 method in the case of publishing the presence document from a 562 presence user agent to a presence agent. The watcher in this case is 563 watching the PUA's presentity. The PUA will SUBSCRIBE to its own 564 presence to see the composite presence state exposed by the PA. This 565 is an optional but likely step for the PUA. 567 PUA PA WATCHER 568 (EPA) (ESC) 569 | | | 570 | | <---- M1: SUBSCRIBE --- | 571 | | | 572 | | ----- M2: 200 OK -----> | 573 | | | 574 | | ----- M3: NOTIFY -----> | 575 | | | 576 | | <---- M4: 200 OK ------ | 577 | | | 578 | --- M5: SUBSCRIBE --> | | 579 | | | 580 |<--- M6: 200 OK --> | | 581 | | | 582 |<--- M7: NOTIFY ----- | | 583 | | | 584 | --- M8: 200 OK --> | | 585 | | | 586 | --- M9: PUBLISH ----> | | 587 | | | 588 | <-- M10: 200 OK ---- | | 589 | | | 590 | | ----- M11: NOTIFY ----> | 591 | | | 592 | | <---- M12: 200 OK ----- | 593 | | | 594 | | | 595 |<---- M13: NOTIFY ---- | | 596 | | | 597 |----- M14: 200 OK --> | | 598 | | | 600 Message flow: 602 M1: The watcher initiates a new subscription to the 603 presentity@domain.com's presence agent. 605 SUBSCRIBE sip:presentity@domain.com SIP/2.0 606 Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bKnashds7 607 To: 608 From: ;tag=12341234 609 Call-ID: 12345678@10.0.0.1 610 CSeq: 1 SUBSCRIBE 611 Expires: 3600 612 Event: presence 613 Contact: 614 Content-Length: 0 616 M2: The presence agent for presentity@domain.com processes the 617 subscription request and creates a new subscription. A 200 (OK) 618 response is sent to confirm the subscription. 620 SIP/2.0 200 OK 621 Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bKnashds7 622 To: ;tag=abcd1234 623 From: ;tag=12341234 624 Call-ID: 12345678@10.0.0.1 625 CSeq: 1 SUBSCRIBE 626 Contact: 627 Expires: 3600 628 Content-Length: 0 630 M3: In order to complete the process, the presence agent sends the 631 watcher a NOTIFY with the current presence state of the 632 presentity. 634 NOTIFY sip:presentity@domain.com SIP/2.0 635 Via: SIP/2.0/UDP pa.domain.com;branch=z9hG4bK8sdf2 636 To: ;tag=12341234 637 From: ;tag=abcd1234 638 Call-ID: 12345678@10.0.0.1 639 CSeq: 1 NOTIFY 640 Event: presence 641 Subscription-State: active; expires=3599 642 Content-Type: application/cpim-pidf+xml 643 Content-Length: ... 645 646 648 649 650 open 651 652 2003-02-01T16:49:29Z 653 654 655 656 open 657 658 2003-02-01T12:21:29Z 659 660 662 M4: The watcher confirms receipt of the NOTIFY request. 664 SIP/2.0 200 OK 665 Via: SIP/2.0/UDP pa.domain.com;branch=z9hG4bK8sdf2 666 To: ;tag=12341234 667 From: ;tag=abcd1234 668 Call-ID: 12345678@10.0.0.1 669 CSeq: 1 NOTIFY 670 Contact: 672 M5: To view its composite presence state, the PUA issues a SUBSCRIBE 673 to the PA for itself. 675 SUBSCRIBE sip:presentity@domain.com SIP/2.0 676 Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bKjjsdfj 677 To: 678 From: ;tag=43214321 679 Call-ID: 87654321@10.0.0.2 680 CSeq: 1 SUBSCRIBE 681 Expires: 3600 682 Event: presence 683 Contact: 684 Content-Length: 0 686 M6: The presence agent for presentity@domain.com processes the 687 subscription request and creates a new subscription. A 200 (OK) 688 response is sent to confirm the subscription. 690 SIP/2.0 200 OK 691 Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bKjjsdfj 692 To: ;tag=abcd1235 693 From: ;tag=43214321 694 Call-ID: 87654321@10.0.0.2 695 CSeq: 1 SUBSCRIBE 696 Contact: 697 Expires: 3600 698 Content-Length: 0 700 M7: In order to complete the process, the presence agent sends the 701 PUA a NOTIFY with the current presence state of the presentity. 703 NOTIFY sip:presentity@domain.com SIP/2.0 704 Via: SIP/2.0/UDP pa.domain.com;branch=z9hG4bK8sdfk 705 To: ;tag=abcd1235 706 From: ;tag=43214321 707 Call-ID: 87654321@10.0.0.2 708 CSeq: 1 NOTIFY 709 Event: presence 710 Subscription-State: active; expires=3599 711 Content-Type: application/cpim-pidf+xml 712 Content-Length: ... 714 715 717 718 719 open 720 721 2003-02-01T16:49:29Z 722 723 724 725 open 726 727 2003-02-01T12:21:29Z 728 729 731 M9: A presence user agent for the presentity detects a change in the 732 user's presence state. It initiates a PUBLISH to the presentity's 733 presence agent in order to update it with the new presence 734 information. The timestamp element is updated to indicate the 735 time of the change. The Expires header indicates the desired 736 duration of this soft-state. The "entity" attribute of the 737 presence element in the PIDF document matches the To AOR. 739 PUBLISH sip:presentity@domain.com SIP/2.0 740 Via: SIP/2.0/UDP pua.domain.com;branch=z9hG4bK652hsge 741 To: ;tag=1a2b3c4d 742 From: ;tag=1234wxyz 743 Call-ID: 81818181@pua.domain.com 744 CSeq: 1 PUBLISH 745 Expires: 3600 746 Event: presence 747 Content-Type: application/cpim-pidf+xml 748 Content-Length: ... 750 751 753 754 755 closed 756 757 2003-02-01T17:00:19Z 758 759 761 M10: The presence agent receives, and accepts the presence 762 information. The published data is incorporated into the 763 presentity's presence document. A 200 (OK) response is sent to 764 confirm the publication. 766 SIP/2.0 200 OK 767 Via: SIP/2.0/UDP pua.domain.com;branch=z9hG4bK652hsge 768 To: ;tag=1a2b3c4d 769 From: ;tag=1234wxyz 770 Call-ID: 81818181@pua.domain.com 771 CSeq: 1 PUBLISH 772 Expires: 1800 774 M11: The presence agent determines that a reportable change has been 775 made to the presentity's presence document, and sends another 776 notification to those watching the presentity to update their 777 information regarding the presentity's current presence status. 779 NOTIFY sip:presentity@domain.com SIP/2.0 780 Via: SIP/2.0/UDP presence.domain.com;branch=z9hG4bK4cd42a 781 To: ;tag=12341234 782 From: ;tag=abcd1234 783 Call-ID: 12345678@10.0.0.1 784 CSeq: 2 NOTIFY 785 Event: presence 786 Subscription-State: active; expires=3400 787 Content-Type: application/cpim-pidf+xml 788 Content-Length: ... 790 791 793 794 795 closed 796 797 2003-02-01T17:00:19Z 798 799 800 801 open 802 803 2003-02-01T12:21:29Z 804 805 807 M12: The watcher confirms receipt of the NOTIFY request. 809 SIP/2.0 200 OK 810 Via: SIP/2.0/UDP presence.domain.com;branch=z9hG4bK4cd42a 811 To: ;tag=12341234 812 From: ;tag=abcd1234 813 Call-ID: 12345678@10.0.0.1 814 CSeq: 2 NOTIFY 815 Content-Length: 0 817 M13: The presence agent also sends a NOTIFY to the PUA. 819 NOTIFY sip:presentity@domain.com SIP/2.0 820 Via: SIP/2.0/UDP presence.domain.com;branch=z9hG4bK4cd42b 821 To: ;tag=abcd1235 822 From: ;tag=43214321 823 Call-ID: 87654321@10.0.0.2 824 CSeq: 2 NOTIFY 825 Event: presence 826 Subscription-State: active; expires=3400 827 Content-Type: application/cpim-pidf+xml 828 Content-Length: ... 830 831 833 834 835 closed 836 837 2003-02-01T17:00:19Z 838 839 840 841 open 842 843 2003-02-01T12:21:29Z 844 845 847 M14: The PUA confirms receipt of the NOTIFY request. 849 SIP/2.0 200 OK 850 Via: SIP/2.0/UDP presence.domain.com;branch=z9hG4bK4cd42b 851 To: ;tag=abcd1235 852 From: ;tag=43214321 853 Call-ID: 87654321@10.0.0.2 854 CSeq: 2 NOTIFY 856 13. IANA Considerations 858 This document registers a new response code. This response code is 859 defined by the following information, which is to be added to the 860 method and response-code sub-registry under http://www.iana.org/ 861 assignments/sip-parameters. Response Code Number: 494 Default 862 Reason Phrase: Out Of Sync 864 14. Security Considerations 866 The state agent SHOULD authenticate the Event Publication Agent 867 (EPA), and SHOULD apply authorization policies. The composition 868 model makes no assumptions that all input sources for a compositor 869 (ESC) are on the same network, or in the same administrative domain. 871 The ESC should throttle incoming publications and the corresponding 872 notifications resulting from the changes in event state. As a first 873 step, careful selection of default Expires: values for the supported 874 event packages at a ESC can help limit refreshes of event state. 875 Additional throttling and debounce logic at the ESC is advisable to 876 further reduce the notification traffic produced as a result of a 877 PUBLISH method. 879 Integrity protection and privacy of the PUBLISH requests can be 880 ensured using the S/MIME mechanisms outlined in section 23 of 881 RFC3261. Integrity protection of the To, From, Call-ID, CSeq, Event, 882 Route, and Expires headers should be done at a minimum. 884 If the ESC receives a PUBLISH request which is integrity protected 885 using a security association that is not with the ESC (for example, 886 end-to-end S/MIME integrity protection), the state agent coupled with 887 the ESC MUST NOT modify the event state before exposing it to the 888 watchers of this event state in a NOTIFY request(s). This is to 889 preserve the end-to-end integrity of the event state. 891 15. Open Issues 893 o Should the version information of the publication request be 894 carried explicitly in a header of the request, or is sufficient to 895 rely on the body for this information? 897 o Should the segments of event state (presence tuples) be sent in 898 separate PUBLISH requests or is it enough to treat these as 899 implicitly separate publication requests? 901 o Should the PUBLISH mechanism be overloaded to publish 902 authorization information (ACLs) for the event state as well? 904 o Does end-to-end S/MIME integrity protection make sense when an 905 event compositor is used? 907 Normative References 909 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 910 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 911 Session Initiation Protocol", RFC 3261, June 2002. 913 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 914 Notification", RFC 3265, June 2002. 916 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 917 Levels", BCP 14, RFC 2119, March 1997. 919 [4] Campbell, Olson, Peterson, Rosenberg and Stucker, "SIMPLE 920 Presence Publication Requirements", 921 draft-ietf-simple-publish-reqs-00 (work in progress), February 922 2003. 924 [5] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A. and W. Carr, 925 "Common Presence and Instant Messaging (CPIM) Presence 926 Information Data Format", draft-ietf-impp-cpim-pidf-07 (work in 927 progress), May 2002. 929 [6] Olson, "A Mechanism for Content Indirection in SIP Messages", 930 draft-olson-sip-content-indirect-mech-01 (work in progress), 931 August 2002. 933 [7] Rosenberg, "A Presence Event Package for the Session Initiation 934 Protocol (SIP)", draft-ietf-simple-presence-10 (work in 935 progress), January 2003. 937 Authors' Addresses 939 Ben Campbell 940 dynamicsoft 941 5100 Tennyson Parkway 942 Suite 1200 943 Plano, TX 75025 944 US 946 EMail: bcampbell@dynamicsoft.com 947 Sean Olson 948 Microsoft 949 One Microsoft Way 950 Redmond, WA 98052 951 US 953 Phone: +1-425-707-2846 954 EMail: seanol@microsoft.com 955 URI: http://www.microsoft.com/rtc 957 Jon Peterson 958 NeuStar, Inc. 959 1800 Sutter St 960 Suite 570 961 Concord, CA 94520 962 US 964 Phone: +1-925-363-8720 965 EMail: jon.peterson@neustar.biz 966 URI: http://www.neustar.biz 968 Jonathan Rosenberg 969 dynamicsoft 970 72 Eagle Rock Avenue 971 First Floor 972 East Hanover, NJ 07936 973 US 975 EMail: jdrosen@dynamicsoft.com 977 Brian Stucker 978 Nortel Networks, Inc. 979 2380 Performance Drive 980 Richardson, TX 75082 981 US 983 EMail: bstucker@nortelnetworks.com 985 Intellectual Property Statement 987 The IETF takes no position regarding the validity or scope of any 988 intellectual property or other rights that might be claimed to 989 pertain to the implementation or use of the technology described in 990 this document or the extent to which any license under such rights 991 might or might not be available; neither does it represent that it 992 has made any effort to identify any such rights. Information on the 993 IETF's procedures with respect to rights in standards-track and 994 standards-related documentation can be found in BCP-11. Copies of 995 claims of rights made available for publication and any assurances of 996 licenses to be made available, or the result of an attempt made to 997 obtain a general license or permission for the use of such 998 proprietary rights by implementors or users of this specification can 999 be obtained from the IETF Secretariat. 1001 The IETF invites any interested party to bring to its attention any 1002 copyrights, patents or patent applications, or other proprietary 1003 rights which may cover technology that may be required to practice 1004 this standard. Please address the information to the IETF Executive 1005 Director. 1007 Full Copyright Statement 1009 Copyright (C) The Internet Society (2003). All Rights Reserved. 1011 This document and translations of it may be copied and furnished to 1012 others, and derivative works that comment on or otherwise explain it 1013 or assist in its implementation may be prepared, copied, published 1014 and distributed, in whole or in part, without restriction of any 1015 kind, provided that the above copyright notice and this paragraph are 1016 included on all such copies and derivative works. However, this 1017 document itself may not be modified in any way, such as by removing 1018 the copyright notice or references to the Internet Society or other 1019 Internet organizations, except as needed for the purpose of 1020 developing Internet standards in which case the procedures for 1021 copyrights defined in the Internet Standards process must be 1022 followed, or as required to translate it into languages other than 1023 English. 1025 The limited permissions granted above are perpetual and will not be 1026 revoked by the Internet Society or its successors or assignees. 1028 This document and the information contained herein is provided on an 1029 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1030 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1031 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1032 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1033 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1035 Acknowledgement 1037 Funding for the RFC Editor function is currently provided by the 1038 Internet Society.