idnits 2.17.1 draft-ietf-simple-event-list-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1869. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) 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 == Line 814 has weird spacing: '...erminal pres...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (December 15, 2004) is 7072 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: 'RFCXXXX' on line 1627 == Unused Reference: '3' is defined on line 1682, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1705, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1717, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1724, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 1521 (ref. '3') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1766 (ref. '6') (Obsoleted by RFC 3066, RFC 3282) == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-03 == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-04 -- Obsolete informational reference (is this intentional?): RFC 3023 (ref. '12') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. '13') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '15') (Obsoleted by RFC 9110) Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft B. Campbell 4 Expires: June 15, 2005 Estacado Systems 5 J. Rosenberg 6 Cisco Systems 7 December 15, 2004 9 A Session Initiation Protocol (SIP) Event Notification Extension for 10 Resource Lists 11 draft-ietf-simple-event-list-07 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 4 of RFC3667. By submitting this Internet- 17 Draft, each author represents that any applicable patent or other IPR 18 claims of which he or she is aware have been or will be disclosed, 19 and any of which he or she become aware will be disclosed, in 20 accordance with RFC 3668. 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 Internet- 25 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 June 15, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document presents an extension to the Session Initiation 47 Protocol (SIP)-Specific Event Notification mechanism for subscribing 48 to a homogeneous list of resources. Instead of the subscriber 49 sending a SUBSCRIBE for each resource individually, the subscriber 50 can subscribe to an entire list, and then receive notifications when 51 the state of any of the resources in the list changes. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 6 58 4. Operation of List Subscriptions . . . . . . . . . . . . . . 7 59 4.1 Negotiation of Support for Resource Lists . . . . . . . . . 7 60 4.2 Subscription Duration . . . . . . . . . . . . . . . . . . . 8 61 4.3 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.4 RLS Processing of SUBSCRIBE Requests . . . . . . . . . . . . 8 63 4.5 RLS Generation of NOTIFY requests . . . . . . . . . . . . . 9 64 4.6 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 10 65 4.7 Handling of Forked Requests . . . . . . . . . . . . . . . . 11 66 4.8 Rate of Notifications . . . . . . . . . . . . . . . . . . . 11 67 5. Using multipart/related to Convey Aggregate State . . . . . 13 68 5.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 15 70 5.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 16 71 5.4 Name Attributes . . . . . . . . . . . . . . . . . . . . . . 16 72 5.5 Instance Attributes . . . . . . . . . . . . . . . . . . . . 16 73 5.6 Constructing Coherent Resource State . . . . . . . . . . . . 18 74 5.6.1 Processing Full State Notifications . . . . . . . . . . . . 19 75 5.6.2 Processing Partial State Notifications . . . . . . . . . . . 19 76 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 7. Security Considerations . . . . . . . . . . . . . . . . . . 34 78 7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34 79 7.1.1 RLS and Subscriber in the Same Domain . . . . . . . . . . . 34 80 7.1.2 RLS and Subscriber in Different Domains . . . . . . . . . . 35 81 7.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 35 82 7.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 36 83 7.4 Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . 36 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 85 8.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 38 86 8.2 New MIME type for Resource List Meta-Information . . . . . . 38 87 8.3 URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . . 39 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 89 Normative References . . . . . . . . . . . . . . . . . . . . 42 90 Informative References . . . . . . . . . . . . . . . . . . . 43 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 92 A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 45 93 A.1 Changes since -06 . . . . . . . . . . . . . . . . . . . . . 45 94 A.2 Changes since -05 . . . . . . . . . . . . . . . . . . . . . 45 95 A.3 Changes since -04 . . . . . . . . . . . . . . . . . . . . . 45 96 A.4 Changes since -03 . . . . . . . . . . . . . . . . . . . . . 45 97 A.5 Changes since -02 . . . . . . . . . . . . . . . . . . . . . 46 98 A.6 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 46 99 A.7 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 46 100 B. Intellectual Property Statement . . . . . . . . . . . . . . 47 101 Full Copyright Statement . . . . . . . . . . . . . . . . . . 48 103 1. Introduction 105 The SIP-specific event notification mechanism [2] allows a user (the 106 subscriber) to request to be notified of changes in the state of a 107 particular resource. This is accomplished by having the subscriber 108 generate a SUBSCRIBE request for the resource, which is processed by 109 a notifier that represents the resource. 111 In many cases, a subscriber has a list of resources they are 112 interested in. Without some aggregating mechanism, this will require 113 the subscriber generate a SUBSCRIBE request for each resource about 114 which they want information. For environments in which bandwidth is 115 limited, such as wireless networks, subscribing to each resource 116 individually is problematic. Some specific problems are: 118 o Doing so generates substantial message traffic, in the form of the 119 initial SUBSCRIBE requests for each resource, and the refreshes of 120 each individual subscription. 122 o The notifier may insist on low refresh intervals, in order to 123 avoid long lived subscription state. This means that the 124 subscriber may need to generate SUBSCRIBE refreshes faster than it 125 would like to, or has the capacity to. 127 o The notifier may generate NOTIFY requests more rapidly than the 128 subscriber desires, causing NOTIFY traffic at a greater volume 129 than is desired by the subscriber. 131 To solve these problems, this specification defines an extension to 132 RFC 3265 [2] that allows for requesting and conveying notifications 133 for lists of resources. A resource list is identified by a URI and 134 it represents a list of zero or more URIs. Each of these URIs is an 135 identifier for an individual resource for which the subscriber wants 136 to receive information. In many cases, the URI used to identify the 137 resource list will be a SIP URI [1]; however, the use of other 138 schemes (such as pres: [10]) is also foreseen. 140 The notifier for the list is called a "resource list server", or RLS. 141 In order to determine the state of the entire list, the RLS will act 142 as if it has generated a subscription to each resource in the list. 144 The resource list is not restricted to be inside the domain of the 145 subscriber. Similarly, the resources in the list are not constrained 146 to be in the domain of the resource list server. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [5]. 154 The following terms are used throughout the remainder of this 155 document. 157 Back-End Subscription: Any subscription (SIP or otherwise) that an 158 RLS creates to learn of the state of a resource. An RLS will 159 create back-end subscriptions to learn of the state of a resource 160 about which the RLS is not an authority. For back-end 161 subscriptions, RLSes act as a subscriber. 163 List Subscription: A subscription to a resource list. In list 164 subscriptions, RLSes act a the notifier. 166 Resource: A resource is any logical entity that has a state or states 167 that can be subscribed to. Resources are identified by URIs. 169 Resource List: A list of zero or more resources that can have their 170 individual states subscribed to with a single subscription. 172 RLMI: Resource List Meta-Information. RLMI is a document that 173 describes the state of the virtual subscriptions associated with a 174 list subscription. 176 RLS: Resource List Server. RLSes accept subscriptions to resource 177 lists and send notifications to update subscribers of the state of 178 the resources in a resource list. 180 Virtual Subscription: Virtual Subscriptions are a logical construct 181 within an RLS that represent subscriptions to the resources in a 182 resource list. For each list subscription it services, an RLS 183 creates at least one virtual subscription for every resource in 184 the resource list being subscribed to. In some cases, such as 185 when the RLS is not the authority for the state of the resource, 186 this virtual subscription will be associated with a back-end 187 subscription. In other cases, such as when the RLS is the 188 authority for the state of the resource, the virtual subscription 189 will not have a corresponding back-end subscription. 191 3. Overview of Operation 193 This section provides an overview of the typical mode of operation of 194 this extension. It is not normative. 196 When users wish to subscribe to the resource of a list of resources, 197 they can use the mechanisms described in this specification. The 198 first step is creation of a resource list. This resource list is 199 represented by a SIP URI. The list contains a set of URIs, each of 200 which represents a resource for which the subscriber wants to receive 201 information. The resource list can exist in any domain. The list 202 could be manipulated through a web page, through a voice response 203 system, or through some other protocol. The specific means by which 204 the list is created and maintained is outside of the scope of this 205 specification. 207 To learn the resource state of the set of elements on the list, the 208 user sends a single SUBSCRIBE request targeted to the URI of the 209 list. This will be routed to an RLS for that URI. The RLS acts as a 210 notifier, authenticates the subscriber, and accepts the subscription. 212 The RLS may have direct information about some or all of the 213 resources specified by the list. If it does not, it could subscribe 214 to any non-local resources specified by the list resource. 216 Note that subscriptions to non-local resources may or may not be SIP 217 subscriptions; any mechanism for determining such information may be 218 employed. This document uses the term "back-end subscription" to 219 refer to such a subscription, regardless of whether SIP is used to 220 establish and service it. 222 As the state of resources in the list change, the RLS generates 223 notifications to the list subscribers. The RLS can, at its 224 discretion, buffer notifications of resource changes, and send the 225 resource information to the subscriber in batches, rather than 226 individually. This allows the RLS to provide rate limiting for the 227 subscriber. 229 The list notifications contain a body of type multipart/related. The 230 root section of the multipart/related content is an XML document that 231 provides meta-information about each resource present in the list. 232 The remaining sections contain the actual state information for each 233 resource. 235 4. Operation of List Subscriptions 237 The event list extension acts, in many ways, like an event template 238 package. In particular, any single list subscription must be 239 homogeneous with respect to the underlying event package. In other 240 words, a single list subscription can apply only one event package to 241 all of the resources in the resource list. 243 It is worth noting that it is perfectly valid, for an RLS to allow 244 multiple subscriptions to the same list to use differing event 245 packages. 247 The key difference between a list subscription and templates in 248 general is that support for list subscriptions indicates support for 249 arbitrary nesting of list subscriptions. In other words, elements 250 within the list may be atomic elements, or they may be lists 251 themselves. 253 The consequence of this is that subscription to a URI that represents 254 a list actually results in a several virtual subscriptions to a tree 255 of resources. The leaf nodes of this tree are virtual subscriptions 256 of the event type given in the "Event" header field; all other nodes 257 in the tree are list subscriptions that are serviced as described in 258 this section and its subsections. 260 It is important to keep in mind that these virtual subscriptions are 261 not literal SIP subscriptions (although they may result in SIP 262 subscriptions, depending on the RLS implementation). 264 4.1 Negotiation of Support for Resource Lists 266 This specification uses the SIP option tag mechanism for negotiating 267 support for the extension defined herein. Refer to RFC3261 [1] for 268 the normative description of processing of the "Supported" and 269 "Require" header fields and the 421 (Extension Required) response 270 code. 272 A non-normative description of the implications of the use of 273 option tags follows. 275 Any client that supports the event list extension will include an 276 option tag of "eventlist" in a "Supported" header field of every 277 SUBSCRIBE message for a subscription for which it is willing to 278 process a list. If the subscription is made to a URI that 279 represents a list, the RLS will include "eventlist" in a "Require" 280 header field of the response to the SUBSCRIBE, and in all NOTIFY 281 messages within that subscription. 283 Use of "Require: eventlist" in NOTIFY messages is applied by the 284 notifier to satisfy the RFC3261 requirement that a UAC MUST insert 285 a Require header field into a request if the UAC wishes to insist 286 that a UAS understand an extension in order to process the 287 request. Because the NOTIFY would not be usable without applying 288 the eventlist option, the notifier is obligated to include it. 290 Including "eventlist" in a "Require" header field in a SUBSCRIBE 291 request serves no purpose except breaking interoperability in certain 292 cases, and is consequently NOT RECOMMENDED. 294 Sending of "Supported: eventlist" in a NOTIFY message is meaningless 295 and silly. Implementations SHOULD NOT include "Supported: eventlist" 296 in any requests except for SUBSCRIBE. 298 There is nothing in a SIP URI which indicates whether it represents a 299 list of resources or a single resource. Therefore, if a subscriber 300 sends a request to a URI that represents a list resource, but does 301 not include a Supported header field listing the "eventlist" token, 302 the notifier will typically return a 421 (Extension Required) 303 response code. RFC 3261 [1] advises servers to avoid returning a 304 421, and instead, attempt to process the request without the 305 extension. However, in this case, the URI fundamentally represents a 306 list resource, and therefore, the subscription cannot proceed without 307 this extension. 309 4.2 Subscription Duration 311 Since the primary benefit of the resource list server is to reduce 312 the overall messaging volume to a subscriber, it is RECOMMENDED that 313 the subscription duration to a list be reasonably long. The default, 314 when no duration is specified, is taken from the underlying event 315 package. Of course, the standard techniques [2] can be used to 316 increase or reduce this amount. 318 4.3 NOTIFY Bodies 320 An implementation compliant to this specification MUST support the 321 multipart/related and application/rlmi+xml MIME types. These types 322 MUST be included in an Accept header sent in SUBSCRIBE message, in 323 addition to any other types supported by the client (including any 324 types required by the event package being used). 326 4.4 RLS Processing of SUBSCRIBE Requests 328 Once the subscriber is authenticated, the RLS performs authorization 329 per its local policy. In many cases, each resource list is 330 associated with a particular user (the one who created it and manages 331 the set of elements in it), and only that user will be allowed to 332 subscribe. Of course, this mode of operation is not inherent in the 333 use of resource lists, and an RLS can use any authorization policy it 334 chooses. 336 4.5 RLS Generation of NOTIFY requests 338 This specification leaves the choice about how and when to generate 339 NOTIFY requests at the discretion of the implementor. One of the 340 value propositions of the RLS is the means by which it aggregates, 341 rate limits, or optimizes the way in which notifications are 342 generated. As a baseline behavior, the RLS MAY generate a NOTIFY to 343 the RLS subscriber whenever the state of any resource on the list 344 changes. 346 It is important to understand that any given subscription is a 347 subscription to either a single resource, or to a list of resources. 348 This nature (single resource versus list of resources) cannot change 349 during the duration of a single subscription. In particular, this 350 means that RLSes MUST NOT send NOTIFY messages which do not contain 351 RLMI for a subscription if they have previously sent NOTIFY messages 352 in that subscription containing RLMI. Similarly, RLSes MUST NOT send 353 NOTIFY messages which do contain RLMI for a subscription if they have 354 previously sent NOTIFY messages in that subscription which do not. 356 List representations necessarily contain RLMI documents for two 357 reasons. Importantly, they identify the resource to which event 358 state corresponds. Many state syntaxes do not fully identify the 359 resource to which the state applies, or may identify the resource 360 in a different way than it is represented in the list; for 361 example, PIDF documents may contain resource URIs which are not 362 identical to the URI used to retrieve them. Further, RLMI 363 documents serve to disambiguate multiple instances of a single 364 resource. 366 See Section 5 for a detailed definition of the syntax used to convey 367 the state of resource lists. For the purposes of the following 368 discussion, it is important to know that the overall list contains 369 zero or more resources, and that the resources contains zero or more 370 instances. Each instance has a state associated with it (pending, 371 active, or terminating), representing the state of the virtual 372 subscription. 374 Notifications contain a multipart document, the first part of which 375 always contains meta-information about the list (e.g. membership, 376 state of the virtual subscription to the resource). Remaining parts 377 are used to convey the actual state of the resources listed in the 378 meta-information. 380 The "state" attribute of each instance of a resource in the meta- 381 information is set according to the state of the virtual 382 subscription. The meanings of the "state" attribute are described in 383 RFC 3265 [2]. 385 If an instance of a resource was previously reported to the 386 subscriber but is no longer available (i.e. the virtual subscription 387 to that instance has been terminated), the resource list server 388 SHOULD include that resource instance in the meta-information in the 389 first NOTIFY message sent to the subscriber following the instance's 390 unavailability. The RLS MAY continue to do so for future 391 notifications. 393 When sending information for a terminated resource instance, the RLS 394 indicates a state of "terminated" and an appropriate reason value. 395 Valid reason values and their meanings are described in RFC 3265 [2]. 396 If the RLS will attempt to recover the resource state again at some 397 point in the future (e.g. when the reason in the meta-information is 398 "probation"), then the instance of the resource SHOULD remain in the 399 meta-information until the instance state is available, or until the 400 RLS gives up on making such state available. 402 When the first SUBSCRIBE message for a particular subscription is 403 received by a RLS, the RLS will often not know state information for 404 all of the resources specified by the resource list. For any 405 resource for which state information is not known, the corresponding 406 "uri" attribute will be set appropriately, and no elements 407 will be present for the resource. 409 For an initial notification, sections corresponding to resources for 410 which the RLS does have state will be populated with appropriate data 411 (subject, of course, to local policy decisions). This will often 412 occur if the resource list server is co-located with the server for 413 one or more of the resources specified on the list. 415 Immediate notifications triggered as a result of subsequent SUBSCRIBE 416 messages SHOULD include an RLMI document with full state indicated. 417 The RLS SHOULD also include state information for all resources in 418 the list for which the RLS has state, subject to policy restrictions. 419 This allows the subscriber to refresh their state, and to recover 420 from lost notifications. 422 4.6 Subscriber Processing of NOTIFY Requests 424 Notifications for a resource list can convey information about a 425 subset of the list elements. This means that an explicit algorithm 426 needs to be defined in order to construct coherent and consistent 427 state. 429 The XML document present in the root of the multipart/related 430 document contains a element for some or all of the 431 resources in the list. Each element contains a URI which 432 uniquely identifies the resource to which that section corresponds. 433 When a NOTIFY arrives, it can contain full or partial state (as 434 indicated by the "fullState" attribute of the top-level 435 element). If full state is indicated, then the recipient replaces 436 all state associated with the list with the entities in the NOTIFY 437 body. If full state is not indicated, the recipient of the NOTIFY 438 updates information for each identified resource. Information for 439 any resources that are not identified in the NOTIFY are not changed, 440 even if they were indicated in previous NOTIFY messages. See Section 441 5.6 for more information. 443 When full state is indicated, note that it applies only to the 444 RLMI document in which it occurs. In particular, one of the 445 elements in the document may in turn refer to another 446 list of resources. Any such sub-lists will be detailed in their 447 own RLMI documents, which may or may not have full state 448 indicated. 450 Further note that underlying event package may have its own rules 451 for compositing partial state notification. When processing data 452 related to those packages, their rules apply (i.e. the fact that 453 they were reported as part of a list does not change their partial 454 notification semantics). 456 Finally, note that a consequence of the way in which resource list 457 subscriptions work is that polling of resource state may not be 458 particularly useful. While such polls will retrieve the resource 459 list, they will not necessarily contain state for some or all of 460 the resources on the list. 462 4.7 Handling of Forked Requests 464 Forking makes little sense with subscriptions to event lists, since 465 the whole idea is a centralization of the source of notifications. 466 Therefore, a subscriber to a list MUST NOT install multiple 467 subscriptions when the initial request is forked. If multiple 468 responses are received, they are handled using the techniques 469 described in section 4.4.9 of RFC 3265[2]. 471 4.8 Rate of Notifications 473 One potential role of the RLS is to perform rate limitations on 474 behalf of the subscriber. As such, this specification does not 475 mandate any particular rate limitation, and rather leaves that to the 476 discretion of the implementation. 478 5. Using multipart/related to Convey Aggregate State 480 In order to convey the state of multiple resources, the list 481 extension uses the "multipart/related" mime type. The syntax for 482 multipart/related is defined in "The MIME Multipart/Related Content- 483 type" [4]. 485 5.1 XML Syntax 487 The root document of the multipart/related body MUST be a Resource 488 List Meta-Information (RLMI) document. It is of type "application/ 489 rlmi+xml". This document contains the meta-information for the 490 resources contained in the notification. The schema for this XML 491 document is given below. 493 494 498 499 500 501 503 505 506 507 509 511 512 513 514 515 516 517 518 520 522 523 524 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 543 544 545 546 547 548 549 550 551 553 554 555 556 557 559 An example of a document formatted using this schema follows. 561 562 565 Buddy List 566 Liste d'amis 567 571 572 573 Dave Jones 574 576 577 578 Jim 579 581 582 583 Ed 584 585 586 588 5.2 List Attributes 590 The element present in a list notification MUST contain three 591 attributes. 593 The first mandatory attribute is "uri", which contains the uri 594 that corresponds to the list. Typically, this is the URI to which 595 the SUBSCRIBE request was sent. 597 The second mandatory attribute is "version", which contains a 598 number from 0 to 2^32-1. This version number MUST be 0 for the first 599 NOTIFY message sent within a subscription, and MUST increase by 600 exactly one for each subsequent NOTIFY sent within a subscription. 602 The third mandatory attribute is "fullState". The "fullState" 603 attribute indicates whether the NOTIFY message contains information 604 for every resource in the list. If it does, the value of the 605 attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The 606 first NOTIFY sent in a subscription MUST contain full state, as must 607 the first NOTIFY sent after receipt of a SUBSCRIBE request for the 608 subscription. 610 Finally, elements MAY contain a "cid" attribute. If present, 611 the "cid" attribute identifies a section within the multipart/related 612 body that contains aggregate state information for the resources 613 contained in the list. The definition of such aggregate information 614 is outside the scope of this document, and will be defined on a per- 615 package basis as needed. The cid attribute is the Content-ID for the 616 corresponding section in the multipart body. 618 The cid attribute MUST refer only to top-level parts of the 619 multipart/related document for which the RLMI document in which it 620 appears is the root. See Section 5.5 for an example. 622 5.3 Resource Attributes 624 The resource list contains one element for each resource 625 being reported in the notification. These resource elements contain 626 attributes that identify meta-data associated with each resource. 628 The "uri" attribute identifies the resource to which the 629 element corresponds. Typically, this will be a SIP URI which, if 630 subscribed to, would return the state of the resource. This 631 attribute MUST be present. 633 5.4 Name Attributes 635 Each list and resource element contains zero or more name elements. 636 These name elements contain human readable descriptions or names for 637 the resource list or resource. The contents of these elements are 638 somewhat analogous to the "Display Name" present in the SIP name-addr 639 element. 641 Name elements contain an optional attribute, called "language". The 642 "language" attribute, if present, specifies the language of the 643 human-readable name. If this attribute is present, is MUST contain a 644 valid language tag. Language tags are defined in RFC 1766 [6]. The 645 language tag assists applications in determining which of potentially 646 several name elements should be rendered to the user. 648 5.5 Instance Attributes 650 Each resource element contains zero or more instance elements. These 651 instance elements are used to represent a single notifier for the 652 resource. For event packages that allow forking, multiple virtual 653 subscriptions may exist for a given resource. Multiple virtual 654 subscriptions are represented as multiple instance elements in the 655 corresponding resource element. For subscriptions in which forking 656 does not occur, at most one instance will be present for a given 657 resource. 659 The "id" attribute contains an opaque string used to uniquely 660 identify the instance of the resource. The "id" attribute is unique 661 only within the context of a resource. Construction of this string 662 is an implementation decision. Any mechanism for generating this 663 string is valid, as long as uniqueness within the resource is 664 assured. 666 The "state" attribute contains the subscription state for the 667 identified instance of the resource. This attribute contains one of 668 the values "active", "pending", or "terminated". The meanings for 669 these values are as defined for the "Subscription-State" header field 670 in RFC 3265 [2]. 672 If the "state" attribute indicates "terminated", then a "reason" 673 attribute MUST also be present. This "reason" attribute has the same 674 values and meanings as given for the "reason" parameter on the 675 "Subscription-State" header field in RFC 3265 [2]. Note that the 676 "reason" attribute is included for informational purposes; the list 677 subscriber is not expected to take any automated actions based on the 678 reason value. 680 Finally, the "cid" attribute, which MUST be present if the "state" 681 attribute is "active", identifies the section within the multipart/ 682 related body that contains the actual resource state. This state is 683 expressed in the content type defined by the event package for 684 conveying state. The cid attribute is the Content-ID for the 685 corresponding section in the multipart body. 687 The cid attribute MUST refer only to top-level parts of the 688 multipart/related document for which the RLMI document in which it 689 appears is the root. 691 For example, consider a multipart/related document containing 692 three parts; we'll label these parts A, B, and C. Part A is type 693 application/rlmi+xml, part B is type multipart/related, and part C 694 is type application/pidf+xml. Part B is in turn a document 695 containing three parts: D, E, and F. Part D is of type 696 application/rlmi+xml, and parts E and F are of type application/ 697 pidf+xml. 699 +-------------------------------------------+ 700 | Top Level Document: multipart/related | 701 | | 702 | +---------------------------------------+ | 703 | | Part A: application/rlmi+xml | | 704 | +---------------------------------------+ | 705 | | Part B: multipart/related | | 706 | | | | 707 | | +-----------------------------------+ | | 708 | | | Part D: application/rlmi+xml | | | 709 | | +-----------------------------------+ | | 710 | | | Part E: application/pidf+xml | | | 711 | | +-----------------------------------+ | | 712 | | | Part F: application/pidf+xml | | | 713 | | +-----------------------------------+ | | 714 | | | | 715 | +---------------------------------------+ | 716 | | Part C: application/pidf+xml | | 717 | +---------------------------------------+ | 718 | | 719 +-------------------------------------------+ 721 Any "cid" attributes in document A must refer only to parts B or 722 C. Referring to parts D, E, or F would be illegal. Similarly, 723 Any "cid" attributes in document D must refer only to parts E or 724 F. Referring to any other parts would be illegal. 726 Also note that the subscription durations of any back-end 727 subscriptions are not propagated into the meta-information state 728 in any way. 730 5.6 Constructing Coherent Resource State 732 The resource list subscriber maintains a table for each resource 733 list. The table contains a row for each resource in the resource 734 list. Each row is indexed by the URI for that resource. That URI is 735 obtained from the "uri" attribute on each element. The 736 contents of each row contain the state of that resource as conveyed 737 in the resource document. 739 For resources that provide versioning information (which is mandated 740 by [2] for any formats that allow partial notification), each row 741 also contains a resource state version number. The version number of 742 the row is initialized with the version specified in the first 743 document received, as defined by the corresponding event package. 744 This value is used when comparing versions of partial notifications 745 for a resource. 747 The processing of the resource list notification depends on whether 748 it contains full or partial state. 750 5.6.1 Processing Full State Notifications 752 If a notification contains full state, indicated by the 753 attribute "fullState" set to "true", the notification is used to 754 update the table. A check is first made to ensure that the "version" 755 attribute of the attribute in the received message is greater 756 than the local version number. If not, the received document is 757 discarded without any further processing. Otherwise, the contents of 758 the resource-list table are flushed, and repopulated from the 759 contents of the document. A new row in the table is created for each 760 "resource" element. 762 5.6.2 Processing Partial State Notifications 764 If a notification contains partial state, indicated by the 765 attribute "fullState" set to "false", a check is made to ensure that 766 no list notifications have been lost. The value of the local version 767 number (the "version" attribute of the element) is compared to 768 the version number of the new document. 770 o If the value in the new document is exactly one higher than the 771 local version number, the local version number is increased by 772 one, and the document is processed, as described below. 774 o If the version in the document is more than one higher than the 775 local version number, the local version number is set to the value 776 in the new document, and the document is processed as described 777 below. The list subscriber SHOULD also generate a refresh request 778 to trigger a full state notification. 780 o If the version in the document is less than or equal to the local 781 version, the document is discarded without any further processing. 783 For each resource listed in the document, the subscriber checks to 784 see whether a row exists for that resource. This check is done by 785 comparing the Resource-URI value with the URI associated with the 786 row. If the resource doesn't exist in the table, a row is added, and 787 its state is set to the information from that "resource" element. If 788 the resource does exist, its state is updated to be the information 789 from that "resource" element, as described in the definition of the 790 event package. If a row is updated or created such that its state is 791 now "terminated," that entry MAY be removed from the table at any 792 time. 794 6. Example 796 This section gives an example call flow. It is not normative. If a 797 conflict arises between this call flow and the normative behavior 798 described in this or any other document, the normative descriptions 799 are to be followed. 801 In this particular example, we request a subscription to a nested 802 presence list. The subscriber's address-of-record is 803 "sip:adam@vancouver.example.com", and the name of the nested list 804 resource that we are subscribing to is called "sip:adam- 805 buddies@pres.vancouver.example.com". The underlying event package is 806 "presence", described by [8]. 808 In this example, the RLS has information to service some of the 809 resources on the list, but must consult other servers to retrieve 810 information for others. The implementation of the RLS in this 811 example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such 812 information. 814 Terminal pres.vancouver.example.com pres.stockholm.example.org 815 | | pres.dallas.example.net | 816 1 |---SUBSCRIBE--->| | | 817 2 |<-----200-------| | | 818 3 |<----NOTIFY-----| | | 819 4 |------200------>| | | 820 5 | |---SUBSCRIBE--->| | 821 6 | |<-----200-------| | 822 7 | |<----NOTIFY-----| | 823 8 | |------200------>| | 824 9 | |------------SUBSCRIBE----------->| 825 10| |<--------------200---------------| 826 11| |<-------------NOTIFY-------------| 827 12| |---------------200-------------->| 828 13|<----NOTIFY-----| | | 829 14|------200------>| | | 831 1. We initiate the subscription by sending a SUBSCRIBE message to 832 our local RLS. (There is no reason that the RLS we contact has 833 to be in our domain, of course). Note that we must advertise 834 support for application/rlmi+xml and multipart/related because 835 we support the eventlist extension, and we must advertise 836 application/pidf+xml because we are requesting a subscription to 837 presence. 839 Terminal -> Local RLS 841 SUBSCRIBE sip:adam-buddies@pres.vancouver.example.com SIP/2.0 842 Via: SIP/2.0/TCP terminal.vancouver.example.com; 843 branch=z9hG4bKwYb6QREiCL 844 Max-Forwards: 70 845 To: 846 From: ;tag=ie4hbb8t 847 Call-ID: cdB34qLToC@terminal.vancouver.example.com 848 CSeq: 322723822 SUBSCRIBE 849 Contact: 850 Event: presence 851 Expires: 7200 852 Supported: eventlist 853 Accept: application/pidf+xml 854 Accept: application/rlmi+xml 855 Accept: multipart/related 856 Accept: multipart/signed 857 Accept: application/pkcs7-mime 858 Content-Length: 0 860 2. The Local RLS completes the SUBSCRIBE transaction. Note that 861 authentication and authorization would normally take place at 862 this point in the call flow. Those steps are omitted for 863 brevity. 865 Local RLS -> Terminal 867 SIP/2.0 200 OK 868 Via: SIP/2.0/TCP terminal.vancouver.example.com; 869 branch=z9hG4bKwYb6QREiCL 870 To: ;tag=zpNctbZq 871 From: ;tag=ie4hbb8t 872 Call-ID: cdB34qLToC@terminal.vancouver.example.com 873 CSeq: 322723822 SUBSCRIBE 874 Contact: 875 Expires: 7200 876 Require: eventlist 877 Content-Length: 0 879 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY 880 immediately upon accepting the subscription. In this example, 881 we are assuming that the local RLS is also an authority for 882 presence information for the users in the 883 "vancouver.example.com" domain. The NOTIFY contains an RLMI 884 document describing the entire buddy list (initial notifies 885 require full state), as well as presence information for the 886 users about which it already knows. Note that, since the RLS 887 has not yet retrieved information for some of the entries on the 888 list, those elements contain no elements. 890 Local RLS -> Terminal 892 NOTIFY sip:terminal.vancouver.example.com SIP/2.0 893 Via: SIP/2.0/TCP pres.vancouver.example.com; 894 branch=z9hG4bKMgRenTETmm 895 Max-Forwards: 70 896 From: ;tag=zpNctbZq 897 To: ;tag=ie4hbb8t 898 Call-ID: cdB34qLToC@terminal.vancouver.example.com 899 CSeq: 997935768 NOTIFY 900 Contact: 901 Event: presence 902 Subscription-State: active;expires=7200 903 Require: eventlist 904 Content-Type: multipart/related;type="application/rlmi+xml"; 905 start=""; 906 boundary="50UBfW7LSCVLtggUPe5z" 907 Content-Length: 1560 909 --50UBfW7LSCVLtggUPe5z 910 Content-Transfer-Encoding: binary 911 Content-ID: 912 Content-Type: application/rlmi+xml;charset="UTF-8" 914 915 918 Buddy List at COM 919 Liste der Freunde an COM 920 921 Bob Smith 922 924 925 926 Dave Jones 927 929 930 931 Ed at NET 932 933 934 My Friends at ORG 935 Meine Freunde an ORG 936 937 939 --50UBfW7LSCVLtggUPe5z 940 Content-Transfer-Encoding: binary 941 Content-ID: 942 Content-Type: application/pidf+xml;charset="UTF-8" 944 945 947 948 949 open 950 951 sip:bob@vancouver.example.com 952 953 955 --50UBfW7LSCVLtggUPe5z 956 Content-Transfer-Encoding: binary 957 Content-ID: 958 Content-Type: application/pidf+xml;charset="UTF-8" 960 961 963 964 965 closed 966 967 968 970 --50UBfW7LSCVLtggUPe5z-- 972 4. The terminal completes the transaction. 974 Terminal -> Local RLS 976 SIP/2.0 200 OK 977 Via: SIP/2.0/TCP pres.vancouver.example.com; 978 branch=z9hG4bKMgRenTETmm 979 From: ;tag=zpNctbZq 980 To: ;tag=ie4hbb8t 981 Call-ID: cdB34qLToC@terminal.vancouver.example.com 982 CSeq: 997935768 NOTIFY 983 Contact: 984 Content-Length: 0 986 5. In order to service the subscription, the local RLS subscribes 987 to the state of the resources. In this step, the RLS attempts 988 to subscribe to the presence state of the resource 989 "sip:ed@dallas.example.net". Since the local RLS knows how to 990 receive notifications for list subscriptions, it includes the 991 "Supported: eventlist" header field in its request. Although 992 the linkage between this subscription and the one sent by the 993 terminal is left up to the application, this message 994 demonstrates some reasonable behavior by including "Accept" 995 header fields for all of the body types it knows the subscriber 996 (Terminal) supports. This is safe to do, since the local RLS 997 will only pass these formats through to the subscriber, and does 998 not need to actually understand them. 1000 Local RLS -> Presence Server in dallas.example.net 1002 SUBSCRIBE sip:ed@dallas.example.net SIP/2.0 1003 Via: SIP/2.0/TCP pres.vancouver.example.com; 1004 branch=z9hG4bKMEyGjdG1LH 1005 Max-Forwards: 70 1006 To: 1007 From: ;tag=aM5icQu9 1008 Call-ID: Ugwz5ARxNw@pres.vancouver.example.com 1009 CSeq: 870936068 SUBSCRIBE 1010 Contact: 1011 Identity: Tm8sIHRoaXMgaXNuJ3QgYSByZWFsIGNlcnQuIFlvdSBvn 1012 Zpb3VzbHkgaGF2ZSB0aW1lIHRvIGtpbGwuIEkKc3VnZ2V 1013 zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8K 1014 Identity-Info: https://vancouver.example.com/cert 1015 Event: presence 1016 Expires: 3600 1017 Supported: eventlist 1018 Accept: application/pidf+xml 1019 Accept: application/rlmi+xml 1020 Accept: multipart/related 1021 Accept: multipart/signed 1022 Accept: application/pkcs7-mime 1023 Content-Length: 0 1025 6. The Presence Server in dallas.example.net completes the 1026 SUBSCRIBE transaction. Note that authentication would normally 1027 take place at this point in the call flow. Those steps are 1028 omitted for brevity. 1030 Presence Server in dallas.example.net -> Local RLS 1032 SIP/2.0 200 OK 1033 Via: SIP/2.0/TCP pres.vancouver.example.com; 1034 branch=z9hG4bKMEyGjdG1LH 1035 To: ;tag=e45TmHTh 1036 From: ;tag=aM5icQu9 1037 Call-ID: Ugwz5ARxNw@pres.vancouver.example.com 1038 CSeq: 870936068 SUBSCRIBE 1039 Contact: 1040 Expires: 3600 1041 Content-Length: 0 1043 7. In this example, we assume that the server at dallas.example.net 1044 doesn't have enough authorization information to reject or 1045 accept our subscription. The initial notify, therefore, 1046 contains a "Subscription-State" of "pending". Presumably, the 1047 party responsible for accepting or denying authorization for the 1048 resource is notified of this change; however, those steps are 1049 not included in this call flow for brevity. 1051 Presence Server in dallas.example.net -> Local RLS 1053 NOTIFY sip:pres.vancouver.example.com SIP/2.0 1054 Via: SIP/2.0/TCP pres.dallas.example.net; 1055 branch=z9hG4bKfwpklPxmrW 1056 Max-Forwards: 70 1057 From: ;tag=e45TmHTh 1058 To: ;tag=aM5icQu9 1059 Call-ID: Ugwz5ARxNw@pres.vancouver.example.com 1060 CSeq: 1002640632 NOTIFY 1061 Contact: 1062 Subscription-State: pending;expires=3600 1063 Event: presence 1064 Require: eventlist 1065 Content-Length: 0 1067 8. The local RLS completes the NOTIFY transaction. Note that, at 1068 this point, the Local RLS has new information to report to the 1069 subscriber. Whether it chooses to report the information 1070 immediately or spool it up for later delivery is completely up 1071 to the application. For this example, we assume that the RLS 1072 will wait for a short period of time before doing so, in order 1073 to allow the subscriptions it sent out sufficient time to 1074 provide useful data. 1076 Local RLS -> Presence Server in dallas.example.net 1078 SIP/2.0 200 OK 1079 Via: SIP/2.0/TCP pres.dallas.example.net; 1080 branch=z9hG4bKfwpklPxmrW 1081 From: ;tag=e45TmHTh 1082 To: ;tag=aM5icQu9 1083 Call-ID: Ugwz5ARxNw@pres.vancouver.example.com 1084 CSeq: 1002640632 NOTIFY 1085 Contact: 1086 Content-Length: 0 1087 9. The Local RLS subscribes to the state of the other non-local 1088 resource. 1090 Local RLS -> RLS in stockholm.example.org 1092 SUBSCRIBE sip:adam-friends@stockholm.example.org SIP/2.0 1093 Via: SIP/2.0/TCP pres.vancouver.example.com; 1094 branch=z9hG4bKFSrAF8CZFL 1095 Max-Forwards: 70 1096 To: 1097 From: ;tag=a12eztNf 1098 Call-ID: kBq5XhtZLN@pres.vancouver.example.com 1099 CSeq: 980774491 SUBSCRIBE 1100 Contact: 1101 Identity: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp 1102 bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p 1103 bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8K 1104 Identity-Info: https://vancouver.example.com/cert 1105 Event: presence 1106 Expires: 3600 1107 Supported: eventlist 1108 Accept: application/pidf+xml 1109 Accept: application/rlmi+xml 1110 Accept: multipart/related 1111 Accept: multipart/signed 1112 Accept: application/pkcs7-mime 1113 Content-Length: 0 1115 10. The RLS in stockholm.example.org completes the SUBSCRIBE 1116 transaction. Note that authentication and would normally take 1117 place at this point in the call flow. Those steps are omitted 1118 for brevity. 1120 RLS in stockholm.example.org -> Local RLS 1122 SIP/2.0 200 OK 1123 Via: SIP/2.0/TCP pres.vancouver.example.com; 1124 branch=z9hG4bKFSrAF8CZFL 1125 To: ;tag=JenZ40P3 1126 From: ;tag=a12eztNf 1127 Call-ID: kBq5XhtZLN@pres.vancouver.example.com 1128 CSeq: 980774491 SUBSCRIBE 1129 Contact: 1130 Expires: 3600 1131 Content-Length: 0 1133 11. In this example, we are assuming that the RLS in 1134 stockholm.example.org is also an authority for presence 1135 information for the users in the "stockholm.example.org" domain. 1136 The NOTIFY contains an RLMI document describing the contained 1137 buddy list, as well as presence information for those users. In 1138 this particular case, the RLS in stockholm.example.org has 1139 chosen to sign [14] the body of the NOTIFY message. As 1140 described in RFC 3851, signing is performed by creating a 1141 multipart/signed document which has two parts. The first part 1142 is the document to be signed (in this example, the multipart/ 1143 related document that describes the list resource states), while 1144 the second part is the actual signature. 1146 RLS in stockholm.example.org -> Local RLS 1148 NOTIFY sip:pres.vancouver.example.com SIP/2.0 1149 Via: SIP/2.0/TCP pres.stockholm.example.org; 1150 branch=z9hG4bKmGL1nyZfQI 1151 Max-Forwards: 70 1152 From: ;tag=JenZ40P3 1153 To: ;tag=a12eztNf 1154 Call-ID: kBq5XhtZLN@pres.vancouver.example.com 1155 CSeq: 294444656 NOTIFY 1156 Contact: 1157 Event: presence 1158 Subscription-State: active;expires=3600 1159 Require: eventlist 1160 Content-Type: multipart/signed; 1161 protocol="application/pkcs7-signature"; 1162 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1163 Content-Length: 2038 1165 --l3WMZaaL8NpQWGnQ4mlU 1166 Content-Transfer-Encoding: binary 1167 Content-ID: 1168 Content-Type: multipart/related;type="application/rlmi+xml"; 1169 start=""; 1170 boundary="tuLLl3lDyPZX0GMr2YOo" 1172 --tuLLl3lDyPZX0GMr2YOo 1173 Content-Transfer-Encoding: binary 1174 Content-ID: 1175 Content-Type: application/rlmi+xml;charset="UTF-8" 1177 1178 1181 Buddy List at COM 1182 Liste der Freunde an COM 1183 1184 Joe Thomas 1185 1187 1188 1189 Mark Edwards 1190 1192 1193 1195 --tuLLl3lDyPZX0GMr2YOo 1196 Content-Transfer-Encoding: binary 1197 Content-ID: 1198 Content-Type: application/pidf+xml;charset="UTF-8" 1200 1201 1203 1204 1205 open 1206 1207 sip:joe@stockholm.example.org 1208 1209 1211 --tuLLl3lDyPZX0GMr2YOo 1212 Content-Transfer-Encoding: binary 1213 Content-ID: 1214 Content-Type: application/pidf+xml;charset="UTF-8" 1216 1217 1219 1220 1221 closed 1222 1223 1224 1226 --tuLLl3lDyPZX0GMr2YOo-- 1228 --l3WMZaaL8NpQWGnQ4mlU 1229 Content-Transfer-Encoding: binary 1230 Content-ID: 1231 Content-Type: application/pkcs7-signature 1233 [PKCS #7 signature here] 1235 --l3WMZaaL8NpQWGnQ4mlU-- 1237 12. The Local RLS completes the NOTIFY transaction. 1239 Local RLS -> RLS in stockholm.example.org 1241 SIP/2.0 200 OK 1242 Via: SIP/2.0/TCP pres.stockholm.example.org; 1243 branch=z9hG4bKmGL1nyZfQI 1244 From: ;tag=JenZ40P3 1245 To: ;tag=a12eztNf 1246 Call-ID: kBq5XhtZLN@pres.vancouver.example.com 1247 CSeq: 294444656 NOTIFY 1248 Contact: 1249 Content-Length: 0 1251 13. At this point, the Local RLS decides it has collected enough 1252 additional information to warrant sending a new notification to 1253 the user. Although sending a full notification would be 1254 perfectly acceptable, the RLS decides to send a partial 1255 notification instead. The RLMI document contains only 1256 information for the updated resources, as indicated by setting 1257 the "fullState" parameter to "false". To avoid corrupting the 1258 S/MIME signature on the data received from the RLS in 1259 stockholm.example.org, the local RLS copies the entire 1260 multipart/signed body as-is into the notification that it sends. 1262 Local RLS -> Terminal 1264 NOTIFY sip:terminal.vancouver.example.com SIP/2.0 1265 Via: SIP/2.0/TCP pres.vancouver.example.com; 1266 branch=z9hG4bK4EPlfSFQK1 1267 Max-Forwards: 70 1268 From: ;tag=zpNctbZq 1269 To: ;tag=ie4hbb8t 1270 Call-ID: cdB34qLToC@terminal.vancouver.example.com 1271 CSeq: 997935769 NOTIFY 1272 Contact: 1273 Event: presence 1274 Subscription-State: active;expires=7200 1275 Require: eventlist 1276 Content-Type: multipart/related;type="application/rlmi+xml"; 1277 start="<2BEI83@pres.vancouver.example.com>"; 1278 boundary="TfZxoxgAvLqgj4wRWPDL" 1279 Content-Length: 2862 1281 --TfZxoxgAvLqgj4wRWPDL 1282 Content-Transfer-Encoding: binary 1283 Content-ID: <2BEI83@pres.vancouver.example.com> 1284 Content-Type: application/rlmi+xml;charset="UTF-8" 1286 1287 1290 Buddy List at COM 1291 Liste der Freunde an COM 1292 1293 Ed at NET 1294 1295 1296 1297 My Friends at ORG 1298 Meine Freunde an ORG 1299 1301 1302 1304 --TfZxoxgAvLqgj4wRWPDL 1305 Content-Transfer-Encoding: binary 1306 Content-ID: <1KQhyE@pres.vancouver.example.com> 1307 Content-Type: multipart/signed; 1308 protocol="application/pkcs7-signature"; 1309 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1311 --l3WMZaaL8NpQWGnQ4mlU 1312 Content-Transfer-Encoding: binary 1313 Content-ID: 1314 Content-Type: multipart/related;type="application/rlmi+xml"; 1315 start=""; 1316 boundary="tuLLl3lDyPZX0GMr2YOo" 1318 --tuLLl3lDyPZX0GMr2YOo 1319 Content-Transfer-Encoding: binary 1320 Content-ID: 1321 Content-Type: application/rlmi+xml;charset="UTF-8" 1323 1324 1327 Buddy List at ORG 1328 Liste der Freunde an ORG 1329 1330 Joe Thomas 1331 1333 1334 1335 Mark Edwards 1336 1338 1339 1341 --tuLLl3lDyPZX0GMr2YOo 1342 Content-Transfer-Encoding: binary 1343 Content-ID: 1344 Content-Type: application/pidf+xml;charset="UTF-8" 1346 1347 1349 1350 1351 open 1352 1353 sip:joe@stockholm.example.org 1355 1356 1358 --tuLLl3lDyPZX0GMr2YOo 1359 Content-Transfer-Encoding: binary 1360 Content-ID: 1361 Content-Type: application/pidf+xml;charset="UTF-8" 1363 1364 1366 1367 1368 closed 1369 1370 1371 1373 --tuLLl3lDyPZX0GMr2YOo-- 1375 --l3WMZaaL8NpQWGnQ4mlU 1376 Content-Transfer-Encoding: binary 1377 Content-ID: 1378 Content-Type: application/pkcs7-signature 1380 [PKCS #7 signature here] 1382 --l3WMZaaL8NpQWGnQ4mlU-- 1384 --TfZxoxgAvLqgj4wRWPDL-- 1386 14. The terminal completes the NOTIFY transaction. 1388 Terminal -> Local RLS 1390 SIP/2.0 200 OK 1391 Via: SIP/2.0/TCP pres.vancouver.example.com; 1392 branch=z9hG4bK4EPlfSFQK1 1393 From: ;tag=zpNctbZq 1394 To: ;tag=ie4hbb8t 1395 Call-ID: cdB34qLToC@terminal.vancouver.example.com 1396 CSeq: 997935769 NOTIFY 1397 Contact: 1398 Content-Length: 0 1400 7. Security Considerations 1402 Note that the mechanisms for obtaining state information for 1403 resources in a list are generally left to the RLS implementor. Some 1404 of the security issues below are specific to the the circumstance 1405 that a SIP back-end subscription is used for such a purpose. Non-SIP 1406 mechanisms for obtaining state information of resources in a list 1407 will typically have their own security issues associated with doing 1408 so; however, exhaustively enumerating such access methods is not 1409 possible in this document. Implementors using such mechanisms must 1410 analyze their chosen access methods for relevant security issues. 1412 7.1 Authentication 1414 If back-end subscriptions are required to retrieve resource state 1415 information, the end user is no longer the direct subscriber to the 1416 state of the resource. This means that direct authentication of the 1417 user is no longer possible. 1419 7.1.1 RLS and Subscriber in the Same Domain 1421 It is expected that the most common deployment of RLSes entails the 1422 subscribers to the RLS being in the same domain as the RLS. When 1423 this is the case, the RLS then has the ability to act as an 1424 authenication service. The role of authentication service is defined 1425 in "Enhancements for Authenticated Identity Management in the Session 1426 Initiation Protocol (SIP)" [7]. 1428 At a high level, under this system, the RLS authenticates the 1429 subscriber, and then includes an "Identity" header field in all of 1430 the back-end subscriptions performed on behalf of that authenticated 1431 user; this "Identity" header field cryptographically asserts that the 1432 request has been authorized to be made on behalf of the user 1433 indicated in the "From" header field. 1435 Because the ability to authenticate requests is central to the proper 1436 functioning of the network, any RLS which uses SIP back-end 1437 subscriptions to acquire information about the resources in a 1438 resource list MUST be able to act as an authentication service as 1439 defined in [7], provided that local administrative policy allows them 1440 to do so. 1442 In other words, all RLS implementations that support back-end SIP 1443 subscriptions also must include the ability to be configured to 1444 act as an authentication service. Whether any given administrator 1445 chooses to activate such a feature is completely up to them. Of 1446 course, lacking the ability to act as an identity server, any RLS 1447 so configured will behave as described in the following section, 1448 since it is effectively acting as if it were in a different domain 1449 than the user. 1451 7.1.2 RLS and Subscriber in Different Domains 1453 In the general case, the SIP Authenticated Identity extensions do not 1454 provide a means for the RLS to securely assert that subscriptions are 1455 being performed on the end user's behalf. Specifically, when the 1456 subscriber and the RLS are in different domains, the RLS will have no 1457 means by which it can vouch for the user's identity. Mechanisms by 1458 which back-end subscriptions in such circumstances can be 1459 authenticated are left for future study. 1461 Until such general solutions are developed, RLSes which are in a 1462 different domain than the subscriber on whose behalf they are 1463 creating back-end susbcriptions SHOULD subscribe to the resources 1464 using their own identity. By doing so, the RLS will generally obtain 1465 only the resource information which is made publicly available. 1467 Absent such general solutions, implemenations of subscriber user 1468 agents MAY attempt direct subscriptions to resources in the resouce 1469 list when subscribing to an RLS outside of their domain (either 1470 directly or by way of another resource list subscription). The 1471 resouces to be subscribed to will be those indicated in the the "uri" 1472 attribute of the elements present in the RLMI document 1473 returned by the RLS. Directly subscribing to the resources allows 1474 proper authentication of the user to take place, which will generally 1475 authorize them to receive more complete state information. 1476 Implementations which choose to perform such direct subscriptions 1477 SHOULD use the data retrieved directly to the exclusion of any 1478 information about the resource obtained via the list subscription. 1480 7.2 Risks of Improper Aggregation 1482 A resource list server typically serves information to multiple 1483 subscribers at once. In many cases, resources may be present in 1484 several lists; additionally, it is quite possible that resource list 1485 servers will have two users subscribe to the same list. 1487 In these cases, misguided RLS implementations may attempt to minimize 1488 network load by maintaining only one back-end subscription to a 1489 resource in a list, and presenting the result of such a subscription 1490 to more than one user. Of course, doing so circumvents any 1491 authorization policy that the notifier for the resource maintains. 1492 It is important to keep in mind that authorization is often much more 1493 than a simple binary "allowed/not allowed" decision; resources may 1494 render very different -- and even conflicting -- resource states, 1495 depending on the identity of the subscribing user. 1497 To prevent the transmission of event information to anyone other than 1498 the intended recipient, implementations MUST NOT present the result 1499 of one back-end subscription to more than one user unless: 1501 a. The RLS has adequate access to the complete authorization policy 1502 associated with the resource to which the back-end subscription 1503 has been made, AND 1505 b. The RLS can and has determined that presenting the information to 1506 more than one user does not violate such policy. 1508 Note that this is a very difficult problem to solve correctly. Even 1509 in the cases that such access is believed possible, this mode of 1510 operation is NOT RECOMMENDED. 1512 7.3 Signing and Sealing 1514 Implementors should keep in mind that any section of the MIME body 1515 may be signed and/or encrypted as necessary. Resource List Servers 1516 should take care not to modify any MIME bodies they receive from any 1517 back-end subscriptions, and should not generally rely on being able 1518 to read them. 1520 In order to facilitate security, resource list servers SHOULD pass 1521 along indication for support of "multipart/signed" and "application/ 1522 pkcs7-mime" content types to any SIP back-end subscriptions, if the 1523 subscriber includes them in the initial SUBSCRIBE message. Not doing 1524 so may actually result in resources refusing to divulge state (if 1525 notifier policy requires encryption, but the RLS fails to convey 1526 support), or subscribers discarding valid state (if subscriber policy 1527 requires a signature, but the RLS fails to convey support). 1529 Note that actual implementation of encryption and signing by the RLS 1530 is not necessary to be able to pass through signed and/or encrypted 1531 bodies. 1533 7.4 Infinite Loops 1535 One risk introduced by the ability to nest resource lists is the 1536 possibility of creating lists which ultimately contain themselves as 1537 a sub-list. Detection and handling of such a case is trivial when 1538 the RLS services all of the virtual subscriptions internally. When 1539 back-end subscriptions are created to service virtual subscriptions, 1540 however, detection of such situations becomes a more difficult 1541 problem. 1543 Implementors of RLSes that create back-end subscriptions MUST 1544 implement safeguards to prevent such nestings from creating an 1545 infinite loop of subscriptions. Typically, such mechanisms will 1546 require support in the back-end subscription protocol. In 1547 particular, applying filters to the back-end subscriptions can be an 1548 effective way to preclude such problems. 1550 8. IANA Considerations 1552 8.1 New SIP Option Tag: eventlist 1554 This section defines a new option tag for the registry established by 1555 section 27.1 of RFC 3261[1]. 1557 Option Tag Name: eventlist 1559 Description: Extension to allow subscriptions to lists of resources 1561 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1562 with the RFC number of this document when published]] 1564 8.2 New MIME type for Resource List Meta-Information 1566 MIME Media Type Name: application 1568 MIME subtype name: rlmi+xml 1570 Required parameters: None 1572 Optional parameters: charset 1574 See RFC 3023 [12] for a discussion of the charset parameter on 1575 XML-derived MIME types. Since this MIME type is used exclusively 1576 in SIP, the use of UTF-8 encoding is strongly encouraged. 1578 Encoding considerations: 8-bit text 1580 Security considerations: Security considerations specific to uses of 1581 this this MIME type are discussed in RFC xxxx [[Note to RFC 1582 editor: replace xxxx with the RFC number of this document when 1583 published]]. RFC 1874 [11] and RFC 3023 [12] discuss security 1584 issues common to all uses of XML. 1586 Interoperability considerations: The use of this MIME body is 1587 intended to be generally interoperable. No unique considerations 1588 have been identified. 1590 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1591 with the RFC number of this document when published]] 1593 Applications which use this media type: This media type is used to 1594 convey meta-information for the state of lists of resources within 1595 a Session Initiation Protocol (SIP) subscription. 1597 Additional information: 1599 Magic Number(s): None. 1601 File Extension(s): None. 1603 Macintosh File Type Code(s): None. 1605 Object Identifier(s) or OID(s): None. 1607 Intended usage: Limited Use 1609 Other Information/General Comment: None. 1611 Person to contact for further information: 1613 Name: Adam Roach 1615 E-Mail: adam@estacado.net 1617 Author/Change Controller: The specification of this MIME type is a 1618 work product of the SIMPLE working group, and was authored by 1619 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1620 change control over its specification. 1622 8.3 URN Sub-Namespace 1624 URI: urn:ietf:params:xml:ns:rlmi 1626 Description: This is the XML namespace URI for XML elements defined 1627 by [RFCXXXX] to describe information about subscriptions when such 1628 subscriptions are aggregated within a single SIP subscription. It 1629 is used in the application/rlmi+xml body type. 1631 Registrant Contact: 1633 Name: Adam Roach 1635 E-Mail: adam@estacado.net 1637 Author/Change Controller: The specification of this MIME type is a 1638 work product of the SIMPLE working group, and was authored by 1639 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1640 change control over its specification. 1642 XML: 1644 BEGIN 1645 1646 1648 1649 1650 1652 Namespace for SIP Event Resource List 1653 Meta-Information 1654 1655 1656

