idnits 2.17.1 draft-ietf-simple-event-list-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 15 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 737 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 5, 2003) is 7662 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 1418 == Unused Reference: '3' is defined on line 1471, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1496, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1512, 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 3, 2003 B. Campbell 5 dynamicsoft 6 May 5, 2003 8 A Session Initiation Protocol (SIP) Event Notification Extension for 9 Resource Lists 10 draft-ietf-simple-event-list-02 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 3, 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 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 76 8.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 32 77 8.2 New MIME type for Resource List Meta-Information . . . . . . 32 78 8.3 URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . . 33 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 80 Normative References . . . . . . . . . . . . . . . . . . . . 36 81 Non-Normative References . . . . . . . . . . . . . . . . . . 37 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 83 A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 39 84 A.1 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 39 85 A.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 39 86 B. Intellectual Property Statement . . . . . . . . . . . . . . 40 87 Full Copyright Statement . . . . . . . . . . . . . . . . . . 41 89 1. Introduction 91 The SIP-specific event notification mechanism [2] allows a user (the 92 subscriber) to request to be notified of changes in the state of a 93 particular resource. This is accomplished by having the subscriber 94 generate a SUBSCRIBE request for the resource, which is processed by 95 a notifier that represents the resource. 97 In many cases, a subscriber has a list of resources they are 98 interested in. Without some aggregating mechanism, this will require 99 the subscriber generate a SUBSCRIBE request for each resource about 100 which they want information. For environments in which bandwidth is 101 limited, such as wireless networks, subscribing to each resource 102 individually is problematic. Some specific problems are: 104 o Doing so generates substantial message traffic, in the form of the 105 initial SUBSCRIBE requests for each resource, and the refreshes of 106 each individual subscription. 108 o The notifier may insist on low refresh intervals, in order to 109 avoid long lived subscription state. This means that the 110 subscriber may need to generate SUBSCRIBE refreshes faster than it 111 would like to, or has the capacity to. 113 o The notifier may generate NOTIFY requests more rapidly than the 114 subscriber desires, causing NOTIFY traffic at a greater volume 115 than is desired by the subscriber. 117 To solve these problems, this specification defines an extension to 118 RFC 3265 [2] that allows for requesting and conveying notifications 119 for lists of resources. A resource list is identified by a URI and 120 it represents a list of zero or more URIs. Each of these URIs is an 121 identifier for an individual resource for which the subscriber wants 122 to receive information. In many cases, the URI will be a SIP URI 123 [1]; however, the use of other schemes (such as pres: [10]) is also 124 foreseen. 126 The notifier for the list is called a "resource list server", or RLS. 127 In order to determine the state of the entire list, the RLS will act 128 as if it has generated a subscription to each resource in the list. 130 The resource list is not restricted to be inside the domain of the 131 subscriber. Similarly, the resources in the list are not constrained 132 to be in the domain of the resource list server. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [5]. 140 The following terms are used throughout the remainder of this 141 document. 143 Back-End Subscription: Any subscription (SIP or otherwise) that an 144 RLS creates to learn of the state of a resource. An RLS will 145 create back-end subscriptions to learn of the state of a resource 146 about which the RLS is not an authority. For back-end 147 subscriptions, RLSes act as a subscriber. 149 List Subscription: A subscription to a resource list. In list 150 subscriptions, RLSes act a the notifier. 152 Resource: A resource is any logical entity that has a state or states 153 that can be subscribed to. Resources are identified by URIs. 155 Resource List: A list of zero or more resources that can have their 156 individual states subscribed to with a single subscription. 158 RLMI: Resource List Meta-Information. RLMI is a document that 159 describes the state of the virtual subscriptions associated with a 160 list subscription. 162 RLS: Resource List Server. RLSes accept subscriptions to resource 163 lists and send notifications to update subscribers of the state of 164 the resources in a resource list. 166 Virtual Subscription: Virtual Subscriptions are a logical construct 167 within an RLS that represent subscriptions to the resources in a 168 resource list. For each list subscription it services, an RLS 169 creates at least one virtual subscription for every resource in 170 the resource list being subscribed to. In some cases, such as 171 when the RLS is not the authority for the state of the resource, 172 this virtual subscription will be associated with a back-end 173 subscription. In other cases, such as when the RLS is the 174 authority for the state of the resource, the virtual subscription 175 will not have a corresponding back-end subscription. 177 3. Overview of Operation 179 This section provides an overview of the typical mode of operation of 180 this extension. It is not normative. 182 When users wish to subscribe to the resource of a list of resources, 183 they can use the mechanisms described in this specification. The 184 first step is creation of a resource list. This resource list is 185 represented by a SIP URI. The list contains a set of URIs, each of 186 which represents a resource for which the subscriber wants to receive 187 information. The resource list can exist in any domain. The list 188 could be manipulated through a web page, through a voice response 189 system, or through some other protocol. The specific means by which 190 the list is created and maintained is outside of the scope of this 191 specification. 193 To learn the resource state of the set of elements on the list, the 194 user sends a single SUBSCRIBE request targeted to the URI of the 195 list. This will be routed to an RLS for that URI. The RLS acts as a 196 notifier, authenticates the subscriber, and accepts the subscription. 198 The RLS may have direct information about some or all of the 199 resources specified by the list. If it does not, it could subscribe 200 to any non-local resources specified by the list resource. 202 Note that subscriptions to non-local resources may or may not be SIP 203 subscriptions; any mechanism for determining such information may be 204 employed. This document uses the term "back-end subscription" to 205 refer to such a subscription, regardless of whether SIP is used to 206 establish and service it. 208 As the state of resources in the list change, the RLS generates 209 notifications to the list subscribers. The RLS can, at its 210 discretion, buffer notifications of resource changes, and send the 211 resource information to the subscriber in batches, rather than 212 individually. This allows the RLS to provide rate limiting for the 213 subscriber. 215 The list notifications contain a body of type multipart/related. The 216 root section of the multipart/related content is an XML document that 217 provides meta-information about each resource present in the list. 218 The remaining sections contain the actual state information for each 219 resource. 221 4. Operation of List Subscriptions 223 The event list extension acts, in many ways, like an event template 224 package. In particular, any single list subscription must be 225 homogeneous with respect to the underlying event package. In other 226 words, a single list subscription can apply only one event package to 227 all of the resources in the resource list. 229 It is worth noting that it is perfectly valid, for an RLS to allow 230 multiple subscriptions to the same list to use differing event 231 packages. 233 The key difference between a list subscription and templates in 234 general is that support for list subscriptions indicates support for 235 arbitrary nesting of list subscriptions. In other words, elements 236 within the list may be atomic elements, or they may be lists 237 themselves. 239 The consequence of this is that subscription to a URI that represents 240 a list actually results in a several virtual subscriptions to a tree 241 of resources. The leaf nodes of this tree are virtual subscriptions 242 of the event type given in the "Event" header field; all other nodes 243 in the tree are list subscriptions that are serviced as described in 244 this section and its subsections. 246 It is important to keep in mind that these virtual subscriptions are 247 not literal SIP subscriptions (although they may result in SIP 248 subscriptions, depending on the RLS implementation). 250 4.1 Negotiation of Support for Resource Lists 252 This specification uses the SIP option tag mechanism for negotiating 253 support for the extension defined herein. Refer to RFC3261 [1] for 254 the normative description of processing of the "Supported" and 255 "Require" header fields and the 421 (Extension Required) response 256 code. 258 A non-normative description of the implications of the use of 259 option tags follows. 261 Any client that supports the event list extension will include an 262 option tag of "eventlist" in a "Supported" header field of every 263 SUBSCRIBE message for a subscription for which it is willing to 264 process a list. If the subscription is made to a URI that 265 represents a list, the RLS will include "eventlist" in a "Require" 266 header field of the response to the SUBSCRIBE, and in all NOTIFY 267 messages within that subscription. 269 Use of "Require: eventlist" in NOTIFY messages is applied by the 270 notifier to satisfy the RFC3261 requirement that a UAC MUST insert 271 a Require header field into a request if the UAC wishes to insist 272 that a UAS understand an extension in order to process the 273 request. Because the NOTIFY would not be usable without applying 274 the eventlist option, the notifier is obligated to include it. 276 Including "eventlist" in a "Require" header field in a SUBSCRIBE 277 request serves no purpose, and is consequently NOT RECOMMENDED. 279 There is nothing in a SIP URI which indicates whether it represents a 280 list of resources or a single resource. Therefore, if a subscriber 281 sends a request to a URI that represents a list resource, but does 282 not include a Supported header field listing the "eventlist" token, 283 the notifier will typically return a 421 (Extension Required) 284 response code. RFC 3261 [1] advises servers to avoid returning a 285 421, and instead, attempt to process the request without the 286 extension. However, in this case, the URI fundamentally represents a 287 list resource, and therefore, the subscription cannot proceed without 288 this extension. 290 4.2 Subscription Duration 292 Since the primary benefit of the resource list server is to reduce 293 the overall messaging volume to a subscriber, it is RECOMMENDED that 294 the subscription duration to a list be reasonably long. The default, 295 when no duration is specified, is taken from the underlying event 296 package. Of course, the standard techniques [2] can be used to 297 increase or reduce this amount. 299 4.3 NOTIFY Bodies 301 An implementation compliant to this specification MUST support the 302 multipart/related and application/rlmi+xml MIME types. These types 303 MUST be included in an Accept header sent in SUBSCRIBE message, in 304 addition to any other types supported by the client (including any 305 types required by the event package being used). 307 4.4 RLS Processing of SUBSCRIBE Requests 309 Once the subscriber is authenticated, the RLS performs authorization 310 per its local policy. In many cases, each resource list is 311 associated with a particular user (the one who created it and manages 312 the set of elements in it), and only that user will be allowed to 313 subscribe. Of course, this mode of operation is not inherent in the 314 use of resource lists, and an RLS can use any authorization policy it 315 chooses. 317 4.5 RLS Generation of NOTIFY requests 319 This specification leaves the choice about how and when to generate 320 NOTIFY requests at the discretion of the implementor. One of the 321 value propositions of the RLS is the means by which it aggregates, 322 rate limits, or optimizes the way in which notifications are 323 generated. As a baseline behavior, the RLS MAY generate a NOTIFY to 324 the RLS subscriber whenever the state of any resource on the list 325 changes. 327 See Section 5 for a detailed definition of the syntax used to convey 328 the state of resource lists. For the purposes of the following 329 discussion, it is important to know that the overall list contains 330 one or more resources, and that the resources contains one or more 331 instances. Each instance has a state associated with it (pending, 332 active, or terminating), representing the state of the virtual 333 subscription. 335 Notifications contain a multipart document, the first part of which 336 always contains meta-information about the list (e.g. membership, 337 state of the virtual subscription to the resource). Remaining parts 338 are used to convey the actual state of the resources listed in the 339 meta-information. 341 The "state" attribute of each instance of a resource in the meta- 342 information is set according to the state of the virtual 343 subscription. The meanings of the "state" attribute are described in 344 RFC 3265 [2]. 346 If an instance of a resource was previously reported to the 347 subscriber but is no longer available (i.e. the virtual subscription 348 to that instance has been terminated), the resource list server 349 SHOULD include that resource instance in the meta-information in the 350 first NOTIFY message sent to the subscriber following the instance's 351 unavailability. The RLS MAY continue to do so for future 352 notifications. 354 When sending information for a terminated resource instance, the RLS 355 indicates a state of "terminated" and an appropriate reason value. 356 Valid reason values and their meanings are described in RFC 3265 [2]. 357 If the RLS will attempt to recover the resource state again at some 358 point in the future (e.g. when the reason in the meta-information is 359 "probation"), then the instance of the resource SHOULD remain in the 360 meta-information until the instance state is available, or until the 361 RLS gives up on making such state available. 363 When the first SUBSCRIBE message for a particular subscription is 364 received by a RLS, the RLS will often not know state information for 365 all of the resources specified by the resource list. For any 366 resource for which state information is not known, the corresponding 367 "uri" attribute will be set appropriately, and no elements 368 will be present for the resource. 370 For an initial notification, sections corresponding to resources for 371 which the RLS does have state will be populated with appropriate data 372 (subject, of course, to local policy decisions). This will often 373 occur if the resource list server is co-located with the server for 374 one or more of the resources specified on the list. 376 Immediate notifications triggered as a result of subsequent SUBSCRIBE 377 messages SHOULD include an RLMI document with full state indicated. 378 The RLS SHOULD also include state information for all resources in 379 the list for which the RLS has state, subject to policy restrictions. 380 This allows the subscriber to refresh their state, and to recover 381 from lost notifications. 383 4.6 Subscriber Processing of NOTIFY Requests 385 Notifications for a resource list can convey information about a 386 subset of the list elements. This means that an explicit algorithm 387 needs to be defined in order to construct coherent and consistent 388 state. 390 The XML document present in the root of the multipart/related 391 document contains a element for some or all of the 392 resources in the list. Each element contains a URI which 393 uniquely identifies the resource to which that section corresponds. 394 When a NOTIFY arrives, it can contain full or partial state (as 395 indicate by the "fullState" attribute of the top-level 396 element). If full state is indicated, then the recipient replaces 397 all state associated with the list with the entities in the NOTIFY 398 body. If full state is not indicated, the recipient of the NOTIFY 399 updates information for each identified resource. Information for 400 any resources that are not identified in the NOTIFY are not changed, 401 even if they were indicated in previous NOTIFY messages. See Section 402 5.5 for more information. 404 When full state is indicated, note that it applies only to the 405 RLMI document in which it occurs. In particular, one of the 406 elements in the document may in turn refer to another 407 list of resources. Any such sub-lists will be detailed in their 408 own RLMI documents, which may or may not have full state 409 indicated. 411 Further note that underlying event package may have its own rules 412 for compositing partial state notification. When processing data 413 related to those packages, their rules apply (i.e. the fact that 414 they were reported as part of a list does not change their partial 415 notification semantics). 417 Finally, note that a consequence of the way in which resource list 418 subscriptions work is that polling of resource state may not be 419 particularly useful. While such polls will retrieve the resource 420 list, they will not necessarily contain state for some or all of 421 the resources on the list. 423 4.7 Handling of Forked Requests 425 Forking makes little sense with subscriptions to event lists, since 426 the whole idea is a centralization of the source of notifications. 427 Therefore, a subscriber to a list MUST NOT install multiple 428 subscriptions when the initial request is forked. If multiple 429 responses are received, they are handled using the techniques 430 described in section 4.4.9 of RFC 3265[2]. 432 4.8 Rate of Notifications 434 One potential role of the RLS is to perform rate limitations on 435 behalf of the subscriber. As such, this specification does not 436 mandate any particular rate limitation, and rather leaves that to the 437 discretion of the implementation. 439 5. Using multipart/related to Convey Aggregate State 441 In order to convey the state of multiple resources, the list 442 extension uses the "multipart/related" mime type. The syntax for 443 multipart/related is defined in "The MIME Multipart/Related Content- 444 type" [4]. 446 5.1 XML Syntax 448 The root document of the multipart/related body MUST be a Resource 449 List Meta-Information (RLMI) document. It is of type "application/ 450 rlmi+xml". This document contains the meta-information for the 451 resources contained in the notification. The schema for this XML 452 document is given below. 454 455 459 460 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 487 488 489 490 491 492 493 494 495 497 An example of a document formatted using this schema follows. 499 500 503 504 505 506 507 508 509 510 511 512 513 514 515 517 5.2 List Attributes 519 The element present in a list notification MUST contain three 520 attributes. 522 The first mandatory attribute is "uri", which contains the uri 523 that corresponds to the list. Typically, this is the URI to which 524 the SUBSCRIBE request was sent. 526 The second mandatory attribute is "version", which contains a 527 number from 0 to 2^32-1. This version number MUST be 0 for the first 528 NOTIFY message sent within a subscription, and MUST increase by 529 exactly one for each subsequent NOTIFY sent within a subscription. 531 The third mandatory attribute is "fullState". The "fullState" 532 attribute indicates whether the NOTIFY message contains information 533 for every resource in the list. If it does, the value of the 534 attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The 535 first NOTIFY sent in a subscription MUST contain full state, as must 536 the first NOTIFY sent after receipt of a SUBSCRIBE request for the 537 subscription. 539 The optional "name" attribute contains a human readable description 540 or name for the resource list. This attribute is somewhat analogous 541 to the "Display Name" present in the SIP name-addr element. 543 Finally, elements MAY contain a "cid" attribute. If present, 544 the "cid" attribute identifies a section within the multipart/related 545 body that contains aggregate state information for the resources 546 contained in the list. The definition of such aggregate information 547 is outside the scope of this document, and will be defined on a per- 548 package basis as needed. The cid attribute is the Content-ID for the 549 corresponding section in the multipart body. 551 The cid attribute MUST refer only to top-level parts of the 552 multipart/related document for which the RLMI document in which it 553 appears is the root. See Section 5.4 for an example. 555 5.3 Resource Attributes 557 The resource list contains one element for each resource 558 being reported in the notification. These resource elements contain 559 attributes that identify meta-data assocated with each resource. 561 The "uri" attribute identifies the resource to which the 562 element corresponds. Typically, this will be a SIP URI which, if 563 subscribed to, would return the state of the resource. This 564 attribute MUST be present. 566 The optional "name" attribute can contain a human readable 567 description or name for the resource. This attribute is somewhat 568 analogous to the "Display Name" present in the SIP name-addr element. 570 5.4 Instance Attributes 572 Each resource element contains one or more instance elements. These 573 instance elements are used to represent a single notifier for the 574 resource. For event packages that allow forking, multiple virtual 575 subscriptions may exist for a given resource. Multiple virtual 576 subscriptions are represented as multiple instance elements in the 577 corresponding resource element. For subscriptions in which forking 578 does not occur, at most one instance will be present for a given 579 resource. 581 The "id" attribute contains an opaque string used to uniquely 582 identify the instance of the resource. The "id" attribute is unique 583 only within the context of a resource. Construction of this string 584 is an implementation decision. Any mechanism for generating this 585 string is valid, as long as uniqueness within the resource is 586 assured. 588 The "state" attribute contains the subscription state for the 589 identified instance of the resource. This attribute contains one of 590 the values "active", "pending", or "terminated". The meanings for 591 these values are as defined for the "Subscription-State" header field 592 in RFC 3265 [2]. 594 If the "state" attribute indicates "terminated", then a "reason" 595 attribute MUST also be present. This "reason" attribute has the same 596 values and meanings as given for the "reason" parameter on the 597 "Subscription-State" header field in RFC 3265 [2]. Note that the 598 "reason" attribute is included for informational purposes; the list 599 subscriber is not expected to take any automated actions based on the 600 reason value. 602 Finally, the "cid" attribute, which MUST be present if the "state" 603 attribute is "active", identifies the section within the multipart/ 604 related body that contains the actual resource state. This state is 605 expressed in the content type defined by the event package for 606 conveying state. The cid attribute is the Content-ID for the 607 corresponding section in the multipart body. 609 The cid attribute MUST refer only to top-level parts of the 610 multipart/related document for which the RLMI document in which it 611 appears is the root. 613 For example, consider a multipart/related document containing 614 three parts; we'll label these parts A, B, and C. Part A is type 615 application/rlmi+xml, part B is type multipart/related, and part C 616 is type application/cpim-pidf+xml. Part B is in turn a document 617 containing three parts: D, E, and F. Part D is of type 618 application/rlmi+xml, and parts E and F are of type application/ 619 cpim-pidf+xml. 621 +-------------------------------------------+ 622 | Top Level Document: multipart/related | 623 | | 624 | +---------------------------------------+ | 625 | | Part A: application/rlmi+xml | | 626 | +---------------------------------------+ | 627 | | Part B: multipart/related | | 628 | | | | 629 | | +-----------------------------------+ | | 630 | | | Part D: application/rlmi+xml | | | 631 | | +-----------------------------------+ | | 632 | | | Part E: application/cpim-pidf+xml | | | 633 | | +-----------------------------------+ | | 634 | | | Part F: application/cpim-pidf+xml | | | 635 | | +-----------------------------------+ | | 636 | | | | 637 | +---------------------------------------+ | 638 | | Part C: application/cpim-pidf+xml | | 639 | +---------------------------------------+ | 640 | | 641 +-------------------------------------------+ 643 Any "cid" attributes in document A must refer only to parts B or 644 C. Referring to parts D, E, or F would be illegal. Similarly, 645 Any "cid" attributes in document D must refer only to parts E or 646 F. Referring to any other parts would be illegal. 648 Also note that the subscription durations of any back-end 649 subscriptions are not propagated into the meta-information state 650 in any way. 652 5.5 Constructing Coherent Resource State 654 The resource list subscriber maintains a table for each resource 655 list. The table contains a row for each resource in the resource 656 list. Each row is indexed by the URI for that resource. That URI is 657 obtained from the "uri" attribute on each element. The 658 contents of each row contain the state of that resource as conveyed 659 in the resource document. 661 For resources that provide versioning information (which is mandated 662 by [2] for any formats that allow partial notification), each row 663 also contains a resource state version number. The version number of 664 the row is initialized with the version specified in the first 665 document received, as defined by the corrsponding event package. 666 This value is used when comparing versions of partial notifications 667 for a resource. 669 The processing of the resource list notification depends on whether 670 it contains full or partial state. 672 5.5.1 Processing Full State Notifications 674 If a notification contains full state, indicated by the value of the 675 attribute "fullState", the notification is used to update the 676 table. A check is first made to ensure that the "version" attribute 677 of the attribute in the received message is greater than the 678 local version number. If not, the received document is discarded 679 without any further processing. Otherwise, the contents of the 680 resource-list table are flushed, and repopulated from the contents of 681 the document. A new row in the table is created for each "resource" 682 element. 684 5.5.2 Processing Partial State Notifications 686 If a notification contains partial state, indicated by the value of 687 the attribute "fullState", a check is made to ensure that no 688 list notifications have been lost. The value of the local version 689 number (the "version" attribute of the element) is compared to 690 the version number of the new document. 692 o If the value in the new document is exactly one higher than the 693 local version number, the local version number is increased by 694 one, and the document is processed, as described below. 696 o If the version in the document is more than one higher than the 697 local version number, the local version number is set to the value 698 in the new document, and the document is processed as described 699 below. Further, if the notification does not contain full state 700 (as indicated by the "fullState" attribute of the element), 701 the list subscriber SHOULD generate a refresh request to trigger a 702 full state notification. 704 o If the version in the document is less than or equal to the local 705 version, the document is discarded without any further processing. 707 For each resource listed in the document, the subscriber checks to 708 see whether a row exists for that resource. This check is done by 709 comparing the Resource-URI value with the URI associated with the 710 row. If the resource doesn't exist in the table, a row is added, and 711 its state is set to the information from that "resource" element. If 712 the resource does exist, its state is updated to be the information 713 from that "resource" element, as described in the definition of the 714 event package. If a row is updated or created such that its state is 715 now "terminated," that entry MAY be removed from the table at any 716 time. 718 6. Example 720 This section gives an example callflow. It is not normative. If a 721 conflict arises between this callflow and the normative behavior 722 described in this or any other document, the normative descriptions 723 are to be followed. 725 In this particular example, we request a subscription to a nested 726 presence list. The subscriber's address-of-record is 727 "sip:adam@example.com", and the name of the nested list resource that 728 we are subscribing to is called "sip:adam-buddies@pres.example.com". 729 The underlying event package is "presence", described by [6]. 731 In this example, the RLS has information to service some of the 732 resources on the list, but must consult other servers to retrive 733 information for others. The implementation of the RLS in this 734 example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such 735 information. 737 Terminal pres.example.com pres.example.org 738 | | pres.example.net | 739 1 |---SUBSCRIBE--->| | | 740 2 |<-----200-------| | | 741 3 |<----NOTIFY-----| | | 742 4 |------200------>| | | 743 5 | |---SUBSCRIBE--->| | 744 6 | |<-----200-------| | 745 7 | |<----NOTIFY-----| | 746 8 | |------200------>| | 747 9 | |------------SUBSCRIBE----------->| 748 10| |<--------------200---------------| 749 11| |<-------------NOTIFY-------------| 750 12| |---------------200-------------->| 751 13|<----NOTIFY-----| | | 752 14|------200------>| | | 754 1. We initate the subscription by sending a SUBSCRIBE message to 755 our local RLS. (There is no reason that the RLS we contact has 756 to be in our domain, of course). Note that we must advertise 757 support for application/rlmi+xml and multipart/related because 758 we support the eventlist extension, and we must advertise 759 application/cpim-pidf+xml because we are requesting a 760 subscription to presence. 762 Terminal -> Local RLS 764 SUBSCRIBE sip:adam-buddies@pres.example.com SIP/2.0 765 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 766 Max-Forwards: 70 767 To: 768 From: ;tag=ie4hbb8t 769 Call-ID: cdB34qLToC@terminal.example.com 770 CSeq: 322723822 SUBSCRIBE 771 Contact: 772 Event: presence 773 Expires: 7200 774 Supported: eventlist 775 Accept: application/cpim-pidf+xml 776 Accept: application/rlmi+xml 777 Accept: multipart/related 778 Accept: multipart/signed 779 Accept: multipart/encrypted 780 Content-Length: 0 782 2. The Local RLS completes the SUBSCRIBE transaction. Note that 783 authentication and authorization would normally take place at 784 this point in the callflow. Those steps are omitted for 785 brevity. 787 Local RLS -> Terminal 789 SIP/2.0 200 OK 790 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 791 To: ;tag=zpNctbZq 792 From: ;tag=ie4hbb8t 793 Call-ID: cdB34qLToC@terminal.example.com 794 CSeq: 322723822 SUBSCRIBE 795 Contact: 796 Expires: 7200 797 Require: eventlist 798 Content-Length: 0 800 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY 801 immediately upon accepting the subscription. In this example, 802 we are assuming that the local RLS is also an authority for 803 presence information for the users in the "example.com" domain. 804 The NOTIFY contains an RLMI document describing the entire buddy 805 list (initial notifies require full state), as well as presence 806 information for the users about which it already knows. Note 807 that, since the RLS has not yet retrieved information for some 808 of the entries on the list, those elements contain no 809 elements. 811 Local RLS -> Terminal 813 NOTIFY sip:terminal.example.com SIP/2.0 814 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 815 Max-Forwards: 70 816 From: ;tag=zpNctbZq 817 To: ;tag=ie4hbb8t 818 Call-ID: cdB34qLToC@terminal.example.com 819 CSeq: 997935768 NOTIFY 820 Contact: 821 Event: presence 822 Subscription-State: active;expires=7200 823 Require: eventlist 824 Content-Type: multipart/related;type="application/rlmi+xml"; 825 start="";boundary="50UBfW7LSCVLtggUPe5z" 826 Content-Length: 1560 828 --50UBfW7LSCVLtggUPe5z 829 Content-Transfer-Encoding: 8bit 830 Content-ID: 831 Content-Type: application/rlmi+xml;charset="UTF-8" 833 834 837 838 839 840 841 842 843 844 845 847 --50UBfW7LSCVLtggUPe5z 848 Content-Transfer-Encoding: 8bit 849 Content-ID: 850 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 852 853 855 856 857 open 858 859 sip:bob@example.com 860 861 863 --50UBfW7LSCVLtggUPe5z 864 Content-Transfer-Encoding: 8bit 865 Content-ID: 866 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 868 869 871 872 873 closed 874 875 876 878 --50UBfW7LSCVLtggUPe5z-- 880 4. The terminal completes the transaction. 882 Terminal -> Local RLS 884 SIP/2.0 200 OK 885 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 886 From: ;tag=zpNctbZq 887 To: ;tag=ie4hbb8t 888 Call-ID: cdB34qLToC@terminal.example.com 889 CSeq: 997935768 NOTIFY 890 Contact: 891 Content-Length: 0 893 5. In order to service the subscription, the local RLS subscribes 894 to the state of the resources. In this step, the RLS attempts 895 to subscribe to the presence state of the resource 896 "sip:ed@example.net". Since the local RLS knows how to receive 897 notifications for list subscriptions, it includes the 898 "Supported: eventlist" header field in its request. Although 899 the linkage between this subscription and the one sent by the 900 terminal is left up to the application, this message 901 demonstrates some reasonable behavior by including "Accept" 902 header fields for all of the body types it knows the subscriber 903 (Terminal) supports. This is safe to do, since the local RLS 904 will only pass these formats through to the subscriber, and does 905 not need to actually understand them. 907 Local RLS -> Presence Server in example.net 909 SUBSCRIBE sip:ed@example.net SIP/2.0 910 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 911 Max-Forwards: 70 912 To: 913 From: ;tag=aM5icQu9 914 Call-ID: Ugwz5ARxNw@pres.example.com 915 CSeq: 870936068 SUBSCRIBE 916 Contact: 917 Event: presence 918 Expires: 3600 919 Supported: eventlist 920 Accept: application/cpim-pidf+xml 921 Accept: application/rlmi+xml 922 Accept: multipart/related 923 Accept: multipart/signed 924 Accept: multipart/encrypted 925 Content-Length: 0 927 6. The Presence Server in example.net completes the SUBSCRIBE 928 transaction. Note that authentication would normally take place 929 at this point in the callflow. Those steps are omitted for 930 brevity. 932 Presence Server in example.net -> Local RLS 934 SIP/2.0 200 OK 935 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 936 To: ;tag=e45TmHTh 937 From: ;tag=aM5icQu9 938 Call-ID: Ugwz5ARxNw@pres.example.com 939 CSeq: 870936068 SUBSCRIBE 940 Contact: 941 Expires: 3600 942 Content-Length: 0 944 7. In this example, we assume that the server at example.net 945 doesn't have enough authorization information to reject or 946 accept our subscription. The initial notify, therefore, 947 contains a "Subscription-State" of "pending". Presumably, the 948 party responsible for accepting or denying authorization for the 949 resource is notified of this change; however, those steps are 950 not included in this call flow for brevity. 952 Presence Server in example.net -> Local RLS 954 NOTIFY sip:pres.example.com SIP/2.0 955 Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW 956 Max-Forwards: 70 957 From: ;tag=e45TmHTh 958 To: ;tag=aM5icQu9 959 Call-ID: Ugwz5ARxNw@pres.example.com 960 CSeq: 1002640632 NOTIFY 961 Contact: 962 Subscription-State: pending;expires=3600 963 Event: presence 964 Require: eventlist 965 Content-Length: 0 967 8. The local RLS completes the NOTIFY transaction. Note that, at 968 this point, the Local RLS has new information to report to the 969 subscriber. Whether it chooses to report the information 970 immediately or spool it up for later delivery is completely up 971 to the application. For this example, we assume that the RLS 972 will wait for a short period of time before doing so, in order 973 to allow the subscriptions it sent out sufficient time to 974 provide useful data. 976 Local RLS -> Presence Server in example.net 978 SIP/2.0 200 OK 979 Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW 980 From: ;tag=e45TmHTh 981 To: ;tag=aM5icQu9 982 Call-ID: Ugwz5ARxNw@pres.example.com 983 CSeq: 1002640632 NOTIFY 984 Contact: 985 Content-Length: 0 987 9. The Local RLS subscribes to the state of the other non-local 988 resource. 990 Local RLS -> RLS in example.org 992 SUBSCRIBE sip:adam-friends@example.org SIP/2.0 993 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 994 Max-Forwards: 70 995 To: 996 From: ;tag=a12eztNf 997 Call-ID: kBq5XhtZLN@pres.example.com 998 CSeq: 980774491 SUBSCRIBE 999 Contact: 1000 Event: presence 1001 Expires: 3600 1002 Supported: eventlist 1003 Accept: application/cpim-pidf+xml 1004 Accept: application/rlmi+xml 1005 Accept: multipart/related 1006 Accept: multipart/signed 1007 Accept: multipart/encrypted 1008 Content-Length: 0 1010 10. The RLS in example.org completes the SUBSCRIBE transaction. 1011 Note that authentication and would normally take place at this 1012 point in the callflow. Those steps are omitted for brevity. 1014 RLS in example.org -> Local RLS 1016 SIP/2.0 200 OK 1017 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 1018 To: ;tag=JenZ40P3 1019 From: ;tag=a12eztNf 1020 Call-ID: kBq5XhtZLN@pres.example.com 1021 CSeq: 980774491 SUBSCRIBE 1022 Contact: 1023 Expires: 3600 1024 Content-Length: 0 1026 11. In this example, we are assuming that the RLS in example.org is 1027 also an authority for presence information for the users in the 1028 "example.org" domain. The NOTIFY contains an RLMI document 1029 describing the contained buddy list, as well as presence 1030 information for those users. In this particular case, the RLS 1031 in example.org has chosen to sign [13] the body of the NOTIFY 1032 message. As described in RFC 2633, signing is performed by 1033 creating a multipart/signed document which has two parts. The 1034 first part is the document to be signed (in this example, the 1035 multipart/related document that describes the list resource 1036 states), while the second part is the actual signature. 1038 RLS in example.org -> Local RLS 1040 NOTIFY sip:pres.example.com SIP/2.0 1041 Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI 1042 Max-Forwards: 70 1043 From: ;tag=JenZ40P3 1044 To: ;tag=a12eztNf 1045 Call-ID: kBq5XhtZLN@pres.example.com 1046 CSeq: 294444656 NOTIFY 1047 Contact: 1048 Event: presence 1049 Subscription-State: active;expires=3600 1050 Require: eventlist 1051 Content-Type: multipart/signed;protocol="application/pkcs7-signature"; 1052 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1053 Content-Length: 2038 1055 --l3WMZaaL8NpQWGnQ4mlU 1056 Content-Transfer-Encoding: 8bit 1057 Content-ID: 1058 Content-Type: multipart/related;type="application/rlmi+xml"; 1059 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 1061 --tuLLl3lDyPZX0GMr2YOo 1062 Content-Transfer-Encoding: 8bit 1063 Content-ID: 1064 Content-Type: application/rlmi+xml;charset="UTF-8" 1066 1067 1070 1071 1072 1073 1074 1075 1076 1078 --tuLLl3lDyPZX0GMr2YOo 1079 Content-Transfer-Encoding: 8bit 1080 Content-ID: 1081 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1083 1084 1086 1087 1088 open 1089 1090 sip:joe@example.org 1091 1092 1094 --tuLLl3lDyPZX0GMr2YOo 1095 Content-Transfer-Encoding: 8bit 1096 Content-ID: 1097 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1099 1100 1102 1103 1104 closed 1105 1106 1107 1108 --tuLLl3lDyPZX0GMr2YOo-- 1110 --l3WMZaaL8NpQWGnQ4mlU 1111 Content-Transfer-Encoding: 8bit 1112 Content-ID: 1113 Content-Type: application/pkcs-signature 1115 [PKCS #7 signature here] 1117 --l3WMZaaL8NpQWGnQ4mlU-- 1119 12. The Local RLS completes the NOTIFY transaction. 1121 Local RLS -> RLS in example.org 1123 SIP/2.0 200 OK 1124 Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI 1125 From: ;tag=JenZ40P3 1126 To: ;tag=a12eztNf 1127 Call-ID: kBq5XhtZLN@pres.example.com 1128 CSeq: 294444656 NOTIFY 1129 Contact: 1130 Content-Length: 0 1132 13. At this point, the Local RLS decides it has collected enough 1133 additional information to warrant sending a new notification to 1134 the user. Although sending a full notification would be 1135 perfectly acceptable, the RLS decides to send a partial 1136 notification instead. The RLMI document contains only 1137 information for the updated resources, as indicated by setting 1138 the "fullState" parameter to "false". To avoid corrupting the 1139 S/MIME signature on the data received from the RLS in 1140 example.org, the local RLS copies the entire application/signed 1141 body as-is into the notification that it sends. 1143 Local RLS -> Terminal 1145 NOTIFY sip:terminal.example.com SIP/2.0 1146 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1147 Max-Forwards: 70 1148 From: ;tag=zpNctbZq 1149 To: ;tag=ie4hbb8t 1150 Call-ID: cdB34qLToC@terminal.example.com 1151 CSeq: 997935769 NOTIFY 1152 Contact: 1153 Event: presence 1154 Subscription-State: active;expires=7200 1155 Require: eventlist 1156 Content-Type: multipart/related;type="application/rlmi+xml"; 1157 start="<2BEI83@pres.example.com>";boundary="TfZxoxgAvLqgj4wRWPDL" 1158 Content-Length: 2862 1160 --TfZxoxgAvLqgj4wRWPDL 1161 Content-Transfer-Encoding: 8bit 1162 Content-ID: <2BEI83@pres.example.com> 1163 Content-Type: application/rlmi+xml;charset="UTF-8" 1165 1166 1169 1170 1171 1172 1173 1174 1175 1177 --TfZxoxgAvLqgj4wRWPDL 1178 Content-Transfer-Encoding: 8bit 1179 Content-ID: <1KQhyE@pres.example.com> 1180 Content-Type: multipart/signed;protocol="application/pkcs-signature"; 1181 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1183 --l3WMZaaL8NpQWGnQ4mlU 1184 Content-Transfer-Encoding: 8bit 1185 Content-ID: 1186 Content-Type: multipart/related;type="application/rlmi+xml"; 1187 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 1189 --tuLLl3lDyPZX0GMr2YOo 1190 Content-Transfer-Encoding: 8bit 1191 Content-ID: 1192 Content-Type: application/rlmi+xml;charset="UTF-8" 1194 1195 1198 1199 1201 1202 1203 1204 1205 1207 --tuLLl3lDyPZX0GMr2YOo 1208 Content-Transfer-Encoding: 8bit 1209 Content-ID: 1210 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1212 1213 1215 1216 1217 open 1218 1219 sip:joe@example.org 1220 1221 1223 --tuLLl3lDyPZX0GMr2YOo 1224 Content-Transfer-Encoding: 8bit 1225 Content-ID: 1226 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1228 1229 1231 1232 1233 closed 1234 1235 1236 1238 --tuLLl3lDyPZX0GMr2YOo-- 1240 --l3WMZaaL8NpQWGnQ4mlU 1241 Content-Transfer-Encoding: 8bit 1242 Content-ID: 1243 Content-Type: application/pkcs-signature 1245 [PKCS #7 signature here] 1247 --l3WMZaaL8NpQWGnQ4mlU-- 1248 --TfZxoxgAvLqgj4wRWPDL-- 1250 14. The terminal completes the NOTIFY transaction. 1252 Terminal -> Local RLS 1254 SIP/2.0 200 OK 1255 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1256 From: ;tag=zpNctbZq 1257 To: ;tag=ie4hbb8t 1258 Call-ID: cdB34qLToC@terminal.example.com 1259 CSeq: 997935769 NOTIFY 1260 Contact: 1261 Content-Length: 0 1263 7. Security Considerations 1265 Note that the mechanisms for obtaining state information for 1266 resources in a list are generally left to the RLS implementor. Some 1267 of the security issues below are specific to the the circumstance 1268 that a SIP back-end subscription is used for such a purpose. Non-SIP 1269 mechanisms for obtaining state information of resources in a list 1270 will typically have their own security issues associated with doing 1271 so; however, exhaustively enumerating such access methods is not 1272 possible in this document. Implementors using such mechanisms must 1273 analyze their chosen access methods for relevant security issues. 1275 7.1 Authentication 1277 The usage of the RLS does introduce some security considerations. If 1278 back-end subscriptions are required to retrieve resource state 1279 information, the end user is no longer the direct subscriber to the 1280 state of the resource. If the notifier for the resource demands end- 1281 to-end authentication, the RLS will need to be provided appropriate 1282 credentials to access those resources (e.g. shared secrets for 1283 Digest authentication). This requires a certain level of trust 1284 between the user and their RLS. This specification does not describe 1285 any particular means of providing such credentials to the RLS (such 1286 as uploading a shared secret). However, any such upload mechanism 1287 MUST ensure privacy of the key data; using HTTPS [15] to fill out a 1288 form is a reasonable method. 1290 If the notifier for the resource is using a transitive trust model to 1291 validate the subscriber, then this works well with the RLS concept 1292 and back-end subscriptions. The RLS would authenticate the 1293 subscriber, and then MAY use the SIP extensions for network asserted 1294 identity [7][8] to provide an authenticated identity to the notifiers 1295 for the resource. 1297 7.2 Risks of Improper Aggregation 1299 A resource list server typically serves information to multiple 1300 subscribers at once. In many cases, resources may be present in 1301 several lists; additionally, it is quite possible that resource list 1302 servers will have two users subscribe to the same list. 1304 In these cases, misguided RLS implementations may attempt to minimize 1305 network load by maintaining only one back-end subscription to a 1306 resource in a list, and presenting the result of such a subscription 1307 to more than one user. Of course, doing so circumvents any 1308 authorization policy that the notifier for the resource maintains. 1309 It is important to keep in mind that authorization is often much more 1310 than a simple binary "allowed/not allowed" decision; resources may 1311 render very different -- and even conflicting -- resource states, 1312 depending on the identity of the subscribing user. 1314 Implementations MUST NOT attempt to perform this type of optimization 1315 unless adequate access to complete authorizaton policy can be 1316 guaranteed. Note that this is a very difficult problem to solve 1317 correctly. Even in the cases that such access is believed possible, 1318 this mode of operation is NOT RECOMMENDED. 1320 7.3 Signing and Sealing 1322 Implementors should keep in mind that any section of the MIME body 1323 may be signed and/or encrypted as necessary. Resource List Servers 1324 should take care not to modify any MIME bodies they receive from any 1325 back-end subscriptions, and should not generally rely on being able 1326 to read them. 1328 In order to facilitate security, resource list servers SHOULD pass 1329 along indication for support of "multipart/signed" and "multipart/ 1330 encrypted" content types to any SIP back-end subscriptions, if the 1331 subscriber includes them in the initial SUBSCRIBE message. Not doing 1332 so may actually result in resources refusing to divulge state (if 1333 notifier policy requires encryption, but the RLS fails to convey 1334 support), or subscribers discarding valid state (if subscriber policy 1335 requires a signature, but the RLS fails to convey support). 1337 Note that actual implemetation of encryption and signing by the RLS 1338 is not necessary to be able to pass through signed and/or encrypted 1339 bodies. 1341 8. IANA Considerations 1343 8.1 New SIP Option Tag: eventlist 1345 This section defines a new option tag for the registry established by 1346 section 27.1 of RFC 3261[1]. 1348 Option Tag Name: eventlist 1350 Description: Extension to allow subscriptions to lists of resources 1352 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1353 with the RFC number of this document when published]] 1355 8.2 New MIME type for Resource List Meta-Information 1357 MIME Media Type Name: application 1359 MIME subtype name: rlmi+xml 1361 Required parameters: None 1363 Optional parameters: charset 1365 See RFC 3023 [12] for a discussion of the charset parameter on 1366 XML-derived MIME types. Since this MIME type is used exclusively 1367 in SIP, the use of UTF-8 encoding is strongly encouraged. 1369 Encoding considerations: 8-bit text 1371 Security considerations: Security considerations specific to uses of 1372 this this MIME type are discussed in RFC xxxx [[Note to RFC 1373 editor: replace xxxx with the RFC number of this document when 1374 published]]. RFC 1874 [11] and RFC 3023 [12] discuss security 1375 issues common to all uses of XML. 1377 Interoperability considerations: The use of this MIME body is 1378 intended to be generally interoperable. No unique considerations 1379 have been identified. 1381 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1382 with the RFC number of this document when published]] 1384 Applications which use this media type: This media type is used to 1385 convey meta-information for the state of lists of resources within 1386 a Session Initiation Protocol (SIP) subscription. 1388 Additional information: 1390 Magic Number(s): None. 1392 File Extension(s): None. 1394 Macintosh File Type Code(s): None. 1396 Object Identifier(s) or OID(s): None. 1398 Intended usage: Limited Use 1400 Other Information/General Comment: None. 1402 Person to contact for further information: 1404 Name: Adam Roach 1406 E-Mail: adam@dynamicsoft.com 1408 Author/Change Controller: The specification of this MIME type is a 1409 work product of the SIMPLE working group, and was authored by 1410 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1411 change control over its specification. 1413 8.3 URN Sub-Namespace 1415 URI: urn:ietf:params:xml:ns:rlmi 1417 Description: This is the XML namespace URI for XML elements defined 1418 by [RFCXXXX] to describe information about subscriptions when such 1419 subscriptions are aggregated within a single SIP subscription. It 1420 is used in the application/rlmi+xml body type. 1422 Registrant Contact: 1424 Name: Adam Roach 1426 E-Mail: adam@dynamicsoft.com 1428 Author/Change Controller: The specification of this MIME type is a 1429 work product of the SIMPLE working group, and was authored by 1430 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1431 change control over its specification. 1433 XML: 1435 BEGIN 1436 1437 1439 1440 1441 1443 Namespace for SIP Event Resource List 1444 Meta-Information 1445 1446 1447

Namespace for SIP Event Resource List Meta-Information

1448

application/rlmi+xml

1449

See RFCXXXX.

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