idnits 2.17.1 draft-ietf-sip-publish-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 28, 2004) is 7273 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) -- Looks like a reference, but probably isn't: 'RFCYYYY' on line 961 ** Obsolete normative reference: RFC 3265 (ref. '1') (Obsoleted by RFC 6665) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '3') ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (ref. '8') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2633 (ref. '9') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '13') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG A. Niemi, Ed. 3 Internet-Draft Nokia 4 Expires: November 26, 2004 May 28, 2004 6 An Event State Publication Extension to the Session Initiation 7 Protocol (SIP) 8 draft-ietf-sip-publish-04 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 26, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes an extension to the Session Initiation 40 Protocol (SIP) for publishing event state used within the SIP Events 41 framework. The first application of this extension is for the 42 publication of presence information. 44 The mechanism described in this document can be extended to support 45 publication of any event state for which there exists an appropriate 46 event package. It is not intended to be a general-purpose mechanism 47 for transport of arbitrary data, as there are better-suited 48 mechanisms for this purpose. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Definitions and Document Conventions . . . . . . . . . . . . 4 54 3. Overall Operation . . . . . . . . . . . . . . . . . . . . . 5 55 4. Constructing PUBLISH Requests . . . . . . . . . . . . . . . 6 56 4.1 Identification of Published Event State . . . . . . . . . 7 57 4.2 Creating Initial Publication . . . . . . . . . . . . . . . 8 58 4.3 Refreshing Event State . . . . . . . . . . . . . . . . . . 9 59 4.4 Modifying Event State . . . . . . . . . . . . . . . . . . 10 60 4.5 Removing Event State . . . . . . . . . . . . . . . . . . . 10 61 5. Processing PUBLISH Responses . . . . . . . . . . . . . . . . 11 62 6. Processing PUBLISH Requests . . . . . . . . . . . . . . . . 11 63 7. Processing OPTIONS Requests . . . . . . . . . . . . . . . . 14 64 8. Use of Entity-tags in PUBLISH . . . . . . . . . . . . . . . 14 65 8.1 General Notes . . . . . . . . . . . . . . . . . . . . . . 14 66 8.2 Client Usage . . . . . . . . . . . . . . . . . . . . . . . 15 67 8.3 Server Usage . . . . . . . . . . . . . . . . . . . . . . . 15 68 9. Controlling the Rate of Publication . . . . . . . . . . . . 15 69 10. Considerations for Event Packages using PUBLISH . . . . . . 16 70 10.1 PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . 16 71 10.2 PUBLISH Response Bodies . . . . . . . . . . . . . . . . 16 72 10.3 Multiple Sources for Event State . . . . . . . . . . . . 17 73 10.4 Event State Segmentation . . . . . . . . . . . . . . . . 17 74 10.5 Rate of Publication . . . . . . . . . . . . . . . . . . 18 75 11. Protocol Element Definitions . . . . . . . . . . . . . . . . 18 76 11.1 New Methods . . . . . . . . . . . . . . . . . . . . . . 18 77 11.1.1 PUBLISH Method . . . . . . . . . . . . . . . . . . . 18 78 11.2 New Response Codes . . . . . . . . . . . . . . . . . . . 20 79 11.2.1 "412 Conditional Request Failed" Response Code . . . 20 80 11.3 New Header Fields . . . . . . . . . . . . . . . . . . . 20 81 11.3.1 "SIP-ETag" Header Field . . . . . . . . . . . . . . 21 82 11.3.2 "SIP-If-Match" Header Field . . . . . . . . . . . . 21 83 12. Augmented BNF Definitions . . . . . . . . . . . . . . . . . 21 84 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 85 13.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . 22 86 13.2 Response Codes . . . . . . . . . . . . . . . . . . . . . 22 87 13.3 Header Field Names . . . . . . . . . . . . . . . . . . . 22 88 14. Security Considerations . . . . . . . . . . . . . . . . . . 23 89 14.1 Access Control . . . . . . . . . . . . . . . . . . . . . 23 90 14.2 Denial of Service Attacks . . . . . . . . . . . . . . . 23 91 14.3 Replay Attack . . . . . . . . . . . . . . . . . . . . . 23 92 14.4 Man in the Middle Attacks . . . . . . . . . . . . . . . 24 93 14.5 Confidentiality . . . . . . . . . . . . . . . . . . . . 24 94 15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 96 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 97 18. Document Change History . . . . . . . . . . . . . . . . . . 33 98 18.1 Changes since "draft-ietf-sip-publish-03" . . . . . . . 33 99 18.2 Changes since "draft-ietf-sip-publish-02" . . . . . . . 34 100 18.3 Changes since "draft-ietf-sip-publish-01" . . . . . . . 34 101 18.4 Changes since "draft-ietf-sip-publish-00" . . . . . . . 35 102 18.5 Changes since "draft-ietf-simple-publish-01" . . . . . . 35 103 18.6 Changes since "draft-ietf-simple-publish-00" . . . . . . 36 104 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 105 19.1 Normative References . . . . . . . . . . . . . . . . . . . 37 106 19.2 Informative References . . . . . . . . . . . . . . . . . . 37 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . 38 108 Intellectual Property and Copyright Statements . . . . . . . 39 110 1. Introduction 112 This specification provides a framework for the publication of event 113 state from a user agent to an entity that is responsible for 114 compositing this event state and distributing it to interested 115 parties through the SIP Events [1] framework. 117 In addition to defining an event publication framework, this 118 specification defines a concrete usage of that framework for the 119 publication of presence state [2] by a presence user agent [3] to a 120 presence compositor, which has a tightly coupled relationship with 121 the presence agent [1]. 123 The requirements and model for presence publication are documented in 124 [10]. This specification will address each of those requirements. 126 The mechanism described in this document can be extended to support 127 publication of any event state for which there exists an appropriate 128 event package as defined in [1]. For instance, an application of SIP 129 events for message waiting indications [11] might choose to collect 130 the statuses of voice-mail boxes across a set of user agents using 131 the PUBLISH mechanism. The compositor in such an application would 132 then be responsible for collecting and distributing this state to the 133 subscribers of the event package. 135 Each application that makes use of the PUBLISH mechanism in the 136 publication of event state will need to adhere to the guidelines set 137 in Section 10. The mechanism described in this document is not 138 intended to be a general-purpose mechanism for transport of arbitrary 139 data, as there are better-suited mechanisms for this purpose. 141 2. Definitions and Document Conventions 143 In addition to the definitions of RFC 2778 [3], RFC 3265 [1], and RFC 144 3261 [4], this document introduces some new concepts: 146 Event State: State information for a resource, associated with an 147 event package and an address-of-record. 149 Event Publication Agent (EPA): The User Agent Client (UAC) that 150 issues PUBLISH requests to publish event state. 152 Event State Compositor (ESC): The User Agent Server (UAS) that 153 processes PUBLISH requests, and is responsible for compositing 154 event state into a complete, composite event state of a resource. 156 Presence Compositor: A type of Event State Compositor that is 157 responsible for compositing presence state for a presentity. 159 Publication: The act of an EPA sending a PUBLISH request to an ESC to 160 publish event state. 162 Event Hard State: The steady-state or default event state of a 163 resource, which the ESC may use in the absence of, or in addition 164 to, soft state publications. 166 Event Soft State: Event state published by an EPA using the PUBLISH 167 mechanism. A protocol element (i.e., an entity-tag) is used to 168 identify a specific soft state entity at the ESC. Soft state has 169 a defined lifetime and will expire after a negotiated amount of 170 time. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in BCP 14, RFC 2119 [5] 175 and indicate requirement levels for compliant implementations. 177 Indented passages such as this one are used in this document to 178 provide additional information and clarifying text. They do not 179 contain descriptions of normative protocol behavior. 181 3. Overall Operation 183 This document defines a new SIP method, PUBLISH, for publishing event 184 state. PUBLISH is similar to REGISTER in that it allows a user to 185 create, modify, and remove state in another entity which manages this 186 state on behalf of the user. Addressing a PUBLISH request is 187 identical to addressing a SUBSCRIBE request. The Request-URI of a 188 PUBLISH request is populated with the address of the resource for 189 which the user wishes to publish event state. The user may in turn 190 have multiple User Agents or endpoints that publish event state. 191 Each endpoint may publish its own unique state, out of which the 192 event state compositor generates the composite event state of the 193 resource. In addition to a particular resource, all published event 194 state is associated with a specific event package. Through a 195 subscription to that event package, the user is able to discover the 196 composite event state of all of the active publications. 198 A User Agent Client (UAC) that publishes event state is labeled an 199 Event Publication Agent (EPA). For presence, this is the familiar 200 Presence User Agent (PUA) role as defined in [2]. The entity that 201 processes the PUBLISH request is known as an Event State Compositor 202 (ESC). For presence, this is the familiar Presence Agent (PA) role 203 as defined in [2]. 205 PUBLISH requests create soft state in the ESC. This event soft state 206 has a defined lifetime and will expire after a negotiated amount of 207 time, requiring the publication to be refreshed by subsequent PUBLISH 208 requests. There may also be event hard state provisioned for each 209 resource for a particular event package. This event state represents 210 the resource state that is present at all times, and does not expire. 211 The ESC may use event hard state in the absence of, or in addition 212 to, event soft state provided through the PUBLISH mechanism. Setting 213 this event hard state or configuring the ESC policy regarding the 214 aggregation of different event state is out of the scope of this 215 specification. 217 The body of a PUBLISH request carries the published event state. In 218 the response to every successful PUBLISH request, the ESC assigns an 219 identifier to the publication in the form of an entity-tag. This 220 identifier is then used by the EPA in any subsequent PUBLISH request 221 that modifies, refreshes or removes the event state of that 222 publication. When event state expires or is explicitly removed, the 223 entity-tag associated with it becomes invalid. A publication for an 224 invalid entity-tag will naturally fail, and the EPA needs to start 225 anew and resend its event state without referencing a previous 226 entity-tag. 228 4. Constructing PUBLISH Requests 230 PUBLISH requests create, modify, and remove event state associated 231 with an address-of-record. A suitably authorized third party may 232 also perform publication on behalf of a particular address-of-record. 234 Except as noted, the construction of the PUBLISH request and the 235 behavior of clients sending a PUBLISH request are identical to the 236 general UAC behavior described in Section 8.1 and Section 17.1 of RFC 237 3261 [4]. 239 If necessary, clients may probe for the support of PUBLISH using the 240 OPTIONS request defined in SIP [4]. The presence of "PUBLISH" in the 241 "Allow" header field in a response to an OPTIONS request indicates 242 support for the PUBLISH method. In addition, the "Allow-Events" 243 header field indicates the supported event packages. 245 Note that it is possible for the OPTIONS request to fork, and 246 consequently return a response from a User Agent other than the 247 ESC. In that case, support for the PUBLISH method may not be 248 appropriately represented for that particular Request-URI. 250 A PUBLISH request does not establish a dialog. A UAC MAY include a 251 Route header field in a PUBLISH request based on a pre-existing route 252 set as described in Section 8.1 of RFC 3261 [4]. The Record-Route 253 header field has no meaning in PUBLISH requests or responses, and 254 MUST be ignored if present. In particular, the UAC MUST NOT create a 255 new route set based on the presence or absence of a Record-Route 256 header field in any response to a PUBLISH request. 258 The PUBLISH request MAY contain a Contact header field, but including 259 one in a PUBLISH request has no meaning in the event publication 260 context and will be ignored by the ESC. An EPA MAY send a PUBLISH 261 request within an existing dialog. In that case, the request is 262 received in the context of any media session or sessions associated 263 with that dialog. 265 Note that while sending a PUBLISH request within an existing 266 dialog is not prohibited, it will typically not result in the 267 expected behavior. Unless the other end of the dialog is also an 268 ESC, it will probably reject the request. 270 EPAs MUST NOT send a new PUBLISH request (not a re-transmission) for 271 the same Request-URI, until they have received a final response from 272 the ESC for the previous one or the previous PUBLISH request has 273 timed out. 275 4.1 Identification of Published Event State 277 Identification of published event state is provided by three pieces 278 of information: Request-URI, event type, and (optionally) an 279 entity-tag. 281 The Request-URI of a PUBLISH request contains enough information to 282 route the request to the appropriate entity per the request routing 283 procedures outlined in RFC 3261 [4]. It also contains enough 284 information to identify the resource whose event state is to be 285 published, but not enough information to determine the type of the 286 published event state. 288 For determining the type of the published event state, the EPA MUST 289 include a single Event header field in PUBLISH requests. The value 290 of this header field indicates the event package for which this 291 request is publishing event state. 293 For each successful PUBLISH request, the ESC will generate and assign 294 an entity-tag and return it in the SIP-ETag header field of the 2xx 295 response. 297 When updating previously published event state, PUBLISH requests MUST 298 contain a single SIP-If-Match header field identifying the specific 299 event state that the request is refreshing, modifying or removing. 300 This header field MUST contain a single entity-tag that was returned 301 by the ESC in the SIP-ETag header field of the response to a previous 302 publication. 304 The PUBLISH request MAY contain a body, which contains event state 305 that the client wishes to publish. The content format and semantics 306 are dependent on the event package identified in the Event header 307 field. 309 The presence of a body and the SIP-If-Match header field determine 310 the specific operation that the request is performing, as described 311 in Table 1. 313 +-----------+-------+---------------+---------------+ 314 | Operation | Body? | SIP-If-Match? | Expires Value | 315 +-----------+-------+---------------+---------------+ 316 | Initial | yes | no | > 0 | 317 | Refresh | no | yes | > 0 | 318 | Modify | yes | yes | > 0 | 319 | Remove | no | yes | 0 | 320 +-----------+-------+---------------+---------------+ 322 Table 1: Publication Operations 324 An 'Initial' publication sets the initial event state for a 325 particular EPA. A 'Refresh' publication refreshes the lifetime of a 326 previous publication, whereas a 'Modify' publication modifies the 327 event state of a previous publication. A 'Remove' publication 328 requests immediate removal of event state. These operations are 329 described in more detail in the following sections. 331 4.2 Creating Initial Publication 333 An initial publication is a PUBLISH request created by the EPA and 334 sent to the ESC that establishes soft state for the event package 335 indicated in the Event header field of the request, and bound to the 336 address in the Request-URI of the request. 338 An initial PUBLISH request MUST NOT contain a SIP-If-Match header 339 field. However, if the EPA expects an appropriate, locally stored 340 entity-tag to still be valid, it SHOULD first try to modify that 341 event state as described in Section 4.4, instead of submitting an 342 initial publication. 344 An initial PUBLISH request MUST contain a body that contains the 345 published event state. 347 An initial PUBLISH request MAY contain a single Expires header field. 348 This value indicates the suggested lifetime of the event state 349 publication. 351 If an Expires header is not present, the EPA is indicating its desire 352 for the ESC to choose. The ESC may lower the suggested lifetime of 353 the publication, but it will never extend it. The Expires header 354 field in a 2xx response to the initial PUBLISH indicates the actual 355 duration for which the publication will remain active. Unless 356 refreshed before this lifetime is exceeded, the publication will 357 expire. 359 4.3 Refreshing Event State 361 An EPA is responsible for refreshing its previously established 362 publications before their expiration interval has elapsed. To 363 refresh a publication, the EPA MUST create a PUBLISH request that 364 includes in a SIP-If-Match header field the entity-tag of the 365 publication to be refreshed. 367 The SIP-If-Match header field containing an entity-tag conditions the 368 PUBLISH request to refresh a specific event state established by a 369 prior publication. If the entity-tag matches previously published 370 event state at the ESC, the refresh succeeds, and the EPA receives a 371 2xx response. 373 Like the 2xx response to an initial PUBLISH request, the 2xx response 374 to a refresh PUBLISH request will contain a SIP-ETag header field 375 with an entity-tag. The EPA MUST store this entity-tag, replacing 376 any existing entity-tag for the refreshed event state. See Section 377 8.2 for more information on the EPA handling of entity-tags. 379 If there is no matching event state, e.g., the event state to be 380 refreshed has already expired, the EPA receives a 412 (Conditional 381 Request Failed) response to the PUBLISH request. 383 A publication refresh MAY contain a single Expires header field. 384 This value indicates the suggested lifetime of the event state. 386 If an Expires header is not present, the EPA is indicating its desire 387 for the ESC to choose. The ESC may lower the suggested lifetime of 388 the publication refresh, but it will never extend it. The Expires 389 header field in a 2xx response to the publication refresh indicates 390 the actual duration for which the publication will remain active. 392 A publication refresh only extends the expiration time of already 393 existing event state. It does not affect that event state in any 394 other way. Therefore, a PUBLISH request that refreshes event state 395 MUST NOT have a body. 397 4.4 Modifying Event State 399 Modifying event state closely resembles the creation of initial event 400 state. However, instead of establishing completely new event state 401 at the ESC, already existing event state is updated with modified 402 event state. The nature of this update depends on the content of the 403 body, and the semantics associated with the format of that body. 405 To modify event state, the EPA MUST construct a PUBLISH request that 406 includes in a SIP-If-Match header field the entity-tag of the event 407 state publication to be modified. A PUBLISH request that modifies 408 event state MUST contain a body that includes the modified event 409 state. 411 The SIP-If-Match header field conditions the PUBLISH request to 412 modify a specific event state established by a prior publication, and 413 identified by the entity-tag. If the entity-tag matches previously 414 published event state at the ESC, that event state is replaced by the 415 event state carried in the PUBLISH request, and the EPA receives a 416 2xx response. 418 Like the 2xx response to an initial PUBLISH request, the 2xx response 419 to a modifying PUBLISH request will contain a SIP-ETag header field 420 with an entity-tag. The EPA MUST store this entity-tag, replacing 421 any existing entity-tag for the modified event state. See Section 422 8.2 for more information on the EPA handling of entity-tags. 424 If there is no matching event state at the ESC, e.g., the event state 425 to be modified has already expired, the EPA receives a 412 426 (Conditional Request Failed) response to the PUBLISH request. 428 A modifying PUBLISH request MAY contain a single Expires header 429 field. This value indicates the suggested lifetime of the event 430 state publication. 432 If an Expires header is not present, the EPA is indicating its desire 433 for the ESC to choose. The ESC may lower the suggested lifetime of 434 the publication, but it will never extend it. The Expires header 435 field in a 2xx response to the modifying PUBLISH indicates the actual 436 duration for which the publication will remain active. Unless 437 refreshed before this lifetime is exceeded, the publication will 438 expire. 440 4.5 Removing Event State 442 Event state established by a prior publication may also be explicitly 443 removed. 445 To request the immediate removal of event state, an EPA MUST create a 446 PUBLISH request with an Expires value of "0", and set the 447 SIP-If-Match header field to contain the entity-tag of the event 448 state publication to be removed. 450 Note that removing event state is effectively a publication 451 refresh suggesting an infinitesimal expiration interval. 452 Consequently, the refreshed event state expires immediately after 453 being refreshed. 455 Similar to an event state refresh, the removal of event state only 456 affects the expiry of the event state. Therefore, a PUBLISH request 457 that removes event state MUST NOT contain a body. 459 5. Processing PUBLISH Responses 461 When processing responses to PUBLISH requests, the steps in Section 462 8.1.2 of RFC 3261 [4] apply. 464 If an EPA receives a 412 (Conditional Request Failed) response, it 465 MUST NOT reattempt the PUBLISH request. Instead, to publish event 466 state, the EPA SHOULD perform an initial publication, i.e., a PUBLISH 467 request without a SIP-If-Match header field, as described in Section 468 4.2. The EPA MUST also discard the entity-tag that produced this 469 error resoponse. 471 If an EPA receives a 423 (Interval Too Brief) response to a PUBLISH 472 request, it MAY retry the publication after changing the expiration 473 interval in the Expires header field to be equal to or greater than 474 the expiration interval within the Min-Expires header field of the 475 423 (Interval Too Brief) response. 477 6. Processing PUBLISH Requests 479 The Event State Compositor (ESC) is a User Agent Server (UAS) that 480 processes and responds to PUBLISH requests, and maintains a list of 481 publications for a given address-of-record. The ESC has to know 482 (e.g., through configuration) the set of addresses for which it 483 maintains event state. 485 The ESC MUST ignore the Record-Route header field if it is included 486 in a PUBLISH request. The ESC MUST NOT include a Record-Route header 487 field in any response to a PUBLISH request. The ESC MUST ignore the 488 Contact header field if one is present in a PUBLISH request. 490 PUBLISH requests with the same Request-URI MUST be processed in the 491 order that they are received. PUBLISH requests MUST also be 492 processed atomically, meaning that a particular PUBLISH request is 493 either processed completely or not at all. 495 When receiving a PUBLISH request, the ESC follows the steps defining 496 general UAS behavior in Section 8.2 of RFC 3261 [4]. In addition, 497 for PUBLISH specific behavior the ESC follows these steps: 499 1. The ESC inspects the Request-URI to determine whether this 500 request is targeted to a resource for which the ESC is 501 responsible for maintaining event state. If not, the ESC MUST 502 return a 404 (Not Found) response and skip the remaining steps. 504 It may also be that the Request-URI points to a domain that 505 the ESC is not responsible for. In that case, the UAS 506 receiving the request can assume the role of a proxy server 507 and forward the request to a more appropriate target. 509 2. The ESC examines the Event header field of the PUBLISH request. 510 If the Event header field is missing or contains an event package 511 which the ESC does not support, the ESC MUST respond to the 512 PUBLISH request with a 489 (Bad Event) response, and skip the 513 remaining steps. 515 3. The ESC examines the SIP-If-Match header field of the PUBLISH 516 request for the presence of a request precondition. 518 * If the request does not contain a SIP-If-Match header field, 519 the ESC MUST generate and store a locally unique entity-tag 520 for identifying the publication. This entity-tag is 521 associated with the event-state carried in the body of the 522 PUBLISH request. 524 * Else, if the request has a SIP-If-Match header field, the ESC 525 checks whether the header field contains a single entity-tag. 526 If not, the request is invalid, and the ESC MUST return with a 527 400 (Invalid Request) response and skip the remaining steps. 529 * Else, the ESC extracts the entity-tag contained in the 530 SIP-If-Match header field and matches that entity-tag against 531 all locally stored entity-tags for this resource and event 532 package. If no match is found, the ESC MUST reject the 533 publication with a response of 412 (Conditional Request 534 Failed), and skip the remaining steps. 536 4. The ESC processes the Expires header field value from the PUBLISH 537 request. 539 * If the request has an Expires header field, that value MUST be 540 taken as the requested expiration. 542 * Else, a locally-configured default value MUST be taken as the 543 requested expiration. 545 * The ESC MAY choose an expiration less than the requested 546 expiration interval. Only if the requested expiration 547 interval is greater than zero and less than a 548 locally-configured minimum, the ESC MAY reject the publication 549 with a response of 423 (Interval Too Brief), and skip the 550 remaining steps. This response MUST contain a Min-Expires 551 header field that states the minimum expiration interval the 552 ESC is willing to honor. 554 5. The ESC processes the published event state contained in the body 555 of the PUBLISH request. If the content type of the request does 556 not match the event package, or is not understood by the ESC, the 557 ESC MUST reject the request with an appropriate response, such as 558 415 (Unsupported Media Type), and skip the remainder of the 559 steps. 561 * If present, the ESC stores the event state delivered in the 562 PUBLISH request and identified by the associated entity-tag, 563 updating any existing event state for that entity-tag. 565 * Else, the event state identified by the entity-tag is 566 refreshed, setting the expiration value to the chosen 567 expiration interval. If the chosen expiration interval has a 568 special value of "0", the event state identified by the 569 entity-tag MUST be immediately removed. 571 The processing of the PUBLISH request MUST be atomic. If 572 internal errors (such as the inability to access a back-end 573 database) occur before processing is complete, the publication 574 MUST NOT succeed, and the ESC MUST fail with an appropriate error 575 response, such as 504 (Server Time-out), and skip the last step. 577 6. The ESC returns a 200 (OK) response. The response MUST contain 578 an Expires header field indicating the expiration interval chosen 579 by the ESC. The response MUST also contain a SIP-ETag header 580 field that contains a single entity-tag identifying the 581 publication. The ESC MUST generate a new entity-tag for each 582 successful publication, replacing any previous entity-tag 583 associated with that event state. See Section 8.3 for more 584 information on the ESC handling of entity-tags. 586 7. Processing OPTIONS Requests 588 A client may probe the ESC for the support of PUBLISH using the 589 OPTIONS request defined in SIP [4]. The ESC processes OPTIONS 590 requests as defined in Section 11.2 of RFC 3261 [4]. In the response 591 to an OPTIONS request, the ESC SHOULD include "PUBLISH" to the list 592 of allowed methods in the Allow header field. Also, it SHOULD list 593 the supported event packages in an Allow-Events header field. 595 The Allow header field may also be used to specifically announce 596 support for PUBLISH messages when registering. (See SIP 597 Capabilities [12] for details). 599 8. Use of Entity-tags in PUBLISH 601 This section makes a general overview of the entity-tags usage in 602 PUBLISH. It is informative in nature and thus contains no normative 603 protocol description. 605 8.1 General Notes 607 The PUBLISH mechanism makes use of entity-tags, as defined in HTTP/ 608 1.1 [13]. While the main functionality is preserved, the syntax and 609 semantics for entity-tags and the corresponding header fields is 610 adapted specifically for use with the PUBLISH method. The main 611 differences are: 613 o The syntax for entity-tags is a token instead of quoted-string. 614 There is also no prefix defined for indicating a weak entity-tag. 616 o A PUBLISH precondition can only apply to a single entity-tag, so 617 request preconditions with multiple entity-tags are not allowed. 619 o A request precondition can't apply to "any" entity, namely there 620 is no special "*" entity-tag value defined for PUBLISH. 622 o Whereas in HTTP/1.1 returning an entity-tag is optional for origin 623 servers, in PUBLISH ESCs are required to always return an 624 entity-tag for a successful publication. 626 The main motivation for the above adaptation is that PUBLISH is 627 conceptually an HTTP PUT, for which only a subset of the features in 628 cache validation using entity-tags is allowed in HTTP/1.1. It makes 629 little sense to enable features other than this subset for event 630 state publication. 632 To make it apparent that the entity-tags usage in PUBLISH is similar 633 but not identical to HTTP/1.1, we have not adopted the header field 634 names directly from HTTP/1.1, but rather have created similar but 635 distinct names, as can be seen in Section 11. 637 8.2 Client Usage 639 Each successful publication will get assigned an entity-tag which is 640 then delivered to the EPA in the response to the PUBLISH request. 641 The EPA needs to store that entity-tag, replacing any previous 642 entity-tag for that event state. If a request fails with a 412 643 (Conditional Request Failed) response, the EPA discards the 644 entity-tag that caused the failure. 646 Entity-tags are opaque tokens to the EPA. The EPA cannot infer any 647 further semantics from an entity-tag beyond a simple identifier, or 648 assume a specific formatting. An entity-tag may be a monotonically 649 increasing counter, but it may also be a totally random token. It is 650 up to the ESC implementation as to what the formatting of an 651 entity-tag is. 653 8.3 Server Usage 655 Entity-tags are generated and maintained by the ESC. They are part 656 of the state maintained by the ESC that also includes the actual 657 event state and its remaining expiration interval. An entity-tag is 658 generated and stored for each successful event state publication, and 659 returned to the EPA in a 200 (OK) response. Each event state 660 publication from the EPA that updates a previous publication will 661 include an entity-tag that the ESC can use as a search key in the set 662 of active publications. 664 The way in which an entity-tag is generated is an implementation 665 decision. One possible way to generate an entity-tag is to implement 666 it as an integer counter that is incremented by one for each 667 successfully processed publication. Other, equally valid ways for 668 generating entity-tags exist, and this document makes no 669 recommendations or preference for a single way. 671 9. Controlling the Rate of Publication 673 As the aggregator of state information from potentially many sources, 674 the ESC can be subject to considerable amounts of publication 675 traffic. There are ways to reduce the amount of PUBLISH requests 676 that the ESC receives: 678 o Choice of the expiration interval for a publication can be 679 affected by the ESC. It can insist that an EPA chooses a longer 680 expiration value to what it suggests, in case the ESC's local 681 default minimum expiration value is not reached. Maintaining a 682 longer default minimum expiration value at the ESC reduces the 683 rate at which publications are refreshed. 685 o Another way of reducing publication traffic is to use a SIP-level 686 push-back to quench a specific source of publication traffic. To 687 push back on publications from a particular source, the ESC MAY 688 respond to a PUBLISH request with a 503 (Service Unavailable), as 689 defined in RFC 3261 [4]. This response SHOULD contain a 690 Retry-After header field indicating the time interval that the 691 publication source is required to wait until sending another 692 PUBLISH request. 694 At the time of writing this specification, work on managing load in 695 SIP is starting, which may be able to provide further tools for 696 managing load in event state publication systems. 698 10. Considerations for Event Packages using PUBLISH 700 This section discusses several issues which should be taken into 701 consideration when applying the PUBLISH mechanism to event packages. 702 It also demonstrates how these issues are handled when using PUBLISH 703 for presence publication. 705 Any future event package specification SHOULD include a discussion of 706 its considerations for using PUBLISH. At a minimum those 707 considerations SHOULD address the issues presented in this chapter, 708 and MAY include additional considerations. 710 10.1 PUBLISH Bodies 712 The body of the PUBLISH request typically carries the published event 713 state. Any application of the PUBLISH mechanism for a given event 714 package MUST define what content type or types are expected in 715 PUBLISH requests. Each event package MUST also describe the 716 semantics associated with that content type, and MUST prescribe a 717 default, mandatory to implement MIME type. 719 This document defines the semantics of the presence publication 720 requests (event package "presence") when the CPIM PIDF [6] presence 721 document format is used. A PUA that uses PUBLISH to publish presence 722 state to the PA MUST support the CPIM PIDF presence format. It MAY 723 support other formats. 725 10.2 PUBLISH Response Bodies 727 The response to a PUBLISH request indicates whether the request was 728 successful or not. In general, the body of such a response will be 729 empty unless the event package defines explicit meaning for such a 730 body. 732 There is no such meaning for the body of a response to a presence 733 publication. 735 10.3 Multiple Sources for Event State 737 For some event packages, the underlying model is that of a single 738 aggregator of event state (ESC), and multiple sources, out of which 739 only some may be using the PUBLISH mechanism. 741 Note that sources for event state other than those using the 742 PUBLISH mechanism are explicitly allowed. However, it is beyond 743 the scope of this document to define such interfaces. 745 Event packages that make use of the PUBLISH mechanism SHOULD describe 746 whether this model for event state publication is applicable, and MAY 747 describe specific mechanisms used for aggregating publications from 748 multiple sources. 750 For presence, a PUA can publish presence state for just a subset of 751 the tuples that may be composited into the presence document that 752 watchers receive in a NOTIFY. The mechanism by which the ESC 753 aggregates this information is a matter of local policy and out of 754 the scope of this specification. 756 10.4 Event State Segmentation 758 For some event packages, there exists a natural decomposition of 759 event state into segments. Each segment is defined as one of 760 potentially many identifiable sections in the published event state. 761 Any event package whose content type supports such segmentation of 762 event state, SHOULD describe the way in which these event state 763 segments are identified by the ESC. 765 In presence publication, the EPA MUST keep the "id" attributes of 766 tuples consistent in the context of an entity-tag. If a publication 767 modifies the contents of a tuple, that tuple MUST maintain its 768 original "id". The ESC will interpret each tuple in the context of 769 the entity-tag with which the request arrived. A tuple whose "id" is 770 missing compared to the original publication will be considered as 771 being removed. Similarly, a tuple is interpreted as being added if 772 its "id" attribute is one that the original publication did not 773 contain. 775 10.5 Rate of Publication 777 Controlling the rate of publication is discussed in Section 9. 778 Individual event packages MAY in turn define recommendations (SHOULD 779 or MUST strength) on absolute maximum rates at which publications are 780 allowed to be generated by a single EPA. 782 There are no rate limiting recommendations for presence publication. 784 11. Protocol Element Definitions 786 This section describes the extensions required for event publication 787 in SIP. 789 11.1 New Methods 791 11.1.1 PUBLISH Method 793 "PUBLISH" is added to the definition of the element "Method" in the 794 SIP message grammar. As with all other SIP methods, the method name 795 is case sensitive. PUBLISH is used to publish event state to an 796 entity responsible for compositing this event state. 798 Table 2 and Table 3 extend Tables 2 and 3 of RFC 3261 [4] by adding 799 an additional column, defining the header fields that can be used in 800 PUBLISH requests and responses. The keys in these tables are 801 specified in Section 20 of RFC 3261 [4]. 803 +---------------------+---------+---------+ 804 | Header Field | where | PUBLISH | 805 +---------------------+---------+---------+ 806 | Accept | R | o | 807 | Accept | 2xx | - | 808 | Accept | 415 | m* | 809 | Accept-Encoding | R | o | 810 | Accept-Encoding | 2xx | - | 811 | Accept-Encoding | 415 | m* | 812 | Accept-Language | R | o | 813 | Accept-Language | 2xx | - | 814 | Accept-Language | 415 | m* | 815 | Alert-Info | | - | 816 | Allow | R | o | 817 | Allow | r | o | 818 | Allow | 405 | m | 819 | Allow-Events | R | o | 820 | Allow-Events | 489 | m | 821 | Authentication-Info | 2xx | o | 822 | Authorization | R | o | 823 | Call-ID | c | m | 824 | Call-Info | | o | 825 | Contact | R | - | 826 | Contact | 1xx | - | 827 | Contact | 2xx | - | 828 | Contact | 3xx | o | 829 | Contact | 485 | o | 830 | Content-Disposition | | o | 831 | Content-Encoding | | o | 832 | Content-Language | | o | 833 | Content-Length | | t | 834 | Content-Type | | * | 835 | CSeq | c | m | 836 | Date | | o | 837 | Event | R | m | 838 | Error-Info | 300-699 | o | 839 | Expires | | o | 840 | Expires | 2xx | m | 841 | From | c | m | 842 | In-Reply-To | R | - | 843 | Max-Forwards | R | m | 844 | Min-Expires | 423 | m | 845 | MIME-Version | | o | 846 | Organization | | o | 847 +---------------------+---------+---------+ 849 Table 2: Summary of header fields, A--O 851 +---------------------+-----------------+---------+ 852 | Header Field | where | PUBLISH | 853 +---------------------+-----------------+---------+ 854 | Priority | R | o | 855 | Proxy-Authenticate | 407 | m | 856 | Proxy-Authenticate | 401 | o | 857 | Proxy-Authorization | R | o | 858 | Proxy-Require | R | o | 859 | Record-Route | | - | 860 | Reply-To | | - | 861 | Require | | o | 862 | Retry-After | 404,413,480,486 | o | 863 | Retry-After | 500,503 | o | 864 | Retry-After | 600,603 | o | 865 | Route | R | c | 866 | Server | r | o | 867 | Subject | R | o | 868 | Supported | R | o | 869 | Supported | 2xx | o | 870 | Timestamp | | o | 871 | To | c(1) | m | 872 | Unsupported | 420 | o | 873 | User-Agent | | o | 874 | Via | R | m | 875 | Via | rc | m | 876 | Warning | r | o | 877 | WWW-Authenticate | 401 | m | 878 | WWW-Authenticate | 407 | o | 879 +---------------------+-----------------+---------+ 881 Table 3: Summary of header fields, P--Z 883 11.2 New Response Codes 885 11.2.1 "412 Conditional Request Failed" Response Code 887 The 412 (Conditional Request Failed) response is added to the 888 "Client-Error" header field definition. 412 (Conditional Request 889 Failed) is used to indicate that the precondition given for the 890 request has failed. 892 11.3 New Header Fields 894 Table 4, Table 5, and Table 6 expand on Table 3 in SIP [4], as 895 amended by the changes in Section 11.1. 897 +--------------+-------+-------+-----+-----+-----+-----+-----+ 898 | Header Field | where | proxy | ACK | BYE | CAN | INF | INV | 899 +--------------+-------+-------+-----+-----+-----+-----+-----+ 900 | SIP-ETag | 2xx | | - | - | - | - | - | 901 | SIP-If-Match | R | | - | - | - | - | - | 902 +--------------+-------+-------+-----+-----+-----+-----+-----+ 904 Table 4: Summary of header fields, P--Z 906 +--------------+-------+-------+-----+-----+-----+-----+-----+ 907 | Header Field | where | proxy | NOT | OPT | PRA | REG | SUB | 908 +--------------+-------+-------+-----+-----+-----+-----+-----+ 909 | SIP-ETag | 2xx | | - | - | - | - | - | 910 | SIP-If-Match | R | | - | - | - | - | - | 911 +--------------+-------+-------+-----+-----+-----+-----+-----+ 913 Table 5: Summary of header fields, P--Z 915 +--------------+-------+-------+-----+-----+-----+---------+ 916 | Header Field | where | proxy | UPD | MSG | REF | PUBLISH | 917 +--------------+-------+-------+-----+-----+-----+---------+ 918 | SIP-ETag | 2xx | | - | - | - | m | 919 | SIP-If-Match | R | | - | - | - | o | 920 +--------------+-------+-------+-----+-----+-----+---------+ 922 Table 6: Summary of header fields, P--Z 924 11.3.1 "SIP-ETag" Header Field 926 SIP-ETag is added to the definition of the element "general-header" 927 in the SIP message grammar. Usage of this header is described in 928 Section 4 and Section 6. 930 11.3.2 "SIP-If-Match" Header Field 932 SIP-If-Match is added to the definition of the element 933 "general-header" in the SIP message grammar. Usage of this header is 934 described in Section 4 and Section 6. 936 12. Augmented BNF Definitions 938 This section describes the syntax extensions required for event 939 publication in SIP. The formal syntax definitions described in this 940 section are expressed in the Augmented BNF [7] format used in SIP 941 [4], and contain references to elements defined therein. 943 PUBLISHm = %x50.55.42.4C.49.53.48 ; PUBLISH in caps. 944 extension-method = PUBLISHm / token 945 SIP-ETag = "SIP-ETag" HCOLON entity-tag 946 SIP-If-Match = "SIP-If-Match" HCOLON entity-tag 947 entity-tag = token 949 13. IANA Considerations 951 This document registers a new method name, a new response code and 952 two new header field names. 954 13.1 Methods 956 This document registers a new SIP method, defined by the following 957 information, which is to be added to the method and response-code 958 sub-registry under http://www.iana.org/assignments/sip-parameters. 960 Method Name: PUBLISH 961 Reference: [RFCYYYY] 963 (Note to RFC Editor: Replace YYYY with the RFC number of this 964 document when published). 966 13.2 Response Codes 968 This document registers a new response code. This response code is 969 defined by the following information, which is to be added to the 970 method and response-code sub-registry under http://www.iana.org/ 971 assignments/sip-parameters. 973 Response Code Number: 412 974 Default Reason Phrase: Conditional Request Failed 976 13.3 Header Field Names 978 This document registers two new SIP header field names. These 979 headers are defined by the following information, which is to be 980 added to the header sub-registry under 981 http://www.iana.org/assignments/ sip-parameters. 983 Header Name: SIP-ETag 984 Compact Form: (none) 986 Header Name: SIP-If-Match 987 Compact Form: (none) 989 14. Security Considerations 991 14.1 Access Control 993 Since event state may be considered sensitive information, the ESC 994 should have the ability to selectively accept publications from 995 authorized sources only, based on the identity of the EPA. 997 The state agent SHOULD authenticate the EPA, and SHOULD apply its 998 authorization policies (e.g., based on access control lists) to all 999 requests. The composition model makes no assumptions that all input 1000 sources for an ESC are on the same network, or in the same 1001 administrative domain. 1003 ESCs and EPAs MUST implement Digest for authenticating PUBLISH 1004 requests, as defined in RFC 3261 [4]. The exact methods for creating 1005 and manipulating access control policies in the ESC are outside the 1006 scope of this document. 1008 14.2 Denial of Service Attacks 1010 The creation of state at the ESC upon receipt of a PUBLISH request 1011 can be used by attackers to consume resources on a victim's machine, 1012 possibly rendering it unusable. 1014 To reduce the chances of such an attack, implementations of ESCs 1015 SHOULD require authentication of PUBLISH requests. Implementations 1016 MUST support Digest authentication, as defined in RFC 3261 [4]. 1018 Also, the ESC SHOULD throttle incoming publications and the 1019 corresponding notifications resulting from the changes in event 1020 state. As a first step, careful selection of default minimum Expires 1021 header field values for the supported event packages at an ESC can 1022 help limit refreshes of event state. 1024 Additional throttling and debounce logic at the ESC is advisable to 1025 further reduce the notification traffic produced as a result of a 1026 PUBLISH request. 1028 14.3 Replay Attack 1030 Replaying a PUBLISH request can have detrimental effects. An 1031 attacker may be able to perform any event state publication it 1032 witnessed being performed at some point in the past, by replaying 1033 that PUBLISH request. Among other things, such a replay message may 1034 be used to spoof old event state information, although a versioning 1035 mechanism, e.g., a timestamp, in the state information may help 1036 mitigate such an attack. 1038 To prevent replay attacks, implementations MUST support Digest 1039 authentication with replay protection, as defined in RFC 3261 [4]. 1040 Further mechanisms for countering replay attacks are discussed in SIP 1041 [4]. 1043 14.4 Man in the Middle Attacks 1045 Even with authentication, man-in-the-middle attacks using PUBLISH may 1046 be used to install arbitrary event state information, modify or 1047 remove existing event state information in publications, or even 1048 remove event state altogether at an ESC. 1050 To prevent such attacks, implementations SHOULD, at a minimum, 1051 provide integrity protection across the To, From, Event, 1052 SIP-If-Match, Route, and Expires headers and the bodies of PUBLISH 1053 requests. 1055 If the ESC receives event state in a PUBLISH request which is 1056 integrity protected using a security association that is not with the 1057 ESC (e.g., integrity protection is applied end-to-end, from publisher 1058 to subscriber), the state agent coupled with the ESC MUST NOT modify 1059 the event state before exposing it to the subscribers of this event 1060 state in NOTIFY requests. This is to preserve the end-to-end 1061 integrity of the event state. 1063 For integrity protection, ESCs MUST implement TLS [8], and MUST 1064 support both mutual and one-way authentication, and MUST also support 1065 the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of 1066 initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs 1067 MAY support S/MIME [9] for integrity protection, as defined in SIP 1068 [4]. 1070 14.5 Confidentiality 1072 The state information contained in a PUBLISH message may potentially 1073 contain sensitive information. Implementations MAY encrypt such 1074 information to ensure confidentiality. 1076 For providing confidentiality, ESCs MUST implement TLS [8], MUST 1077 support both mutual and one-way authentication, and MUST also support 1078 the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of 1079 initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs 1080 MAY support S/MIME [9] for encryption of event state information, as 1081 defined in SIP [4]. 1083 15. Examples 1085 This section shows an example of the usage of the PUBLISH method in 1086 the case of publishing the presence document from a presence user 1087 agent to a presence agent. The watcher in this case is watching the 1088 PUA's presentity. The PUA may also SUBSCRIBE to its own presence to 1089 see the composite presence state exposed by the PA. This is an 1090 optional but likely step for the PUA, and is not shown in this 1091 example. 1093 PUA PA WATCHER 1094 (EPA) (ESC) 1095 | | | 1096 | | <---- M1: SUBSCRIBE --- | 1097 | | | 1098 | | ----- M2: 200 OK -----> | 1099 | | | 1100 | | ----- M3: NOTIFY -----> | 1101 | | | 1102 | | <---- M4: 200 OK ------ | 1103 | | | 1104 | | | 1105 | ---- M5: PUBLISH ---> | | 1106 | | | 1107 | <--- M6: 200 OK ---- | | 1108 | | | 1109 | | ----- M7: NOTIFY -----> | 1110 | | | 1111 | | <---- M8: 200 OK ------ | 1112 | | | 1113 | ---- M9: PUBLISH ---> | | 1114 | | | 1115 | <--- M10: 200 OK --- | | 1116 | | | 1117 | | | 1118 | --- M11: PUBLISH ---> | | 1119 | | | 1120 | <-- M12: 200 OK ---- | | 1121 | | | 1122 | | ----- M13: NOTIFY ----> | 1123 | | | 1124 | | <---- M14: 200 OK ----- | 1125 | | | 1127 Message flow: 1129 M1: The watcher initiates a new subscription to the 1130 presentity@example.com's presence agent. 1132 SUBSCRIBE sip:presentity@example.com SIP/2.0 1133 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7 1134 To: 1135 From: ;tag=12341234 1136 Call-ID: 12345678@host.example.com 1137 CSeq: 1 SUBSCRIBE 1138 Max-Forwards: 70 1139 Expires: 3600 1140 Event: presence 1141 Contact: sip:user@host.example.com 1142 Content-Length: 0 1144 M2: The presence agent for presentity@example.com processes the 1145 subscription request and creates a new subscription. A 200 (OK) 1146 response is sent to confirm the subscription. 1148 SIP/2.0 200 OK 1149 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7 1150 ;received=192.0.2.1 1151 To: ;tag=abcd1234 1152 From: ;tag=12341234 1153 Call-ID: 12345678@host.example.com 1154 CSeq: 1 SUBSCRIBE 1155 Contact: sip:pa.example.com 1156 Expires: 3600 1157 Content-Length: 0 1159 M3: In order to complete the process, the presence agent sends the 1160 watcher a NOTIFY with the current presence state of the 1161 presentity. 1163 NOTIFY sip:user@host.example.com SIP/2.0 1164 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 1165 To: ;tag=12341234 1166 From: ;tag=abcd1234 1167 Call-ID: 12345678@host.example.com 1168 CSeq: 1 NOTIFY 1169 Max-Forwards: 70 1170 Event: presence 1171 Subscription-State: active; expires=3599 1172 Contact: sip:pa.example.com 1173 Content-Type: application/pidf+xml 1174 Content-Length: ... 1176 1177 1179 1180 1181 open 1182 1183 2003-02-01T16:49:29Z 1184 1185 1186 1187 open 1188 1189 2003-02-01T12:21:29Z 1190 1191 1193 M4: The watcher confirms receipt of the NOTIFY request. 1195 SIP/2.0 200 OK 1196 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 1197 ;received=192.0.2.2 1198 To: ;tag=12341234 1199 From: ;tag=abcd1234 1200 Call-ID: 12345678@host.example.com 1201 CSeq: 1 NOTIFY 1203 M5: A presence user agent for the presentity initiates a PUBLISH to 1204 the presentity's presence agent in order to update it with new 1205 presence information. The Expires header indicates the desired 1206 duration of this soft state. 1208 PUBLISH sip:presentity@example.com SIP/2.0 1209 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge 1210 To: 1211 From: ;tag=1234wxyz 1212 Call-ID: 81818181@pua.example.com 1213 CSeq: 1 PUBLISH 1214 Max-Forwards: 70 1215 Expires: 3600 1216 Event: presence 1217 Content-Type: application/pidf+xml 1218 Content-Length: ... 1220 1221 1223 1224 1225 closed 1226 1227 2003-02-01T17:00:19Z 1228 1229 1231 M6: The presence agent receives, and accepts the presence 1232 information. The published data is incorporated into the 1233 presentity's presence document. A 200 (OK) response is sent to 1234 confirm the publication. The 200 (OK) response contains an 1235 SIP-ETag header field with an entity-tag. This is used to 1236 identify the published event state in subsequent PUBLISH requests. 1238 SIP/2.0 200 OK 1239 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge 1240 ;received=192.0.2.3 1241 To: ;tag=1a2b3c4d 1242 From: ;tag=1234wxyz 1243 Call-ID: 81818181@pua.example.com 1244 CSeq: 1 PUBLISH 1245 SIP-ETag: dx200xyz 1246 Expires: 1800 1248 M7: The presence agent determines that a reportable change has been 1249 made to the presentity's presence document, and sends another 1250 notification to those watching the presentity to update their 1251 information regarding the presentity's current presence status. 1253 NOTIFY sip:user@host.example.com SIP/2.0 1254 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a 1255 To: ;tag=12341234 1256 From: ;tag=abcd1234 1257 Call-ID: 12345678@host.example.com 1258 CSeq: 2 NOTIFY 1259 Max-Forwards: 70 1260 Event: presence 1261 Subscription-State: active; expires=3400 1262 Contact: sip:pa.example.com 1263 Content-Type: application/pidf+xml 1264 Content-Length: ... 1266 1267 1269 1270 1271 closed 1272 1273 2003-02-01T17:00:19Z 1274 1275 1276 1277 open 1278 1279 2003-02-01T12:21:29Z 1280 1281 1283 M8: The watcher confirms receipt of the NOTIFY request. 1285 SIP/2.0 200 OK 1286 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a 1287 ;received=192.0.2.2 1288 To: ;tag=12341234 1289 From: ;tag=abcd1234 1290 Call-ID: 12345678@host.example.com 1291 CSeq: 2 NOTIFY 1292 Content-Length: 0 1294 M9: The PUA determines that the event state it previously published 1295 is about to expire, and refreshes that event state. 1297 PUBLISH sip:presentity@example.com SIP/2.0 1298 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02 1299 To: 1300 From: ;tag=1234kljk 1301 Call-ID: 98798798@pua.example.com 1302 CSeq: 1 PUBLISH 1303 Max-Forwards: 70 1304 SIP-If-Match: dx200xyz 1305 Expires: 3600 1306 Event: presence 1307 Content-Length: 0 1309 M10: The presence agent receives, and accepts the publication 1310 refresh. The timers regarding the expiration of the specific 1311 event state identified by the entity-tag are updated. As always, 1312 the ESC returns an entity-tag in the response to a successful 1313 PUBLISH. Note that no actual state change has occured, so the 1314 watchers will receive no NOTIFYs. 1316 SIP/2.0 200 OK 1317 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02 1318 ;received=192.0.2.3 1319 To: ;tag=2affde434 1320 From: ;tag=1234kljk 1321 Call-ID: 98798798@pua.example.com 1322 CSeq: 1 PUBLISH 1323 SIP-ETag: kwj449x 1324 Expires: 1800 1326 M11: The PUA of the presentity detects a change in the user's 1327 presence state. It initiates a PUBLISH request to the presence 1328 agent to modify the published presence information with the recent 1329 change. 1331 PUBLISH sip:presentity@example.com SIP/2.0 1332 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2 1333 To: 1334 From: ;tag=54321mm 1335 Call-ID: 5566778@pua.example.com 1336 CSeq: 1 PUBLISH 1337 Max-Forwards: 70 1338 SIP-If-Match: kwj449x 1339 Expires: 3600 1340 Event: presence 1341 Content-Type: application/pidf+xml 1342 Content-Length: ... 1344 1345 1347 1348 1349 open 1350 1351 2003-02-01T19:15:15Z 1352 1353 1355 M12: The presence agent receives, and accepts the publication 1356 modification. The timers regarding the expiration of the specific 1357 event state identified by the entity-tag are updated, and the 1358 published data is incorporated into the presentity's presence 1359 document. Note that the document delivered in this modification 1360 will replace the previous document. 1362 SIP/2.0 200 OK 1363 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2 1364 ;received=192.0.2.3 1365 To: ;tag=effe22aa 1366 From: ;tag=54321mm 1367 Call-ID: 5566778@pua.example.com 1368 CSeq: 1 PUBLISH 1369 SIP-ETag: qwi982ks 1370 Expires: 3600 1372 M13: The presence agent determines that a reportable change has been 1373 made to the presentity's presence document, and sends another 1374 notification to those watching the presentity to update their 1375 information regarding the presentity's current presence status. 1377 NOTIFY sip:user@host.example.com SIP/2.0 1378 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3 1379 To: ;tag=12341234 1380 From: ;tag=abcd1234 1381 Call-ID: 12345678@host.example.com 1382 CSeq: 2 NOTIFY 1383 Max-Forwards: 70 1384 Event: presence 1385 Subscription-State: active; expires=3400 1386 Contact: sip:pa.example.com 1387 Content-Type: application/pidf+xml 1388 Content-Length: ... 1390 1391 1393 1394 1395 open 1396 1397 2003-02-01T19:15:15Z 1398 1399 1400 1401 open 1402 1403 2003-02-01T12:21:29Z 1404 1405 1407 M14: The watcher confirms receipt of the NOTIFY request. 1409 SIP/2.0 200 OK 1410 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3 1411 ;received=192.0.2.3 1412 To: ;tag=12341234 1413 From: ;tag=abcd1234 1414 Call-ID: 12345678@host.example.com 1415 CSeq: 2 NOTIFY 1416 Content-Length: 0 1418 16. Contributors 1420 The original contributors to this specification are: 1422 Ben Campbell 1423 dynamicsoft 1424 Sean Olson 1425 Microsoft 1427 Jon Peterson 1428 Neustar, Inc. 1430 Jonathan Rosenberg 1431 dynamicsoft 1433 Brian Stucker 1434 Nortel Networks, Inc. 1436 17. Acknowledgements 1438 The authors would like to thank the SIMPLE Working Group for their 1439 collective effort, and specifically the following people for their 1440 review and support of this work: Henning Schulzrinne, Paul Kyzivat, 1441 Hisham Khartabil, George Foti, Keith Drage, Samir Srivastava, Arun 1442 Kumar, Adam Roach, Pekka Pessi, Kai Wang, Cullen Jennings, Mikko 1443 Lonnfors, Eva-Maria Leppanen, Ernst Horvath, Thanos Diacakis, Oded 1444 Cnaan, Rohan Mahy and Dean Willis. 1446 18. Document Change History 1448 (Note to RFC Editor: please remove this whole section prior to 1449 publication as an RFC.) 1451 18.1 Changes since "draft-ietf-sip-publish-03" 1453 The following changes were made since the last version: 1455 o Changed the default response phrase for 412 to avoid clashing with 1456 session preconditions 1458 o Added explanations for columns and keys therein in tables 2 and 3 1459 for clarity 1461 o Reworded passages in sections 4.3 and 4.4, and added a reference 1462 to chapter 8 to clarify the etags usage in refresh/modify 1463 publications. 1465 o Added a reference to section 8 in the last step of section 6 to 1466 clarify the etags usage by the ESC. 1468 o Small wording change in section 8.2, 1st paragraph to clarify the 1469 meaning of the 2nd sentence. 1471 18.2 Changes since "draft-ietf-sip-publish-02" 1473 The following changes were made since the last version: 1475 o Changed title to be in line with draft-ietf-sip-guidelines. 1477 o Added RFC 2779 reference, as well as a reference for 1478 draft-ietf-simple-presence. 1480 o Added a definition for presence compositor. 1482 o Cleaned up the message syntax in the examples section. 1484 o Fixed typos and improved wording. 1486 18.3 Changes since "draft-ietf-sip-publish-01" 1488 The following changes were made since the last version: 1490 o Added new chapter discussing entity-tags in general. 1492 o Added new chapter discussing rate control for publications, 1493 including SIP level push-back. 1495 o Added back a considerations section for event segmentation (in 1496 Chapter 4), and clarified text in other parts. 1498 o Clarified text on constructing a PUBLISH. Added a table 1499 describing the operations and their properties. 1501 o Changed syntax by adding a "SIP-" prefix to the header field 1502 names. This is to indicate that the syntax/semantics of 1503 entity-tags is similar but different from the HTTP counterparts. 1505 o Fixed the draft to consistently use Request-URI as identifying the 1506 target resource for the publication. 1508 o Clarified Contact usage and in-dialog requests. 1510 o Lots of fixes to various places in the draft based on review 1511 comments. 1513 o Split the old Table 3 into two for better readability. 1515 o Fixed examples to use correct PIDF XML namespace declarations and 1516 MIME type. 1518 o Added reference to ABNF. 1520 18.4 Changes since "draft-ietf-sip-publish-00" 1522 The following changes were made since the last version: 1524 o Specified the role of the Request-URI in identifying the 1525 publication target resource. Also, clarified chapter 5 in this 1526 regard to explicitly talk about the identification of 1527 publications. 1529 o Changed chapter 6 to use Request-URI in determining the 1530 publication target resource. Also clarified language within the 1531 processing steps of an ESC. 1533 o Added missing header fields and removed unneeded "proxy" column in 1534 Table 1 and Table 2. Corrected Table 3 content. 1536 o Corrected various nits in examples and in body text. 1538 18.5 Changes since "draft-ietf-simple-publish-01" 1540 The following changes were made since the last version: 1542 o Submitted as "draft-ietf-sip-publish-00". 1544 o Changed title to better reflect the content. 1546 o Removed event state segmentation and collision detection of 1547 segments, and simplified usage of entity-tags. 1549 o Rewrote Ch 4 "Considerations for Event Packages Using PUBLISH" to 1550 mimic the way RFC 3265 defines considerations for event packages. 1551 Also, removed normative dependency to 1552 "draft-ietf-simple-publish-reqs". 1554 o Rewrote Ch 9 "Security Considerations" to now include text about 1555 specific vulnerabilities and the security tools to counter those 1556 attacks. 1558 o Clarified both UAC and UAS usage of entity-tags. Moved common 1559 error handling of UACs to a separate sub-section. 1561 o Improved description of UAS functionality of Ch 6 "Processing 1562 PUBLISH Requests", and alinged it with RFC 3261 Chapter 10 on 1563 processing registrations. 1565 o Changed entity-tag syntax from "quoted-string" to "token". This 1566 is a deviation from RFC 2616 entity-tag syntax, but more aligned 1567 to how similar things are expressed in SIP. 1569 o Restricted the If-Match header syntax to only allow a single 1570 entity-tag. Multiple entity-tags are not applicable to PUBLISH. 1572 o Added methods other than PUBLISH to Table 3. 1574 o Rewrote Ch 10 "Examples" to better reflect actual PUBLISH usage. 1576 o Changed reference [10] from caller-prefs to callee-caps. 1578 o Overall language and structure tweaking. 1580 18.6 Changes since "draft-ietf-simple-publish-00" 1582 The following changes were made since the last version: 1584 o Merged with "draft-olson-simple-publish-02" 1586 o Removed usage of Call-ID and CSeq for ordering 1588 o Removed timestamp based versioning 1590 o Added versioning based on entity-tag version information (ETag), 1591 and request precondition (If-Match) 1593 o Changed reference to content-indirection as Informative 1595 o Added section for ABNF definitions 1597 o Editorial corrections, restructuring of document to improve 1598 readability 1600 o Moved the original authors into a new "Contributors" section 1602 o Added new definitions in Terminology, and clarified EPA and ESC 1603 definitions 1605 o Strengthened the IANA considerations section. 1607 o Added text for announcing/probing support for publish, namely 1608 OPTIONS and "methods" parameter usage. 1610 19. References 1612 19.1 Normative References 1614 [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1615 Notification", RFC 3265, June 2002. 1617 [2] Rosenberg, J., "A Presence Event Package for the Session 1618 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 1619 in progress), January 2003. 1621 [3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 1622 Instant Messaging", RFC 2778, February 2000. 1624 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1625 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1626 Session Initiation Protocol", RFC 3261, June 2002. 1628 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1629 Levels", BCP 14, RFC 2119, March 1997. 1631 [6] Sugano, H. and S. Fujimoto, "Presence Information Data Format 1632 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 1633 2003. 1635 [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1636 Specifications: ABNF", RFC 2234, November 1997. 1638 [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1639 2246, January 1999. 1641 [9] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 1642 2633, June 1999. 1644 19.2 Informative References 1646 [10] Campbell, B., "SIMPLE Presence Publication Requirements", 1647 draft-ietf-simple-publish-reqs-00 (work in progress), February 1648 2003. 1650 [11] Mahy, R., "A Message Summary and Message Waiting Indication 1651 Event Package for the Session Initiation Protocol (SIP)", 1652 draft-ietf-sipping-mwi-04 (work in progress), December 2003. 1654 [12] Rosenberg, J., "Indicating User Agent Capabilities in the 1655 Session Initiation Protocol (SIP)", 1656 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 1658 [13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1659 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 1660 HTTP/1.1", RFC 2616, June 1999. 1662 Author's Address 1664 Aki Niemi (editor) 1665 Nokia 1666 P.O. Box 100 1667 NOKIA GROUP, FIN 00045 1668 Finland 1670 Phone: +358 50 389 1644 1671 EMail: aki.niemi@nokia.com 1673 Intellectual Property Statement 1675 The IETF takes no position regarding the validity or scope of any 1676 intellectual property or other rights that might be claimed to 1677 pertain to the implementation or use of the technology described in 1678 this document or the extent to which any license under such rights 1679 might or might not be available; neither does it represent that it 1680 has made any effort to identify any such rights. Information on the 1681 IETF's procedures with respect to rights in standards-track and 1682 standards-related documentation can be found in BCP-11. Copies of 1683 claims of rights made available for publication and any assurances of 1684 licenses to be made available, or the result of an attempt made to 1685 obtain a general license or permission for the use of such 1686 proprietary rights by implementors or users of this specification can 1687 be obtained from the IETF Secretariat. 1689 The IETF invites any interested party to bring to its attention any 1690 copyrights, patents or patent applications, or other proprietary 1691 rights which may cover technology that may be required to practice 1692 this standard. Please address the information to the IETF Executive 1693 Director. 1695 Full Copyright Statement 1697 Copyright (C) The Internet Society (2004). All Rights Reserved. 1699 This document and translations of it may be copied and furnished to 1700 others, and derivative works that comment on or otherwise explain it 1701 or assist in its implementation may be prepared, copied, published 1702 and distributed, in whole or in part, without restriction of any 1703 kind, provided that the above copyright notice and this paragraph are 1704 included on all such copies and derivative works. However, this 1705 document itself may not be modified in any way, such as by removing 1706 the copyright notice or references to the Internet Society or other 1707 Internet organizations, except as needed for the purpose of 1708 developing Internet standards in which case the procedures for 1709 copyrights defined in the Internet Standards process must be 1710 followed, or as required to translate it into languages other than 1711 English. 1713 The limited permissions granted above are perpetual and will not be 1714 revoked by the Internet Society or its successors or assignees. 1716 This document and the information contained herein is provided on an 1717 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1718 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1719 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1720 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1721 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1723 Acknowledgment 1725 Funding for the RFC Editor function is currently provided by the 1726 Internet Society.