Namespace for SIP Event Resource List 1657 Meta-Information

1658

application/rlmi+xml

1659

See 1660 RFCXXXX.

1661 1662 1663 END 1665 9. Acknowledgements 1667 Thanks to Sean Olson for a review of and corrections to the usage of 1668 XML in this protocol. 1670 Thanks also to Hisham Khartabil, Paul Kyzivat, Keith Drage and Robert 1671 Sparks for their careful reviews of and comments on this document. 1673 Normative References 1675 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1676 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1677 Session Initiation Protocol", RFC 3261, June 2002. 1679 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1680 Notification", RFC 3265, June 2002. 1682 [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 1683 Extensions) Part One: Mechanisms for Specifying and Describing 1684 the Format of Internet Message Bodies", RFC 1521, September 1685 1993. 1687 [4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 1688 2387, August 1998. 1690 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1691 Levels", BCP 14, RFC 2119, March 1997. 1693 [6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1694 1766, March 1995. 1696 [7] Peterson, J., "Enhancements for Authenticated Identity 1697 Management in the Session Initiation Protocol (SIP)", draft- 1698 ietf-sip-identity-03 (work in progress), September 2004. 1700 Informative References 1702 [8] Rosenberg, J., "A Presence Event Package for the Session 1703 Initiation Protocol (SIP)", RFC 3856, August 2004. 1705 [9] Olson, S., "A Mechanism for Content Indirection in Session 1706 Initiation Protocol (SIP) Messages", draft-ietf-sip-content- 1707 indirect-mech-04 (work in progress), July 2004. 1709 [10] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 1710 August 2004. 1712 [11] Levinson, E., "SGML Media Types", RFC 1874, December 1995. 1714 [12] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1715 3023, January 2001. 1717 [13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/ 1718 MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 1720 [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security 1721 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 1722 RFC 1847, October 1995. 1724 [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1726 Authors' Addresses 1728 Adam Roach 1729 Estacado Systems 1731 US 1733 EMail: adam@estacado.net 1735 Ben Campbell 1736 Estacado Systems 1738 US 1740 EMail: ben@estacado.net 1741 Jonathan Rosenberg 1742 Cisco Systems 1743 600 Lanidex Plaza 1744 Parsippany, NJ 07054-2711 1745 US 1747 EMail: jdrosen@cisco.com 1749 Appendix A. Changes 1751 Note that this section will be removed before publication as an RFC. 1753 A.1 Changes since -06 1755 o Substantial reworking of section on authentication; now requires 1756 SIP Identity extension for RLSes that use SIP back-end 1757 subscriptions. Examples updated to reflect this change. 1759 o Fixed CPIM mime type everywhere. 1761 A.2 Changes since -05 1763 o Added open issue regarding transfer of user secrets to the RLS. 1765 o Removed all references to multipart/encrypted. Replaced with 1766 application/pkcs7-mime, to align with RFC 3261 and RFC 3851. 1768 o Formally restricted state attribute in schema to reflect the three 1769 valid values outlined in the text 1771 o Changed "name" from an attribute to an element for both and 1772 elements. This allows for multiple names to be 1773 present, each with an appropriate language tag. 1775 o Minor editorial updates. 1777 A.3 Changes since -04 1779 o Removed references to P-Asserted-Identity mechanism. 1781 o Removed some leftover cruft from the section on constructing 1782 coherent resource state. 1784 A.4 Changes since -03 1786 o Changed Content-Encoding in examples from 8bit to binary. 1788 o Adjusted formatting to comply with RFC 2223. 1790 A.5 Changes since -02 1792 o Added discussion in security section about infinite loops. 1794 o Fixed several places where the document said "one or more" instead 1795 of "zero or more", when referring to the number of resources that 1796 can appear in a list and the number of instances that can appear 1797 in a resource. 1799 o Tiny editorial cleanup (mostly spelling gaffes). 1801 A.6 Changes since -01 1803 o Several editorial updates. Change "collection" to "list" 1804 everywhere. 1806 o Added terminology section. 1808 o Added restriction that cid attributes can only point to documents 1809 at the same level as the RLMI document in which they appear. 1811 o Clarified description of how to construct resource state by 1812 splitting discussion of full state notifications apart from 1813 discussion of partial-state notifications. 1815 A.7 Changes since -00 1817 o Removed text in several places which went into detail about 1818 specific implementations which used SIP SUB/NOT for back-end 1819 subscriptions. Some of this text will probably be published later 1820 as part of an implementors' guide. 1822 o Removed specific semantics for "Event" header field parameters and 1823 SUBSCRIBE bodies. These will be defined on a per-package basis, 1824 probably by the filtering work. 1826 o Added "cid" attribute to elements. 1828 o Reworked XML schema definition for meta-information. 1830 o Added IANA registration for XML namespace. 1832 o Minor editorial fixes 1834 Appendix B. Intellectual Property Statement 1836 The IETF takes no position regarding the validity or scope of any 1837 intellectual property or other rights that might be claimed to 1838 pertain to the implementation or use of the technology described in 1839 this document or the extent to which any license under such rights 1840 might or might not be available; neither does it represent that it 1841 has made any effort to identify any such rights. 1843 Information on the IETF's procedures with respect to rights in 1844 standards-track and standards-related documentation can be found in 1845 BCP-11. Copies of claims of rights made available for publication 1846 and any assurances of licenses to be made available, or the result of 1847 an attempt made to obtain a general license or permission for the use 1848 of such proprietary rights by implementors or users of this 1849 specification can be obtained from the IETF Secretariat. 1851 The IETF invites any interested party to bring to its attention any 1852 copyrights, patents or patent applications, or other proprietary 1853 rights which may cover technology that may be required to practice 1854 this standard. Please address the information to the IETF Executive 1855 Director. 1857 Full Copyright Statement 1859 Copyright (C) The Internet Society (2004). This document is subject 1860 to the rights, licenses and restrictions contained in BCP 78, and 1861 except as set forth therein, the authors retain all their rights. 1863 This document and the information contained herein are provided on an 1864 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1865 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1866 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1867 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1868 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1869 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1871 Acknowledgement 1873 Funding for the RFC Editor function is currently provided by the 1874 Internet Society.