idnits 2.17.1 draft-ietf-simple-event-list-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 739 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 (May 16, 2003) is 7650 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 1436 == Unused Reference: '3' is defined on line 1489, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1514, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1530, 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) == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-01 == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-02 == Outdated reference: A later version (-04) exists of draft-ietf-impp-pres-02 -- Obsolete informational reference (is this intentional?): RFC 3023 (ref. '12') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '13') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '15') (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 6 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 J. Rosenberg 4 Expires: November 14, 2003 B. Campbell 5 dynamicsoft 6 May 16, 2003 8 A Session Initiation Protocol (SIP) Event Notification Extension for 9 Resource Lists 10 draft-ietf-simple-event-list-03 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 14, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document presents an extension to the Session Initiation 42 Protocol (SIP)-Specific Event Notification mechanism for subscribing 43 to a homogeneous list of resources. Instead of the subscriber 44 sending a SUBSCRIBE for each resource individually, the subscriber 45 can subscribe to an entire list, and then receive notifications when 46 the state of any of the resources in the list changes. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 53 4. Operation of List Subscriptions . . . . . . . . . . . . . . 6 54 4.1 Negotiation of Support for Resource Lists . . . . . . . . . 6 55 4.2 Subscription Duration . . . . . . . . . . . . . . . . . . . 7 56 4.3 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 7 57 4.4 RLS Processing of SUBSCRIBE Requests . . . . . . . . . . . . 7 58 4.5 RLS Generation of NOTIFY requests . . . . . . . . . . . . . 8 59 4.6 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 9 60 4.7 Handling of Forked Requests . . . . . . . . . . . . . . . . 10 61 4.8 Rate of Notifications . . . . . . . . . . . . . . . . . . . 10 62 5. Using multipart/related to Convey Aggregate State . . . . . 11 63 5.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 12 65 5.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 13 66 5.4 Instance Attributes . . . . . . . . . . . . . . . . . . . . 13 67 5.5 Constructing Coherent Resource State . . . . . . . . . . . . 15 68 5.5.1 Processing Full State Notifications . . . . . . . . . . . . 16 69 5.5.2 Processing Partial State Notifications . . . . . . . . . . . 16 70 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 72 7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 30 73 7.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 30 74 7.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 31 75 7.4 Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . 31 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 77 8.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 32 78 8.2 New MIME type for Resource List Meta-Information . . . . . . 32 79 8.3 URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . . 33 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 81 Normative References . . . . . . . . . . . . . . . . . . . . 36 82 Non-Normative References . . . . . . . . . . . . . . . . . . 37 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 84 A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 39 85 A.1 Changes since -02 . . . . . . . . . . . . . . . . . . . . . 39 86 A.2 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 39 87 A.3 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 39 88 B. Intellectual Property Statement . . . . . . . . . . . . . . 41 89 Full Copyright Statement . . . . . . . . . . . . . . . . . . 42 91 1. Introduction 93 The SIP-specific event notification mechanism [2] allows a user (the 94 subscriber) to request to be notified of changes in the state of a 95 particular resource. This is accomplished by having the subscriber 96 generate a SUBSCRIBE request for the resource, which is processed by 97 a notifier that represents the resource. 99 In many cases, a subscriber has a list of resources they are 100 interested in. Without some aggregating mechanism, this will require 101 the subscriber generate a SUBSCRIBE request for each resource about 102 which they want information. For environments in which bandwidth is 103 limited, such as wireless networks, subscribing to each resource 104 individually is problematic. Some specific problems are: 106 o Doing so generates substantial message traffic, in the form of the 107 initial SUBSCRIBE requests for each resource, and the refreshes of 108 each individual subscription. 110 o The notifier may insist on low refresh intervals, in order to 111 avoid long lived subscription state. This means that the 112 subscriber may need to generate SUBSCRIBE refreshes faster than it 113 would like to, or has the capacity to. 115 o The notifier may generate NOTIFY requests more rapidly than the 116 subscriber desires, causing NOTIFY traffic at a greater volume 117 than is desired by the subscriber. 119 To solve these problems, this specification defines an extension to 120 RFC 3265 [2] that allows for requesting and conveying notifications 121 for lists of resources. A resource list is identified by a URI and 122 it represents a list of zero or more URIs. Each of these URIs is an 123 identifier for an individual resource for which the subscriber wants 124 to receive information. In many cases, the URI will be a SIP URI 125 [1]; however, the use of other schemes (such as pres: [10]) is also 126 foreseen. 128 The notifier for the list is called a "resource list server", or RLS. 129 In order to determine the state of the entire list, the RLS will act 130 as if it has generated a subscription to each resource in the list. 132 The resource list is not restricted to be inside the domain of the 133 subscriber. Similarly, the resources in the list are not constrained 134 to be in the domain of the resource list server. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [5]. 142 The following terms are used throughout the remainder of this 143 document. 145 Back-End Subscription: Any subscription (SIP or otherwise) that an 146 RLS creates to learn of the state of a resource. An RLS will 147 create back-end subscriptions to learn of the state of a resource 148 about which the RLS is not an authority. For back-end 149 subscriptions, RLSes act as a subscriber. 151 List Subscription: A subscription to a resource list. In list 152 subscriptions, RLSes act a the notifier. 154 Resource: A resource is any logical entity that has a state or states 155 that can be subscribed to. Resources are identified by URIs. 157 Resource List: A list of zero or more resources that can have their 158 individual states subscribed to with a single subscription. 160 RLMI: Resource List Meta-Information. RLMI is a document that 161 describes the state of the virtual subscriptions associated with a 162 list subscription. 164 RLS: Resource List Server. RLSes accept subscriptions to resource 165 lists and send notifications to update subscribers of the state of 166 the resources in a resource list. 168 Virtual Subscription: Virtual Subscriptions are a logical construct 169 within an RLS that represent subscriptions to the resources in a 170 resource list. For each list subscription it services, an RLS 171 creates at least one virtual subscription for every resource in 172 the resource list being subscribed to. In some cases, such as 173 when the RLS is not the authority for the state of the resource, 174 this virtual subscription will be associated with a back-end 175 subscription. In other cases, such as when the RLS is the 176 authority for the state of the resource, the virtual subscription 177 will not have a corresponding back-end subscription. 179 3. Overview of Operation 181 This section provides an overview of the typical mode of operation of 182 this extension. It is not normative. 184 When users wish to subscribe to the resource of a list of resources, 185 they can use the mechanisms described in this specification. The 186 first step is creation of a resource list. This resource list is 187 represented by a SIP URI. The list contains a set of URIs, each of 188 which represents a resource for which the subscriber wants to receive 189 information. The resource list can exist in any domain. The list 190 could be manipulated through a web page, through a voice response 191 system, or through some other protocol. The specific means by which 192 the list is created and maintained is outside of the scope of this 193 specification. 195 To learn the resource state of the set of elements on the list, the 196 user sends a single SUBSCRIBE request targeted to the URI of the 197 list. This will be routed to an RLS for that URI. The RLS acts as a 198 notifier, authenticates the subscriber, and accepts the subscription. 200 The RLS may have direct information about some or all of the 201 resources specified by the list. If it does not, it could subscribe 202 to any non-local resources specified by the list resource. 204 Note that subscriptions to non-local resources may or may not be SIP 205 subscriptions; any mechanism for determining such information may be 206 employed. This document uses the term "back-end subscription" to 207 refer to such a subscription, regardless of whether SIP is used to 208 establish and service it. 210 As the state of resources in the list change, the RLS generates 211 notifications to the list subscribers. The RLS can, at its 212 discretion, buffer notifications of resource changes, and send the 213 resource information to the subscriber in batches, rather than 214 individually. This allows the RLS to provide rate limiting for the 215 subscriber. 217 The list notifications contain a body of type multipart/related. The 218 root section of the multipart/related content is an XML document that 219 provides meta-information about each resource present in the list. 220 The remaining sections contain the actual state information for each 221 resource. 223 4. Operation of List Subscriptions 225 The event list extension acts, in many ways, like an event template 226 package. In particular, any single list subscription must be 227 homogeneous with respect to the underlying event package. In other 228 words, a single list subscription can apply only one event package to 229 all of the resources in the resource list. 231 It is worth noting that it is perfectly valid, for an RLS to allow 232 multiple subscriptions to the same list to use differing event 233 packages. 235 The key difference between a list subscription and templates in 236 general is that support for list subscriptions indicates support for 237 arbitrary nesting of list subscriptions. In other words, elements 238 within the list may be atomic elements, or they may be lists 239 themselves. 241 The consequence of this is that subscription to a URI that represents 242 a list actually results in a several virtual subscriptions to a tree 243 of resources. The leaf nodes of this tree are virtual subscriptions 244 of the event type given in the "Event" header field; all other nodes 245 in the tree are list subscriptions that are serviced as described in 246 this section and its subsections. 248 It is important to keep in mind that these virtual subscriptions are 249 not literal SIP subscriptions (although they may result in SIP 250 subscriptions, depending on the RLS implementation). 252 4.1 Negotiation of Support for Resource Lists 254 This specification uses the SIP option tag mechanism for negotiating 255 support for the extension defined herein. Refer to RFC3261 [1] for 256 the normative description of processing of the "Supported" and 257 "Require" header fields and the 421 (Extension Required) response 258 code. 260 A non-normative description of the implications of the use of 261 option tags follows. 263 Any client that supports the event list extension will include an 264 option tag of "eventlist" in a "Supported" header field of every 265 SUBSCRIBE message for a subscription for which it is willing to 266 process a list. If the subscription is made to a URI that 267 represents a list, the RLS will include "eventlist" in a "Require" 268 header field of the response to the SUBSCRIBE, and in all NOTIFY 269 messages within that subscription. 271 Use of "Require: eventlist" in NOTIFY messages is applied by the 272 notifier to satisfy the RFC3261 requirement that a UAC MUST insert 273 a Require header field into a request if the UAC wishes to insist 274 that a UAS understand an extension in order to process the 275 request. Because the NOTIFY would not be usable without applying 276 the eventlist option, the notifier is obligated to include it. 278 Including "eventlist" in a "Require" header field in a SUBSCRIBE 279 request serves no purpose, and is consequently NOT RECOMMENDED. 281 There is nothing in a SIP URI which indicates whether it represents a 282 list of resources or a single resource. Therefore, if a subscriber 283 sends a request to a URI that represents a list resource, but does 284 not include a Supported header field listing the "eventlist" token, 285 the notifier will typically return a 421 (Extension Required) 286 response code. RFC 3261 [1] advises servers to avoid returning a 287 421, and instead, attempt to process the request without the 288 extension. However, in this case, the URI fundamentally represents a 289 list resource, and therefore, the subscription cannot proceed without 290 this extension. 292 4.2 Subscription Duration 294 Since the primary benefit of the resource list server is to reduce 295 the overall messaging volume to a subscriber, it is RECOMMENDED that 296 the subscription duration to a list be reasonably long. The default, 297 when no duration is specified, is taken from the underlying event 298 package. Of course, the standard techniques [2] can be used to 299 increase or reduce this amount. 301 4.3 NOTIFY Bodies 303 An implementation compliant to this specification MUST support the 304 multipart/related and application/rlmi+xml MIME types. These types 305 MUST be included in an Accept header sent in SUBSCRIBE message, in 306 addition to any other types supported by the client (including any 307 types required by the event package being used). 309 4.4 RLS Processing of SUBSCRIBE Requests 311 Once the subscriber is authenticated, the RLS performs authorization 312 per its local policy. In many cases, each resource list is 313 associated with a particular user (the one who created it and manages 314 the set of elements in it), and only that user will be allowed to 315 subscribe. Of course, this mode of operation is not inherent in the 316 use of resource lists, and an RLS can use any authorization policy it 317 chooses. 319 4.5 RLS Generation of NOTIFY requests 321 This specification leaves the choice about how and when to generate 322 NOTIFY requests at the discretion of the implementor. One of the 323 value propositions of the RLS is the means by which it aggregates, 324 rate limits, or optimizes the way in which notifications are 325 generated. As a baseline behavior, the RLS MAY generate a NOTIFY to 326 the RLS subscriber whenever the state of any resource on the list 327 changes. 329 See Section 5 for a detailed definition of the syntax used to convey 330 the state of resource lists. For the purposes of the following 331 discussion, it is important to know that the overall list contains 332 zero or more resources, and that the resources contains zero or more 333 instances. Each instance has a state associated with it (pending, 334 active, or terminating), representing the state of the virtual 335 subscription. 337 Notifications contain a multipart document, the first part of which 338 always contains meta-information about the list (e.g. membership, 339 state of the virtual subscription to the resource). Remaining parts 340 are used to convey the actual state of the resources listed in the 341 meta-information. 343 The "state" attribute of each instance of a resource in the meta- 344 information is set according to the state of the virtual 345 subscription. The meanings of the "state" attribute are described in 346 RFC 3265 [2]. 348 If an instance of a resource was previously reported to the 349 subscriber but is no longer available (i.e. the virtual subscription 350 to that instance has been terminated), the resource list server 351 SHOULD include that resource instance in the meta-information in the 352 first NOTIFY message sent to the subscriber following the instance's 353 unavailability. The RLS MAY continue to do so for future 354 notifications. 356 When sending information for a terminated resource instance, the RLS 357 indicates a state of "terminated" and an appropriate reason value. 358 Valid reason values and their meanings are described in RFC 3265 [2]. 359 If the RLS will attempt to recover the resource state again at some 360 point in the future (e.g. when the reason in the meta-information is 361 "probation"), then the instance of the resource SHOULD remain in the 362 meta-information until the instance state is available, or until the 363 RLS gives up on making such state available. 365 When the first SUBSCRIBE message for a particular subscription is 366 received by a RLS, the RLS will often not know state information for 367 all of the resources specified by the resource list. For any 368 resource for which state information is not known, the corresponding 369 "uri" attribute will be set appropriately, and no elements 370 will be present for the resource. 372 For an initial notification, sections corresponding to resources for 373 which the RLS does have state will be populated with appropriate data 374 (subject, of course, to local policy decisions). This will often 375 occur if the resource list server is co-located with the server for 376 one or more of the resources specified on the list. 378 Immediate notifications triggered as a result of subsequent SUBSCRIBE 379 messages SHOULD include an RLMI document with full state indicated. 380 The RLS SHOULD also include state information for all resources in 381 the list for which the RLS has state, subject to policy restrictions. 382 This allows the subscriber to refresh their state, and to recover 383 from lost notifications. 385 4.6 Subscriber Processing of NOTIFY Requests 387 Notifications for a resource list can convey information about a 388 subset of the list elements. This means that an explicit algorithm 389 needs to be defined in order to construct coherent and consistent 390 state. 392 The XML document present in the root of the multipart/related 393 document contains a element for some or all of the 394 resources in the list. Each element contains a URI which 395 uniquely identifies the resource to which that section corresponds. 396 When a NOTIFY arrives, it can contain full or partial state (as 397 indicate by the "fullState" attribute of the top-level 398 element). If full state is indicated, then the recipient replaces 399 all state associated with the list with the entities in the NOTIFY 400 body. If full state is not indicated, the recipient of the NOTIFY 401 updates information for each identified resource. Information for 402 any resources that are not identified in the NOTIFY are not changed, 403 even if they were indicated in previous NOTIFY messages. See Section 404 5.5 for more information. 406 When full state is indicated, note that it applies only to the 407 RLMI document in which it occurs. In particular, one of the 408 elements in the document may in turn refer to another 409 list of resources. Any such sub-lists will be detailed in their 410 own RLMI documents, which may or may not have full state 411 indicated. 413 Further note that underlying event package may have its own rules 414 for compositing partial state notification. When processing data 415 related to those packages, their rules apply (i.e. the fact that 416 they were reported as part of a list does not change their partial 417 notification semantics). 419 Finally, note that a consequence of the way in which resource list 420 subscriptions work is that polling of resource state may not be 421 particularly useful. While such polls will retrieve the resource 422 list, they will not necessarily contain state for some or all of 423 the resources on the list. 425 4.7 Handling of Forked Requests 427 Forking makes little sense with subscriptions to event lists, since 428 the whole idea is a centralization of the source of notifications. 429 Therefore, a subscriber to a list MUST NOT install multiple 430 subscriptions when the initial request is forked. If multiple 431 responses are received, they are handled using the techniques 432 described in section 4.4.9 of RFC 3265[2]. 434 4.8 Rate of Notifications 436 One potential role of the RLS is to perform rate limitations on 437 behalf of the subscriber. As such, this specification does not 438 mandate any particular rate limitation, and rather leaves that to the 439 discretion of the implementation. 441 5. Using multipart/related to Convey Aggregate State 443 In order to convey the state of multiple resources, the list 444 extension uses the "multipart/related" mime type. The syntax for 445 multipart/related is defined in "The MIME Multipart/Related Content- 446 type" [4]. 448 5.1 XML Syntax 450 The root document of the multipart/related body MUST be a Resource 451 List Meta-Information (RLMI) document. It is of type "application/ 452 rlmi+xml". This document contains the meta-information for the 453 resources contained in the notification. The schema for this XML 454 document is given below. 456 457 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 489 490 491 492 493 494 495 496 497 499 An example of a document formatted using this schema follows. 501 502 505 506 507 508 509 510 511 512 513 514 515 516 517 519 5.2 List Attributes 521 The element present in a list notification MUST contain three 522 attributes. 524 The first mandatory attribute is "uri", which contains the uri 525 that corresponds to the list. Typically, this is the URI to which 526 the SUBSCRIBE request was sent. 528 The second mandatory attribute is "version", which contains a 529 number from 0 to 2^32-1. This version number MUST be 0 for the first 530 NOTIFY message sent within a subscription, and MUST increase by 531 exactly one for each subsequent NOTIFY sent within a subscription. 533 The third mandatory attribute is "fullState". The "fullState" 534 attribute indicates whether the NOTIFY message contains information 535 for every resource in the list. If it does, the value of the 536 attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The 537 first NOTIFY sent in a subscription MUST contain full state, as must 538 the first NOTIFY sent after receipt of a SUBSCRIBE request for the 539 subscription. 541 The optional "name" attribute contains a human readable description 542 or name for the resource list. This attribute is somewhat analogous 543 to the "Display Name" present in the SIP name-addr element. 545 Finally, elements MAY contain a "cid" attribute. If present, 546 the "cid" attribute identifies a section within the multipart/related 547 body that contains aggregate state information for the resources 548 contained in the list. The definition of such aggregate information 549 is outside the scope of this document, and will be defined on a per- 550 package basis as needed. The cid attribute is the Content-ID for the 551 corresponding section in the multipart body. 553 The cid attribute MUST refer only to top-level parts of the 554 multipart/related document for which the RLMI document in which it 555 appears is the root. See Section 5.4 for an example. 557 5.3 Resource Attributes 559 The resource list contains one element for each resource 560 being reported in the notification. These resource elements contain 561 attributes that identify meta-data associated with each resource. 563 The "uri" attribute identifies the resource to which the 564 element corresponds. Typically, this will be a SIP URI which, if 565 subscribed to, would return the state of the resource. This 566 attribute MUST be present. 568 The optional "name" attribute can contain a human readable 569 description or name for the resource. This attribute is somewhat 570 analogous to the "Display Name" present in the SIP name-addr element. 572 5.4 Instance Attributes 574 Each resource element contains zero or more instance elements. These 575 instance elements are used to represent a single notifier for the 576 resource. For event packages that allow forking, multiple virtual 577 subscriptions may exist for a given resource. Multiple virtual 578 subscriptions are represented as multiple instance elements in the 579 corresponding resource element. For subscriptions in which forking 580 does not occur, at most one instance will be present for a given 581 resource. 583 The "id" attribute contains an opaque string used to uniquely 584 identify the instance of the resource. The "id" attribute is unique 585 only within the context of a resource. Construction of this string 586 is an implementation decision. Any mechanism for generating this 587 string is valid, as long as uniqueness within the resource is 588 assured. 590 The "state" attribute contains the subscription state for the 591 identified instance of the resource. This attribute contains one of 592 the values "active", "pending", or "terminated". The meanings for 593 these values are as defined for the "Subscription-State" header field 594 in RFC 3265 [2]. 596 If the "state" attribute indicates "terminated", then a "reason" 597 attribute MUST also be present. This "reason" attribute has the same 598 values and meanings as given for the "reason" parameter on the 599 "Subscription-State" header field in RFC 3265 [2]. Note that the 600 "reason" attribute is included for informational purposes; the list 601 subscriber is not expected to take any automated actions based on the 602 reason value. 604 Finally, the "cid" attribute, which MUST be present if the "state" 605 attribute is "active", identifies the section within the multipart/ 606 related body that contains the actual resource state. This state is 607 expressed in the content type defined by the event package for 608 conveying state. The cid attribute is the Content-ID for the 609 corresponding section in the multipart body. 611 The cid attribute MUST refer only to top-level parts of the 612 multipart/related document for which the RLMI document in which it 613 appears is the root. 615 For example, consider a multipart/related document containing 616 three parts; we'll label these parts A, B, and C. Part A is type 617 application/rlmi+xml, part B is type multipart/related, and part C 618 is type application/cpim-pidf+xml. Part B is in turn a document 619 containing three parts: D, E, and F. Part D is of type 620 application/rlmi+xml, and parts E and F are of type application/ 621 cpim-pidf+xml. 623 +-------------------------------------------+ 624 | Top Level Document: multipart/related | 625 | | 626 | +---------------------------------------+ | 627 | | Part A: application/rlmi+xml | | 628 | +---------------------------------------+ | 629 | | Part B: multipart/related | | 630 | | | | 631 | | +-----------------------------------+ | | 632 | | | Part D: application/rlmi+xml | | | 633 | | +-----------------------------------+ | | 634 | | | Part E: application/cpim-pidf+xml | | | 635 | | +-----------------------------------+ | | 636 | | | Part F: application/cpim-pidf+xml | | | 637 | | +-----------------------------------+ | | 638 | | | | 639 | +---------------------------------------+ | 640 | | Part C: application/cpim-pidf+xml | | 641 | +---------------------------------------+ | 642 | | 643 +-------------------------------------------+ 645 Any "cid" attributes in document A must refer only to parts B or 646 C. Referring to parts D, E, or F would be illegal. Similarly, 647 Any "cid" attributes in document D must refer only to parts E or 648 F. Referring to any other parts would be illegal. 650 Also note that the subscription durations of any back-end 651 subscriptions are not propagated into the meta-information state 652 in any way. 654 5.5 Constructing Coherent Resource State 656 The resource list subscriber maintains a table for each resource 657 list. The table contains a row for each resource in the resource 658 list. Each row is indexed by the URI for that resource. That URI is 659 obtained from the "uri" attribute on each element. The 660 contents of each row contain the state of that resource as conveyed 661 in the resource document. 663 For resources that provide versioning information (which is mandated 664 by [2] for any formats that allow partial notification), each row 665 also contains a resource state version number. The version number of 666 the row is initialized with the version specified in the first 667 document received, as defined by the corresponding event package. 668 This value is used when comparing versions of partial notifications 669 for a resource. 671 The processing of the resource list notification depends on whether 672 it contains full or partial state. 674 5.5.1 Processing Full State Notifications 676 If a notification contains full state, indicated by the value of the 677 attribute "fullState", the notification is used to update the 678 table. A check is first made to ensure that the "version" attribute 679 of the attribute in the received message is greater than the 680 local version number. If not, the received document is discarded 681 without any further processing. Otherwise, the contents of the 682 resource-list table are flushed, and repopulated from the contents of 683 the document. A new row in the table is created for each "resource" 684 element. 686 5.5.2 Processing Partial State Notifications 688 If a notification contains partial state, indicated by the value of 689 the attribute "fullState", a check is made to ensure that no 690 list notifications have been lost. The value of the local version 691 number (the "version" attribute of the element) is compared to 692 the version number of the new document. 694 o If the value in the new document is exactly one higher than the 695 local version number, the local version number is increased by 696 one, and the document is processed, as described below. 698 o If the version in the document is more than one higher than the 699 local version number, the local version number is set to the value 700 in the new document, and the document is processed as described 701 below. Further, if the notification does not contain full state 702 (as indicated by the "fullState" attribute of the element), 703 the list subscriber SHOULD generate a refresh request to trigger a 704 full state notification. 706 o If the version in the document is less than or equal to the local 707 version, the document is discarded without any further processing. 709 For each resource listed in the document, the subscriber checks to 710 see whether a row exists for that resource. This check is done by 711 comparing the Resource-URI value with the URI associated with the 712 row. If the resource doesn't exist in the table, a row is added, and 713 its state is set to the information from that "resource" element. If 714 the resource does exist, its state is updated to be the information 715 from that "resource" element, as described in the definition of the 716 event package. If a row is updated or created such that its state is 717 now "terminated," that entry MAY be removed from the table at any 718 time. 720 6. Example 722 This section gives an example call flow. It is not normative. If a 723 conflict arises between this call flow and the normative behavior 724 described in this or any other document, the normative descriptions 725 are to be followed. 727 In this particular example, we request a subscription to a nested 728 presence list. The subscriber's address-of-record is 729 "sip:adam@example.com", and the name of the nested list resource that 730 we are subscribing to is called "sip:adam-buddies@pres.example.com". 731 The underlying event package is "presence", described by [6]. 733 In this example, the RLS has information to service some of the 734 resources on the list, but must consult other servers to retrieve 735 information for others. The implementation of the RLS in this 736 example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such 737 information. 739 Terminal pres.example.com pres.example.org 740 | | pres.example.net | 741 1 |---SUBSCRIBE--->| | | 742 2 |<-----200-------| | | 743 3 |<----NOTIFY-----| | | 744 4 |------200------>| | | 745 5 | |---SUBSCRIBE--->| | 746 6 | |<-----200-------| | 747 7 | |<----NOTIFY-----| | 748 8 | |------200------>| | 749 9 | |------------SUBSCRIBE----------->| 750 10| |<--------------200---------------| 751 11| |<-------------NOTIFY-------------| 752 12| |---------------200-------------->| 753 13|<----NOTIFY-----| | | 754 14|------200------>| | | 756 1. We initiate the subscription by sending a SUBSCRIBE message to 757 our local RLS. (There is no reason that the RLS we contact has 758 to be in our domain, of course). Note that we must advertise 759 support for application/rlmi+xml and multipart/related because 760 we support the eventlist extension, and we must advertise 761 application/cpim-pidf+xml because we are requesting a 762 subscription to presence. 764 Terminal -> Local RLS 766 SUBSCRIBE sip:adam-buddies@pres.example.com SIP/2.0 767 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 768 Max-Forwards: 70 769 To: 770 From: ;tag=ie4hbb8t 771 Call-ID: cdB34qLToC@terminal.example.com 772 CSeq: 322723822 SUBSCRIBE 773 Contact: 774 Event: presence 775 Expires: 7200 776 Supported: eventlist 777 Accept: application/cpim-pidf+xml 778 Accept: application/rlmi+xml 779 Accept: multipart/related 780 Accept: multipart/signed 781 Accept: multipart/encrypted 782 Content-Length: 0 784 2. The Local RLS completes the SUBSCRIBE transaction. Note that 785 authentication and authorization would normally take place at 786 this point in the call flow. Those steps are omitted for 787 brevity. 789 Local RLS -> Terminal 791 SIP/2.0 200 OK 792 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 793 To: ;tag=zpNctbZq 794 From: ;tag=ie4hbb8t 795 Call-ID: cdB34qLToC@terminal.example.com 796 CSeq: 322723822 SUBSCRIBE 797 Contact: 798 Expires: 7200 799 Require: eventlist 800 Content-Length: 0 802 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY 803 immediately upon accepting the subscription. In this example, 804 we are assuming that the local RLS is also an authority for 805 presence information for the users in the "example.com" domain. 806 The NOTIFY contains an RLMI document describing the entire buddy 807 list (initial notifies require full state), as well as presence 808 information for the users about which it already knows. Note 809 that, since the RLS has not yet retrieved information for some 810 of the entries on the list, those elements contain no 811 elements. 813 Local RLS -> Terminal 815 NOTIFY sip:terminal.example.com SIP/2.0 816 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 817 Max-Forwards: 70 818 From: ;tag=zpNctbZq 819 To: ;tag=ie4hbb8t 820 Call-ID: cdB34qLToC@terminal.example.com 821 CSeq: 997935768 NOTIFY 822 Contact: 823 Event: presence 824 Subscription-State: active;expires=7200 825 Require: eventlist 826 Content-Type: multipart/related;type="application/rlmi+xml"; 827 start="";boundary="50UBfW7LSCVLtggUPe5z" 828 Content-Length: 1560 830 --50UBfW7LSCVLtggUPe5z 831 Content-Transfer-Encoding: 8bit 832 Content-ID: 833 Content-Type: application/rlmi+xml;charset="UTF-8" 835 836 839 840 841 842 843 844 845 846 847 849 --50UBfW7LSCVLtggUPe5z 850 Content-Transfer-Encoding: 8bit 851 Content-ID: 852 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 854 855 857 858 859 open 860 861 sip:bob@example.com 862 863 865 --50UBfW7LSCVLtggUPe5z 866 Content-Transfer-Encoding: 8bit 867 Content-ID: 868 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 870 871 873 874 875 closed 876 877 878 880 --50UBfW7LSCVLtggUPe5z-- 882 4. The terminal completes the transaction. 884 Terminal -> Local RLS 886 SIP/2.0 200 OK 887 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 888 From: ;tag=zpNctbZq 889 To: ;tag=ie4hbb8t 890 Call-ID: cdB34qLToC@terminal.example.com 891 CSeq: 997935768 NOTIFY 892 Contact: 893 Content-Length: 0 895 5. In order to service the subscription, the local RLS subscribes 896 to the state of the resources. In this step, the RLS attempts 897 to subscribe to the presence state of the resource 898 "sip:ed@example.net". Since the local RLS knows how to receive 899 notifications for list subscriptions, it includes the 900 "Supported: eventlist" header field in its request. Although 901 the linkage between this subscription and the one sent by the 902 terminal is left up to the application, this message 903 demonstrates some reasonable behavior by including "Accept" 904 header fields for all of the body types it knows the subscriber 905 (Terminal) supports. This is safe to do, since the local RLS 906 will only pass these formats through to the subscriber, and does 907 not need to actually understand them. 909 Local RLS -> Presence Server in example.net 911 SUBSCRIBE sip:ed@example.net SIP/2.0 912 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 913 Max-Forwards: 70 914 To: 915 From: ;tag=aM5icQu9 916 Call-ID: Ugwz5ARxNw@pres.example.com 917 CSeq: 870936068 SUBSCRIBE 918 Contact: 919 Event: presence 920 Expires: 3600 921 Supported: eventlist 922 Accept: application/cpim-pidf+xml 923 Accept: application/rlmi+xml 924 Accept: multipart/related 925 Accept: multipart/signed 926 Accept: multipart/encrypted 927 Content-Length: 0 929 6. The Presence Server in example.net completes the SUBSCRIBE 930 transaction. Note that authentication would normally take place 931 at this point in the call flow. Those steps are omitted for 932 brevity. 934 Presence Server in example.net -> Local RLS 936 SIP/2.0 200 OK 937 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 938 To: ;tag=e45TmHTh 939 From: ;tag=aM5icQu9 940 Call-ID: Ugwz5ARxNw@pres.example.com 941 CSeq: 870936068 SUBSCRIBE 942 Contact: 943 Expires: 3600 944 Content-Length: 0 946 7. In this example, we assume that the server at example.net 947 doesn't have enough authorization information to reject or 948 accept our subscription. The initial notify, therefore, 949 contains a "Subscription-State" of "pending". Presumably, the 950 party responsible for accepting or denying authorization for the 951 resource is notified of this change; however, those steps are 952 not included in this call flow for brevity. 954 Presence Server in example.net -> Local RLS 956 NOTIFY sip:pres.example.com SIP/2.0 957 Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW 958 Max-Forwards: 70 959 From: ;tag=e45TmHTh 960 To: ;tag=aM5icQu9 961 Call-ID: Ugwz5ARxNw@pres.example.com 962 CSeq: 1002640632 NOTIFY 963 Contact: 964 Subscription-State: pending;expires=3600 965 Event: presence 966 Require: eventlist 967 Content-Length: 0 969 8. The local RLS completes the NOTIFY transaction. Note that, at 970 this point, the Local RLS has new information to report to the 971 subscriber. Whether it chooses to report the information 972 immediately or spool it up for later delivery is completely up 973 to the application. For this example, we assume that the RLS 974 will wait for a short period of time before doing so, in order 975 to allow the subscriptions it sent out sufficient time to 976 provide useful data. 978 Local RLS -> Presence Server in example.net 980 SIP/2.0 200 OK 981 Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW 982 From: ;tag=e45TmHTh 983 To: ;tag=aM5icQu9 984 Call-ID: Ugwz5ARxNw@pres.example.com 985 CSeq: 1002640632 NOTIFY 986 Contact: 987 Content-Length: 0 989 9. The Local RLS subscribes to the state of the other non-local 990 resource. 992 Local RLS -> RLS in example.org 994 SUBSCRIBE sip:adam-friends@example.org SIP/2.0 995 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 996 Max-Forwards: 70 997 To: 998 From: ;tag=a12eztNf 999 Call-ID: kBq5XhtZLN@pres.example.com 1000 CSeq: 980774491 SUBSCRIBE 1001 Contact: 1002 Event: presence 1003 Expires: 3600 1004 Supported: eventlist 1005 Accept: application/cpim-pidf+xml 1006 Accept: application/rlmi+xml 1007 Accept: multipart/related 1008 Accept: multipart/signed 1009 Accept: multipart/encrypted 1010 Content-Length: 0 1012 10. The RLS in example.org completes the SUBSCRIBE transaction. 1013 Note that authentication and would normally take place at this 1014 point in the call flow. Those steps are omitted for brevity. 1016 RLS in example.org -> Local RLS 1018 SIP/2.0 200 OK 1019 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 1020 To: ;tag=JenZ40P3 1021 From: ;tag=a12eztNf 1022 Call-ID: kBq5XhtZLN@pres.example.com 1023 CSeq: 980774491 SUBSCRIBE 1024 Contact: 1025 Expires: 3600 1026 Content-Length: 0 1028 11. In this example, we are assuming that the RLS in example.org is 1029 also an authority for presence information for the users in the 1030 "example.org" domain. The NOTIFY contains an RLMI document 1031 describing the contained buddy list, as well as presence 1032 information for those users. In this particular case, the RLS 1033 in example.org has chosen to sign [13] the body of the NOTIFY 1034 message. As described in RFC 2633, signing is performed by 1035 creating a multipart/signed document which has two parts. The 1036 first part is the document to be signed (in this example, the 1037 multipart/related document that describes the list resource 1038 states), while the second part is the actual signature. 1040 RLS in example.org -> Local RLS 1042 NOTIFY sip:pres.example.com SIP/2.0 1043 Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI 1044 Max-Forwards: 70 1045 From: ;tag=JenZ40P3 1046 To: ;tag=a12eztNf 1047 Call-ID: kBq5XhtZLN@pres.example.com 1048 CSeq: 294444656 NOTIFY 1049 Contact: 1050 Event: presence 1051 Subscription-State: active;expires=3600 1052 Require: eventlist 1053 Content-Type: multipart/signed;protocol="application/pkcs7-signature"; 1054 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1055 Content-Length: 2038 1057 --l3WMZaaL8NpQWGnQ4mlU 1058 Content-Transfer-Encoding: 8bit 1059 Content-ID: 1060 Content-Type: multipart/related;type="application/rlmi+xml"; 1061 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 1063 --tuLLl3lDyPZX0GMr2YOo 1064 Content-Transfer-Encoding: 8bit 1065 Content-ID: 1066 Content-Type: application/rlmi+xml;charset="UTF-8" 1068 1069 1072 1073 1074 1075 1076 1077 1078 1080 --tuLLl3lDyPZX0GMr2YOo 1081 Content-Transfer-Encoding: 8bit 1082 Content-ID: 1083 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1085 1086 1088 1089 1090 open 1091 1092 sip:joe@example.org 1093 1094 1096 --tuLLl3lDyPZX0GMr2YOo 1097 Content-Transfer-Encoding: 8bit 1098 Content-ID: 1099 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1101 1102 1104 1105 1106 closed 1107 1108 1109 1110 --tuLLl3lDyPZX0GMr2YOo-- 1112 --l3WMZaaL8NpQWGnQ4mlU 1113 Content-Transfer-Encoding: 8bit 1114 Content-ID: 1115 Content-Type: application/pkcs7-signature 1117 [PKCS #7 signature here] 1119 --l3WMZaaL8NpQWGnQ4mlU-- 1121 12. The Local RLS completes the NOTIFY transaction. 1123 Local RLS -> RLS in example.org 1125 SIP/2.0 200 OK 1126 Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI 1127 From: ;tag=JenZ40P3 1128 To: ;tag=a12eztNf 1129 Call-ID: kBq5XhtZLN@pres.example.com 1130 CSeq: 294444656 NOTIFY 1131 Contact: 1132 Content-Length: 0 1134 13. At this point, the Local RLS decides it has collected enough 1135 additional information to warrant sending a new notification to 1136 the user. Although sending a full notification would be 1137 perfectly acceptable, the RLS decides to send a partial 1138 notification instead. The RLMI document contains only 1139 information for the updated resources, as indicated by setting 1140 the "fullState" parameter to "false". To avoid corrupting the 1141 S/MIME signature on the data received from the RLS in 1142 example.org, the local RLS copies the entire application/signed 1143 body as-is into the notification that it sends. 1145 Local RLS -> Terminal 1147 NOTIFY sip:terminal.example.com SIP/2.0 1148 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1149 Max-Forwards: 70 1150 From: ;tag=zpNctbZq 1151 To: ;tag=ie4hbb8t 1152 Call-ID: cdB34qLToC@terminal.example.com 1153 CSeq: 997935769 NOTIFY 1154 Contact: 1155 Event: presence 1156 Subscription-State: active;expires=7200 1157 Require: eventlist 1158 Content-Type: multipart/related;type="application/rlmi+xml"; 1159 start="<2BEI83@pres.example.com>";boundary="TfZxoxgAvLqgj4wRWPDL" 1160 Content-Length: 2862 1162 --TfZxoxgAvLqgj4wRWPDL 1163 Content-Transfer-Encoding: 8bit 1164 Content-ID: <2BEI83@pres.example.com> 1165 Content-Type: application/rlmi+xml;charset="UTF-8" 1167 1168 1171 1172 1173 1174 1175 1176 1177 1179 --TfZxoxgAvLqgj4wRWPDL 1180 Content-Transfer-Encoding: 8bit 1181 Content-ID: <1KQhyE@pres.example.com> 1182 Content-Type: multipart/signed;protocol="application/pkcs7-signature"; 1183 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1185 --l3WMZaaL8NpQWGnQ4mlU 1186 Content-Transfer-Encoding: 8bit 1187 Content-ID: 1188 Content-Type: multipart/related;type="application/rlmi+xml"; 1189 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 1191 --tuLLl3lDyPZX0GMr2YOo 1192 Content-Transfer-Encoding: 8bit 1193 Content-ID: 1194 Content-Type: application/rlmi+xml;charset="UTF-8" 1196 1197 1200 1201 1203 1204 1205 1206 1207 1209 --tuLLl3lDyPZX0GMr2YOo 1210 Content-Transfer-Encoding: 8bit 1211 Content-ID: 1212 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1214 1215 1217 1218 1219 open 1220 1221 sip:joe@example.org 1222 1223 1225 --tuLLl3lDyPZX0GMr2YOo 1226 Content-Transfer-Encoding: 8bit 1227 Content-ID: 1228 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1230 1231 1233 1234 1235 closed 1236 1237 1238 1240 --tuLLl3lDyPZX0GMr2YOo-- 1242 --l3WMZaaL8NpQWGnQ4mlU 1243 Content-Transfer-Encoding: 8bit 1244 Content-ID: 1245 Content-Type: application/pkcs7-signature 1247 [PKCS #7 signature here] 1249 --l3WMZaaL8NpQWGnQ4mlU-- 1250 --TfZxoxgAvLqgj4wRWPDL-- 1252 14. The terminal completes the NOTIFY transaction. 1254 Terminal -> Local RLS 1256 SIP/2.0 200 OK 1257 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1258 From: ;tag=zpNctbZq 1259 To: ;tag=ie4hbb8t 1260 Call-ID: cdB34qLToC@terminal.example.com 1261 CSeq: 997935769 NOTIFY 1262 Contact: 1263 Content-Length: 0 1265 7. Security Considerations 1267 Note that the mechanisms for obtaining state information for 1268 resources in a list are generally left to the RLS implementor. Some 1269 of the security issues below are specific to the the circumstance 1270 that a SIP back-end subscription is used for such a purpose. Non-SIP 1271 mechanisms for obtaining state information of resources in a list 1272 will typically have their own security issues associated with doing 1273 so; however, exhaustively enumerating such access methods is not 1274 possible in this document. Implementors using such mechanisms must 1275 analyze their chosen access methods for relevant security issues. 1277 7.1 Authentication 1279 If back-end subscriptions are required to retrieve resource state 1280 information, the end user is no longer the direct subscriber to the 1281 state of the resource. If the notifier for the resource demands end- 1282 to-end authentication, the RLS will need to be provided appropriate 1283 credentials to access those resources (e.g. shared secrets for 1284 Digest authentication). This requires a certain level of trust 1285 between the user and their RLS. This specification does not describe 1286 any particular means of providing such credentials to the RLS (such 1287 as uploading a shared secret). However, any such upload mechanism 1288 MUST ensure privacy of the key data; using HTTPS [15] to fill out a 1289 form is a reasonable method. 1291 If the notifier for the resource is using a transitive trust model to 1292 validate the subscriber, then this works well with the RLS concept 1293 and back-end subscriptions. The RLS would authenticate the 1294 subscriber, and then MAY use the SIP extensions for network asserted 1295 identity [7][8] to provide an authenticated identity to the notifiers 1296 for the resource. 1298 7.2 Risks of Improper Aggregation 1300 A resource list server typically serves information to multiple 1301 subscribers at once. In many cases, resources may be present in 1302 several lists; additionally, it is quite possible that resource list 1303 servers will have two users subscribe to the same list. 1305 In these cases, misguided RLS implementations may attempt to minimize 1306 network load by maintaining only one back-end subscription to a 1307 resource in a list, and presenting the result of such a subscription 1308 to more than one user. Of course, doing so circumvents any 1309 authorization policy that the notifier for the resource maintains. 1310 It is important to keep in mind that authorization is often much more 1311 than a simple binary "allowed/not allowed" decision; resources may 1312 render very different -- and even conflicting -- resource states, 1313 depending on the identity of the subscribing user. 1315 Implementations MUST NOT attempt to perform this type of optimization 1316 unless adequate access to complete authorization policy can be 1317 guaranteed. Note that this is a very difficult problem to solve 1318 correctly. Even in the cases that such access is believed possible, 1319 this mode of operation is NOT RECOMMENDED. 1321 7.3 Signing and Sealing 1323 Implementors should keep in mind that any section of the MIME body 1324 may be signed and/or encrypted as necessary. Resource List Servers 1325 should take care not to modify any MIME bodies they receive from any 1326 back-end subscriptions, and should not generally rely on being able 1327 to read them. 1329 In order to facilitate security, resource list servers SHOULD pass 1330 along indication for support of "multipart/signed" and "multipart/ 1331 encrypted" content types to any SIP back-end subscriptions, if the 1332 subscriber includes them in the initial SUBSCRIBE message. Not doing 1333 so may actually result in resources refusing to divulge state (if 1334 notifier policy requires encryption, but the RLS fails to convey 1335 support), or subscribers discarding valid state (if subscriber policy 1336 requires a signature, but the RLS fails to convey support). 1338 Note that actual implementation of encryption and signing by the RLS 1339 is not necessary to be able to pass through signed and/or encrypted 1340 bodies. 1342 7.4 Infinite Loops 1344 One risk introduced by the ability to nest resource lists is the 1345 possibility of creating lists which ultimately contain themselves as 1346 a sub-list. Detection and handling of such a case is trivial when 1347 the RLS services all of the virtual subscriptions internally. When 1348 back-end subscriptions are created to service virtual subscriptions, 1349 however, detection of such situations becomes a more difficult 1350 problem. 1352 Implementors of RLSes that create back-end subscriptions MUST 1353 implement safeguards to prevent such nestings from creating an 1354 infinite loop of subscriptions. Typically, such mechanisms will 1355 require support in the back-end subscription protocol. In 1356 particular, applying filters to the back-end subscriptions can be an 1357 effective way to preclude such problems. 1359 8. IANA Considerations 1361 8.1 New SIP Option Tag: eventlist 1363 This section defines a new option tag for the registry established by 1364 section 27.1 of RFC 3261[1]. 1366 Option Tag Name: eventlist 1368 Description: Extension to allow subscriptions to lists of resources 1370 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1371 with the RFC number of this document when published]] 1373 8.2 New MIME type for Resource List Meta-Information 1375 MIME Media Type Name: application 1377 MIME subtype name: rlmi+xml 1379 Required parameters: None 1381 Optional parameters: charset 1383 See RFC 3023 [12] for a discussion of the charset parameter on 1384 XML-derived MIME types. Since this MIME type is used exclusively 1385 in SIP, the use of UTF-8 encoding is strongly encouraged. 1387 Encoding considerations: 8-bit text 1389 Security considerations: Security considerations specific to uses of 1390 this this MIME type are discussed in RFC xxxx [[Note to RFC 1391 editor: replace xxxx with the RFC number of this document when 1392 published]]. RFC 1874 [11] and RFC 3023 [12] discuss security 1393 issues common to all uses of XML. 1395 Interoperability considerations: The use of this MIME body is 1396 intended to be generally interoperable. No unique considerations 1397 have been identified. 1399 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1400 with the RFC number of this document when published]] 1402 Applications which use this media type: This media type is used to 1403 convey meta-information for the state of lists of resources within 1404 a Session Initiation Protocol (SIP) subscription. 1406 Additional information: 1408 Magic Number(s): None. 1410 File Extension(s): None. 1412 Macintosh File Type Code(s): None. 1414 Object Identifier(s) or OID(s): None. 1416 Intended usage: Limited Use 1418 Other Information/General Comment: None. 1420 Person to contact for further information: 1422 Name: Adam Roach 1424 E-Mail: adam@dynamicsoft.com 1426 Author/Change Controller: The specification of this MIME type is a 1427 work product of the SIMPLE working group, and was authored by 1428 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1429 change control over its specification. 1431 8.3 URN Sub-Namespace 1433 URI: urn:ietf:params:xml:ns:rlmi 1435 Description: This is the XML namespace URI for XML elements defined 1436 by [RFCXXXX] to describe information about subscriptions when such 1437 subscriptions are aggregated within a single SIP subscription. It 1438 is used in the application/rlmi+xml body type. 1440 Registrant Contact: 1442 Name: Adam Roach 1444 E-Mail: adam@dynamicsoft.com 1446 Author/Change Controller: The specification of this MIME type is a 1447 work product of the SIMPLE working group, and was authored by 1448 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1449 change control over its specification. 1451 XML: 1453 BEGIN 1454 1455 1457 1458 1459 1461 Namespace for SIP Event Resource List 1462 Meta-Information 1463 1464 1465

Namespace for SIP Event Resource List Meta-Information

1466

application/rlmi+xml

1467

See RFCXXXX.

1468 1469 1470 END 1472 9. Acknowledgements 1474 Thanks to Sean Olson for a review of and corrections to the usage of 1475 XML in this protocol. 1477 Thanks also to Hisham Khartabil, Paul Kyzivat, and Keith Drage for 1478 their careful reviews of and comments on this document. 1480 Normative References 1482 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1483 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1484 Session Initiation Protocol", RFC 3261, June 2002. 1486 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1487 Notification", RFC 3265, June 2002. 1489 [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 1490 Extensions) Part One: Mechanisms for Specifying and Describing 1491 the Format of Internet Message Bodies", RFC 1521, September 1492 1993. 1494 [4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 1495 2387, August 1998. 1497 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1498 Levels", BCP 14, RFC 2119, March 1997. 1500 Non-Normative References 1502 [6] Rosenberg, J., "A Presence Event Package for the Session 1503 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 1504 in progress), January 2003. 1506 [7] Jennings, C., Peterson, J. and M. Watson, "Private Extensions 1507 to the Session Initiation Protocol (SIP) for Asserted Identity 1508 within Trusted Networks", RFC 3325, November 2002. 1510 [8] Peterson, J., "Enhancements for Authenticated Identity 1511 Management in the Session Initiation Protocol (SIP)", draft- 1512 ietf-sip-identity-01 (work in progress), February 2003. 1514 [9] Olson, S., "A Mechanism for Content Indirection in Session 1515 Initiation Protocol (SIP) Messages", draft-ietf-sip-content- 1516 indirect-mech-02 (work in progress), February 2003. 1518 [10] Crocker, D. and J. Peterson, "Common Profile for Presence 1519 (CPP)", draft-ietf-impp-pres-02 (work in progress), February 1520 2003. 1522 [11] Levinson, E., "SGML Media Types", RFC 1874, December 1995. 1524 [12] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1525 3023, January 2001. 1527 [13] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 1528 2633, June 1999. 1530 [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security 1531 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 1532 RFC 1847, October 1995. 1534 [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1536 Authors' Addresses 1538 Adam Roach 1539 dynamicsoft 1540 5100 Tennyson Pkwy 1541 Suite 1200 1542 Plano, TX 75024 1543 US 1545 EMail: adam@dynamicsoft.com 1546 Jonathan Rosenberg 1547 dynamicsoft 1548 600 Lanidex Plaza 1549 Parsippany, NJ 07054-2711 1550 US 1552 EMail: jdrosen@dynamicsoft.com 1554 Ben Campbell 1555 dynamicsoft 1556 5100 Tennyson Pkwy 1557 Suite 1200 1558 Plano, TX 75024 1559 US 1561 EMail: bcampbell@dynamicsoft.com 1563 Appendix A. Changes 1565 Note that this section will be removed before publication as an RFC. 1567 A.1 Changes since -02 1569 o Added discussion in security section about infinite loops. 1571 o Fixed several places where the document said "one or more" instead 1572 of "zero or more", when referring to the number of resources that 1573 can appear in a list and the number of instances that can appear 1574 in a resource. 1576 o Tiny editorial cleanup (mostly spelling gaffes). 1578 A.2 Changes since -01 1580 o Several editorial updates. Change "collection" to "list" 1581 everywhere. 1583 o Added terminology section. 1585 o Added restriction that cid attributes can only point to documents 1586 at the same level as the RLMI document in which they appear. 1588 o Clarified description of how to construct resource state by 1589 splitting discussion of full state notifications apart from 1590 discussion of partial-state notifications. 1592 A.3 Changes since -00 1594 o Removed text in several places which went into detail about 1595 specific implementations which used SIP SUB/NOT for back-end 1596 subscriptions. Some of this text will probably be published later 1597 as part of an implementors' guide. 1599 o Removed specific semantics for "Event" header field parameters and 1600 SUBSCRIBE bodies. These will be defined on a per-package basis, 1601 probably by the filtering work. 1603 o Added "cid" attribute to elements. 1605 o Reworked XML schema definition for meta-information. 1607 o Added IANA registration for XML namespace. 1609 o Minor editorial fixes 1611 Appendix B. Intellectual Property Statement 1613 The IETF takes no position regarding the validity or scope of any 1614 intellectual property or other rights that might be claimed to 1615 pertain to the implementation or use of the technology described in 1616 this document or the extent to which any license under such rights 1617 might or might not be available; neither does it represent that it 1618 has made any effort to identify any such rights. 1620 Information on the IETF's procedures with respect to rights in 1621 standards-track and standards-related documentation can be found in 1622 BCP-11. Copies of claims of rights made available for publication 1623 and any assurances of licenses to be made available, or the result of 1624 an attempt made to obtain a general license or permission for the use 1625 of such proprietary rights by implementors or users of this 1626 specification can be obtained from the IETF Secretariat. 1628 The IETF invites any interested party to bring to its attention any 1629 copyrights, patents or patent applications, or other proprietary 1630 rights which may cover technology that may be required to practice 1631 this standard. Please address the information to the IETF Executive 1632 Director. 1634 Full Copyright Statement 1636 Copyright (C) The Internet Society (2003). All Rights Reserved. 1638 This document and translations of it may be copied and furnished to 1639 others, and derivative works that comment on or otherwise explain it 1640 or assist in its implementation may be prepared, copied, published 1641 and distributed, in whole or in part, without restriction of any 1642 kind, provided that the above copyright notice and this paragraph are 1643 included on all such copies and derivative works. However, this 1644 document itself may not be modified in any way, such as by removing 1645 the copyright notice or references to the Internet Society or other 1646 Internet organizations, except as needed for the purpose of 1647 developing Internet standards in which case the procedures for 1648 copyrights defined in the Internet Standards process must be 1649 followed, or as required to translate it into languages other than 1650 English. 1652 The limited permissions granted above are perpetual and will not be 1653 revoked by the Internet Society or its successors or assigns. 1655 This document and the information contained herein is provided on an 1656 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1657 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1658 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1659 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1660 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1662 Acknowledgement 1664 Funding for the RFC Editor function is currently provided by the 1665 Internet Society.