idnits 2.17.1 draft-ietf-simple-event-list-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1669. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1661), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 743 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 (August 10, 2004) is 7189 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 1448 == Unused Reference: '3' is defined on line 1503, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1524, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1540, 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-02 == 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. '11') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '12') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '14') (Obsoleted by RFC 9110) Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. B. Roach 2 Internet-Draft J. Rosenberg 3 Expires: February 8, 2005 B. Campbell 4 dynamicsoft 5 August 10, 2004 7 A Session Initiation Protocol (SIP) Event Notification Extension for 8 Resource Lists 9 draft-ietf-simple-event-list-05 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 8, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document presents an extension to the Session Initiation 41 Protocol (SIP)-Specific Event Notification mechanism for subscribing 42 to a homogeneous list of resources. Instead of the subscriber 43 sending a SUBSCRIBE for each resource individually, the subscriber 44 can subscribe to an entire list, and then receive notifications when 45 the state of any of the resources in the list changes. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 52 4. Operation of List Subscriptions . . . . . . . . . . . . . . 6 53 4.1 Negotiation of Support for Resource Lists . . . . . . . . . 6 54 4.2 Subscription Duration . . . . . . . . . . . . . . . . . . . 7 55 4.3 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.4 RLS Processing of SUBSCRIBE Requests . . . . . . . . . . . . 7 57 4.5 RLS Generation of NOTIFY requests . . . . . . . . . . . . . 8 58 4.6 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 9 59 4.7 Handling of Forked Requests . . . . . . . . . . . . . . . . 10 60 4.8 Rate of Notifications . . . . . . . . . . . . . . . . . . . 10 61 5. Using multipart/related to Convey Aggregate State . . . . . 11 62 5.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 12 64 5.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 13 65 5.4 Instance Attributes . . . . . . . . . . . . . . . . . . . . 13 66 5.5 Constructing Coherent Resource State . . . . . . . . . . . . 15 67 5.5.1 Processing Full State Notifications . . . . . . . . . . . . 16 68 5.5.2 Processing Partial State Notifications . . . . . . . . . . . 16 69 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 71 7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 30 72 7.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 30 73 7.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 31 74 7.4 Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . 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 -04 . . . . . . . . . . . . . . . . . . . . . 39 85 A.2 Changes since -03 . . . . . . . . . . . . . . . . . . . . . 39 86 A.3 Changes since -02 . . . . . . . . . . . . . . . . . . . . . 39 87 A.4 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 39 88 A.5 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 40 89 B. Intellectual Property Statement . . . . . . . . . . . . . . 41 90 Full Copyright Statement . . . . . . . . . . . . . . . . . . 42 92 1. Introduction 94 The SIP-specific event notification mechanism [2] allows a user (the 95 subscriber) to request to be notified of changes in the state of a 96 particular resource. This is accomplished by having the subscriber 97 generate a SUBSCRIBE request for the resource, which is processed by 98 a notifier that represents the resource. 100 In many cases, a subscriber has a list of resources they are 101 interested in. Without some aggregating mechanism, this will require 102 the subscriber generate a SUBSCRIBE request for each resource about 103 which they want information. For environments in which bandwidth is 104 limited, such as wireless networks, subscribing to each resource 105 individually is problematic. Some specific problems are: 107 o Doing so generates substantial message traffic, in the form of the 108 initial SUBSCRIBE requests for each resource, and the refreshes of 109 each individual subscription. 111 o The notifier may insist on low refresh intervals, in order to 112 avoid long lived subscription state. This means that the 113 subscriber may need to generate SUBSCRIBE refreshes faster than it 114 would like to, or has the capacity to. 116 o The notifier may generate NOTIFY requests more rapidly than the 117 subscriber desires, causing NOTIFY traffic at a greater volume 118 than is desired by the subscriber. 120 To solve these problems, this specification defines an extension to 121 RFC 3265 [2] that allows for requesting and conveying notifications 122 for lists of resources. A resource list is identified by a URI and 123 it represents a list of zero or more URIs. Each of these URIs is an 124 identifier for an individual resource for which the subscriber wants 125 to receive information. In many cases, the URI will be a SIP URI 126 [1]; however, the use of other schemes (such as pres: [9]) is also 127 foreseen. 129 The notifier for the list is called a "resource list server", or RLS. 130 In order to determine the state of the entire list, the RLS will act 131 as if it has generated a subscription to each resource in the list. 133 The resource list is not restricted to be inside the domain of the 134 subscriber. Similarly, the resources in the list are not constrained 135 to be in the domain of the resource list server. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [5]. 143 The following terms are used throughout the remainder of this 144 document. 146 Back-End Subscription: Any subscription (SIP or otherwise) that an 147 RLS creates to learn of the state of a resource. An RLS will 148 create back-end subscriptions to learn of the state of a resource 149 about which the RLS is not an authority. For back-end 150 subscriptions, RLSes act as a subscriber. 152 List Subscription: A subscription to a resource list. In list 153 subscriptions, RLSes act a the notifier. 155 Resource: A resource is any logical entity that has a state or states 156 that can be subscribed to. Resources are identified by URIs. 158 Resource List: A list of zero or more resources that can have their 159 individual states subscribed to with a single subscription. 161 RLMI: Resource List Meta-Information. RLMI is a document that 162 describes the state of the virtual subscriptions associated with a 163 list subscription. 165 RLS: Resource List Server. RLSes accept subscriptions to resource 166 lists and send notifications to update subscribers of the state of 167 the resources in a resource list. 169 Virtual Subscription: Virtual Subscriptions are a logical construct 170 within an RLS that represent subscriptions to the resources in a 171 resource list. For each list subscription it services, an RLS 172 creates at least one virtual subscription for every resource in 173 the resource list being subscribed to. In some cases, such as 174 when the RLS is not the authority for the state of the resource, 175 this virtual subscription will be associated with a back-end 176 subscription. In other cases, such as when the RLS is the 177 authority for the state of the resource, the virtual subscription 178 will not have a corresponding back-end subscription. 180 3. Overview of Operation 182 This section provides an overview of the typical mode of operation of 183 this extension. It is not normative. 185 When users wish to subscribe to the resource of a list of resources, 186 they can use the mechanisms described in this specification. The 187 first step is creation of a resource list. This resource list is 188 represented by a SIP URI. The list contains a set of URIs, each of 189 which represents a resource for which the subscriber wants to receive 190 information. The resource list can exist in any domain. The list 191 could be manipulated through a web page, through a voice response 192 system, or through some other protocol. The specific means by which 193 the list is created and maintained is outside of the scope of this 194 specification. 196 To learn the resource state of the set of elements on the list, the 197 user sends a single SUBSCRIBE request targeted to the URI of the 198 list. This will be routed to an RLS for that URI. The RLS acts as a 199 notifier, authenticates the subscriber, and accepts the subscription. 201 The RLS may have direct information about some or all of the 202 resources specified by the list. If it does not, it could subscribe 203 to any non-local resources specified by the list resource. 205 Note that subscriptions to non-local resources may or may not be SIP 206 subscriptions; any mechanism for determining such information may be 207 employed. This document uses the term "back-end subscription" to 208 refer to such a subscription, regardless of whether SIP is used to 209 establish and service it. 211 As the state of resources in the list change, the RLS generates 212 notifications to the list subscribers. The RLS can, at its 213 discretion, buffer notifications of resource changes, and send the 214 resource information to the subscriber in batches, rather than 215 individually. This allows the RLS to provide rate limiting for the 216 subscriber. 218 The list notifications contain a body of type multipart/related. The 219 root section of the multipart/related content is an XML document that 220 provides meta-information about each resource present in the list. 221 The remaining sections contain the actual state information for each 222 resource. 224 4. Operation of List Subscriptions 226 The event list extension acts, in many ways, like an event template 227 package. In particular, any single list subscription must be 228 homogeneous with respect to the underlying event package. In other 229 words, a single list subscription can apply only one event package to 230 all of the resources in the resource list. 232 It is worth noting that it is perfectly valid, for an RLS to allow 233 multiple subscriptions to the same list to use differing event 234 packages. 236 The key difference between a list subscription and templates in 237 general is that support for list subscriptions indicates support for 238 arbitrary nesting of list subscriptions. In other words, elements 239 within the list may be atomic elements, or they may be lists 240 themselves. 242 The consequence of this is that subscription to a URI that represents 243 a list actually results in a several virtual subscriptions to a tree 244 of resources. The leaf nodes of this tree are virtual subscriptions 245 of the event type given in the "Event" header field; all other nodes 246 in the tree are list subscriptions that are serviced as described in 247 this section and its subsections. 249 It is important to keep in mind that these virtual subscriptions are 250 not literal SIP subscriptions (although they may result in SIP 251 subscriptions, depending on the RLS implementation). 253 4.1 Negotiation of Support for Resource Lists 255 This specification uses the SIP option tag mechanism for negotiating 256 support for the extension defined herein. Refer to RFC3261 [1] for 257 the normative description of processing of the "Supported" and 258 "Require" header fields and the 421 (Extension Required) response 259 code. 261 A non-normative description of the implications of the use of 262 option tags follows. 264 Any client that supports the event list extension will include an 265 option tag of "eventlist" in a "Supported" header field of every 266 SUBSCRIBE message for a subscription for which it is willing to 267 process a list. If the subscription is made to a URI that 268 represents a list, the RLS will include "eventlist" in a "Require" 269 header field of the response to the SUBSCRIBE, and in all NOTIFY 270 messages within that subscription. 272 Use of "Require: eventlist" in NOTIFY messages is applied by the 273 notifier to satisfy the RFC3261 requirement that a UAC MUST insert 274 a Require header field into a request if the UAC wishes to insist 275 that a UAS understand an extension in order to process the 276 request. Because the NOTIFY would not be usable without applying 277 the eventlist option, the notifier is obligated to include it. 279 Including "eventlist" in a "Require" header field in a SUBSCRIBE 280 request serves no purpose, and is consequently NOT RECOMMENDED. 282 There is nothing in a SIP URI which indicates whether it represents a 283 list of resources or a single resource. Therefore, if a subscriber 284 sends a request to a URI that represents a list resource, but does 285 not include a Supported header field listing the "eventlist" token, 286 the notifier will typically return a 421 (Extension Required) 287 response code. RFC 3261 [1] advises servers to avoid returning a 288 421, and instead, attempt to process the request without the 289 extension. However, in this case, the URI fundamentally represents a 290 list resource, and therefore, the subscription cannot proceed without 291 this extension. 293 4.2 Subscription Duration 295 Since the primary benefit of the resource list server is to reduce 296 the overall messaging volume to a subscriber, it is RECOMMENDED that 297 the subscription duration to a list be reasonably long. The default, 298 when no duration is specified, is taken from the underlying event 299 package. Of course, the standard techniques [2] can be used to 300 increase or reduce this amount. 302 4.3 NOTIFY Bodies 304 An implementation compliant to this specification MUST support the 305 multipart/related and application/rlmi+xml MIME types. These types 306 MUST be included in an Accept header sent in SUBSCRIBE message, in 307 addition to any other types supported by the client (including any 308 types required by the event package being used). 310 4.4 RLS Processing of SUBSCRIBE Requests 312 Once the subscriber is authenticated, the RLS performs authorization 313 per its local policy. In many cases, each resource list is 314 associated with a particular user (the one who created it and manages 315 the set of elements in it), and only that user will be allowed to 316 subscribe. Of course, this mode of operation is not inherent in the 317 use of resource lists, and an RLS can use any authorization policy it 318 chooses. 320 4.5 RLS Generation of NOTIFY requests 322 This specification leaves the choice about how and when to generate 323 NOTIFY requests at the discretion of the implementor. One of the 324 value propositions of the RLS is the means by which it aggregates, 325 rate limits, or optimizes the way in which notifications are 326 generated. As a baseline behavior, the RLS MAY generate a NOTIFY to 327 the RLS subscriber whenever the state of any resource on the list 328 changes. 330 See Section 5 for a detailed definition of the syntax used to convey 331 the state of resource lists. For the purposes of the following 332 discussion, it is important to know that the overall list contains 333 zero or more resources, and that the resources contains zero or more 334 instances. Each instance has a state associated with it (pending, 335 active, or terminating), representing the state of the virtual 336 subscription. 338 Notifications contain a multipart document, the first part of which 339 always contains meta-information about the list (e.g. membership, 340 state of the virtual subscription to the resource). Remaining parts 341 are used to convey the actual state of the resources listed in the 342 meta-information. 344 The "state" attribute of each instance of a resource in the meta- 345 information is set according to the state of the virtual 346 subscription. The meanings of the "state" attribute are described in 347 RFC 3265 [2]. 349 If an instance of a resource was previously reported to the 350 subscriber but is no longer available (i.e. the virtual subscription 351 to that instance has been terminated), the resource list server 352 SHOULD include that resource instance in the meta-information in the 353 first NOTIFY message sent to the subscriber following the instance's 354 unavailability. The RLS MAY continue to do so for future 355 notifications. 357 When sending information for a terminated resource instance, the RLS 358 indicates a state of "terminated" and an appropriate reason value. 359 Valid reason values and their meanings are described in RFC 3265 [2]. 360 If the RLS will attempt to recover the resource state again at some 361 point in the future (e.g. when the reason in the meta-information is 362 "probation"), then the instance of the resource SHOULD remain in the 363 meta-information until the instance state is available, or until the 364 RLS gives up on making such state available. 366 When the first SUBSCRIBE message for a particular subscription is 367 received by a RLS, the RLS will often not know state information for 368 all of the resources specified by the resource list. For any 369 resource for which state information is not known, the corresponding 370 "uri" attribute will be set appropriately, and no elements 371 will be present for the resource. 373 For an initial notification, sections corresponding to resources for 374 which the RLS does have state will be populated with appropriate data 375 (subject, of course, to local policy decisions). This will often 376 occur if the resource list server is co-located with the server for 377 one or more of the resources specified on the list. 379 Immediate notifications triggered as a result of subsequent SUBSCRIBE 380 messages SHOULD include an RLMI document with full state indicated. 381 The RLS SHOULD also include state information for all resources in 382 the list for which the RLS has state, subject to policy restrictions. 383 This allows the subscriber to refresh their state, and to recover 384 from lost notifications. 386 4.6 Subscriber Processing of NOTIFY Requests 388 Notifications for a resource list can convey information about a 389 subset of the list elements. This means that an explicit algorithm 390 needs to be defined in order to construct coherent and consistent 391 state. 393 The XML document present in the root of the multipart/related 394 document contains a element for some or all of the 395 resources in the list. Each element contains a URI which 396 uniquely identifies the resource to which that section corresponds. 397 When a NOTIFY arrives, it can contain full or partial state (as 398 indicated by the "fullState" attribute of the top-level 399 element). If full state is indicated, then the recipient replaces 400 all state associated with the list with the entities in the NOTIFY 401 body. If full state is not indicated, the recipient of the NOTIFY 402 updates information for each identified resource. Information for 403 any resources that are not identified in the NOTIFY are not changed, 404 even if they were indicated in previous NOTIFY messages. See Section 405 5.5 for more information. 407 When full state is indicated, note that it applies only to the 408 RLMI document in which it occurs. In particular, one of the 409 elements in the document may in turn refer to another 410 list of resources. Any such sub-lists will be detailed in their 411 own RLMI documents, which may or may not have full state 412 indicated. 414 Further note that underlying event package may have its own rules 415 for compositing partial state notification. When processing data 416 related to those packages, their rules apply (i.e. the fact that 417 they were reported as part of a list does not change their partial 418 notification semantics). 420 Finally, note that a consequence of the way in which resource list 421 subscriptions work is that polling of resource state may not be 422 particularly useful. While such polls will retrieve the resource 423 list, they will not necessarily contain state for some or all of 424 the resources on the list. 426 4.7 Handling of Forked Requests 428 Forking makes little sense with subscriptions to event lists, since 429 the whole idea is a centralization of the source of notifications. 430 Therefore, a subscriber to a list MUST NOT install multiple 431 subscriptions when the initial request is forked. If multiple 432 responses are received, they are handled using the techniques 433 described in section 4.4.9 of RFC 3265[2]. 435 4.8 Rate of Notifications 437 One potential role of the RLS is to perform rate limitations on 438 behalf of the subscriber. As such, this specification does not 439 mandate any particular rate limitation, and rather leaves that to the 440 discretion of the implementation. 442 5. Using multipart/related to Convey Aggregate State 444 In order to convey the state of multiple resources, the list 445 extension uses the "multipart/related" mime type. The syntax for 446 multipart/related is defined in "The MIME Multipart/Related Content- 447 type" [4]. 449 5.1 XML Syntax 451 The root document of the multipart/related body MUST be a Resource 452 List Meta-Information (RLMI) document. It is of type "application/ 453 rlmi+xml". This document contains the meta-information for the 454 resources contained in the notification. The schema for this XML 455 document is given below. 457 458 462 463 464 465 467 468 469 471 473 474 475 476 477 478 479 480 481 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 503 An example of a document formatted using this schema follows. 505 506 509 510 512 513 514 516 517 518 519 520 521 522 523 525 5.2 List Attributes 527 The element present in a list notification MUST contain three 528 attributes. 530 The first mandatory attribute is "uri", which contains the uri 531 that corresponds to the list. Typically, this is the URI to which 532 the SUBSCRIBE request was sent. 534 The second mandatory attribute is "version", which contains a 535 number from 0 to 2^32-1. This version number MUST be 0 for the first 536 NOTIFY message sent within a subscription, and MUST increase by 537 exactly one for each subsequent NOTIFY sent within a subscription. 539 The third mandatory attribute is "fullState". The "fullState" 540 attribute indicates whether the NOTIFY message contains information 541 for every resource in the list. If it does, the value of the 542 attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The 543 first NOTIFY sent in a subscription MUST contain full state, as must 544 the first NOTIFY sent after receipt of a SUBSCRIBE request for the 545 subscription. 547 The optional "name" attribute contains a human readable description 548 or name for the resource list. This attribute is somewhat analogous 549 to the "Display Name" present in the SIP name-addr element. 551 Finally, elements MAY contain a "cid" attribute. If present, 552 the "cid" attribute identifies a section within the multipart/related 553 body that contains aggregate state information for the resources 554 contained in the list. The definition of such aggregate information 555 is outside the scope of this document, and will be defined on a per- 556 package basis as needed. The cid attribute is the Content-ID for the 557 corresponding section in the multipart body. 559 The cid attribute MUST refer only to top-level parts of the 560 multipart/related document for which the RLMI document in which it 561 appears is the root. See Section 5.4 for an example. 563 5.3 Resource Attributes 565 The resource list contains one element for each resource 566 being reported in the notification. These resource elements contain 567 attributes that identify meta-data associated with each resource. 569 The "uri" attribute identifies the resource to which the 570 element corresponds. Typically, this will be a SIP URI which, if 571 subscribed to, would return the state of the resource. This 572 attribute MUST be present. 574 The optional "name" attribute can contain a human readable 575 description or name for the resource. This attribute is somewhat 576 analogous to the "Display Name" present in the SIP name-addr element. 578 5.4 Instance Attributes 580 Each resource element contains zero or more instance elements. These 581 instance elements are used to represent a single notifier for the 582 resource. For event packages that allow forking, multiple virtual 583 subscriptions may exist for a given resource. Multiple virtual 584 subscriptions are represented as multiple instance elements in the 585 corresponding resource element. For subscriptions in which forking 586 does not occur, at most one instance will be present for a given 587 resource. 589 The "id" attribute contains an opaque string used to uniquely 590 identify the instance of the resource. The "id" attribute is unique 591 only within the context of a resource. Construction of this string 592 is an implementation decision. Any mechanism for generating this 593 string is valid, as long as uniqueness within the resource is 594 assured. 596 The "state" attribute contains the subscription state for the 597 identified instance of the resource. This attribute contains one of 598 the values "active", "pending", or "terminated". The meanings for 599 these values are as defined for the "Subscription-State" header field 600 in RFC 3265 [2]. 602 If the "state" attribute indicates "terminated", then a "reason" 603 attribute MUST also be present. This "reason" attribute has the same 604 values and meanings as given for the "reason" parameter on the 605 "Subscription-State" header field in RFC 3265 [2]. Note that the 606 "reason" attribute is included for informational purposes; the list 607 subscriber is not expected to take any automated actions based on the 608 reason value. 610 Finally, the "cid" attribute, which MUST be present if the "state" 611 attribute is "active", identifies the section within the multipart/ 612 related body that contains the actual resource state. This state is 613 expressed in the content type defined by the event package for 614 conveying state. The cid attribute is the Content-ID for the 615 corresponding section in the multipart body. 617 The cid attribute MUST refer only to top-level parts of the 618 multipart/related document for which the RLMI document in which it 619 appears is the root. 621 For example, consider a multipart/related document containing 622 three parts; we'll label these parts A, B, and C. Part A is type 623 application/rlmi+xml, part B is type multipart/related, and part C 624 is type application/cpim-pidf+xml. Part B is in turn a document 625 containing three parts: D, E, and F. Part D is of type 626 application/rlmi+xml, and parts E and F are of type application/ 627 cpim-pidf+xml. 629 +-------------------------------------------+ 630 | Top Level Document: multipart/related | 631 | | 632 | +---------------------------------------+ | 633 | | Part A: application/rlmi+xml | | 634 | +---------------------------------------+ | 635 | | Part B: multipart/related | | 636 | | | | 637 | | +-----------------------------------+ | | 638 | | | Part D: application/rlmi+xml | | | 639 | | +-----------------------------------+ | | 640 | | | Part E: application/cpim-pidf+xml | | | 641 | | +-----------------------------------+ | | 642 | | | Part F: application/cpim-pidf+xml | | | 643 | | +-----------------------------------+ | | 644 | | | | 645 | +---------------------------------------+ | 646 | | Part C: application/cpim-pidf+xml | | 647 | +---------------------------------------+ | 648 | | 649 +-------------------------------------------+ 651 Any "cid" attributes in document A must refer only to parts B or 652 C. Referring to parts D, E, or F would be illegal. Similarly, 653 Any "cid" attributes in document D must refer only to parts E or 654 F. Referring to any other parts would be illegal. 656 Also note that the subscription durations of any back-end 657 subscriptions are not propagated into the meta-information state 658 in any way. 660 5.5 Constructing Coherent Resource State 662 The resource list subscriber maintains a table for each resource 663 list. The table contains a row for each resource in the resource 664 list. Each row is indexed by the URI for that resource. That URI is 665 obtained from the "uri" attribute on each element. The 666 contents of each row contain the state of that resource as conveyed 667 in the resource document. 669 For resources that provide versioning information (which is mandated 670 by [2] for any formats that allow partial notification), each row 671 also contains a resource state version number. The version number of 672 the row is initialized with the version specified in the first 673 document received, as defined by the corresponding event package. 674 This value is used when comparing versions of partial notifications 675 for a resource. 677 The processing of the resource list notification depends on whether 678 it contains full or partial state. 680 5.5.1 Processing Full State Notifications 682 If a notification contains full state, indicated by the 683 attribute "fullState" set to "true", the notification is used to 684 update the table. A check is first made to ensure that the "version" 685 attribute of the attribute in the received message is greater 686 than the local version number. If not, the received document is 687 discarded without any further processing. Otherwise, the contents of 688 the resource-list table are flushed, and repopulated from the 689 contents of the document. A new row in the table is created for each 690 "resource" element. 692 5.5.2 Processing Partial State Notifications 694 If a notification contains partial state, indicated by the 695 attribute "fullState" set to "false", a check is made to ensure that 696 no list notifications have been lost. The value of the local version 697 number (the "version" attribute of the element) is compared to 698 the version number of the new document. 700 o If the value in the new document is exactly one higher than the 701 local version number, the local version number is increased by 702 one, and the document is processed, as described below. 704 o If the version in the document is more than one higher than the 705 local version number, the local version number is set to the value 706 in the new document, and the document is processed as described 707 below. The list subscriber SHOULD also generate a refresh request 708 to trigger a full state notification. 710 o If the version in the document is less than or equal to the local 711 version, the document is discarded without any further processing. 713 For each resource listed in the document, the subscriber checks to 714 see whether a row exists for that resource. This check is done by 715 comparing the Resource-URI value with the URI associated with the 716 row. If the resource doesn't exist in the table, a row is added, and 717 its state is set to the information from that "resource" element. If 718 the resource does exist, its state is updated to be the information 719 from that "resource" element, as described in the definition of the 720 event package. If a row is updated or created such that its state is 721 now "terminated," that entry MAY be removed from the table at any 722 time. 724 6. Example 726 This section gives an example call flow. It is not normative. If a 727 conflict arises between this call flow and the normative behavior 728 described in this or any other document, the normative descriptions 729 are to be followed. 731 In this particular example, we request a subscription to a nested 732 presence list. The subscriber's address-of-record is 733 "sip:adam@example.com", and the name of the nested list resource that 734 we are subscribing to is called "sip:adam-buddies@pres.example.com". 735 The underlying event package is "presence", described by [6]. 737 In this example, the RLS has information to service some of the 738 resources on the list, but must consult other servers to retrieve 739 information for others. The implementation of the RLS in this 740 example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such 741 information. 743 Terminal pres.example.com pres.example.org 744 | | pres.example.net | 745 1 |---SUBSCRIBE--->| | | 746 2 |<-----200-------| | | 747 3 |<----NOTIFY-----| | | 748 4 |------200------>| | | 749 5 | |---SUBSCRIBE--->| | 750 6 | |<-----200-------| | 751 7 | |<----NOTIFY-----| | 752 8 | |------200------>| | 753 9 | |------------SUBSCRIBE----------->| 754 10| |<--------------200---------------| 755 11| |<-------------NOTIFY-------------| 756 12| |---------------200-------------->| 757 13|<----NOTIFY-----| | | 758 14|------200------>| | | 760 1. We initiate the subscription by sending a SUBSCRIBE message to 761 our local RLS. (There is no reason that the RLS we contact has 762 to be in our domain, of course). Note that we must advertise 763 support for application/rlmi+xml and multipart/related because 764 we support the eventlist extension, and we must advertise 765 application/cpim-pidf+xml because we are requesting a 766 subscription to presence. 768 Terminal -> Local RLS 770 SUBSCRIBE sip:adam-buddies@pres.example.com SIP/2.0 771 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 772 Max-Forwards: 70 773 To: 774 From: ;tag=ie4hbb8t 775 Call-ID: cdB34qLToC@terminal.example.com 776 CSeq: 322723822 SUBSCRIBE 777 Contact: 778 Event: presence 779 Expires: 7200 780 Supported: eventlist 781 Accept: application/cpim-pidf+xml 782 Accept: application/rlmi+xml 783 Accept: multipart/related 784 Accept: multipart/signed 785 Accept: multipart/encrypted 786 Content-Length: 0 788 2. The Local RLS completes the SUBSCRIBE transaction. Note that 789 authentication and authorization would normally take place at 790 this point in the call flow. Those steps are omitted for 791 brevity. 793 Local RLS -> Terminal 795 SIP/2.0 200 OK 796 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 797 To: ;tag=zpNctbZq 798 From: ;tag=ie4hbb8t 799 Call-ID: cdB34qLToC@terminal.example.com 800 CSeq: 322723822 SUBSCRIBE 801 Contact: 802 Expires: 7200 803 Require: eventlist 804 Content-Length: 0 806 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY 807 immediately upon accepting the subscription. In this example, 808 we are assuming that the local RLS is also an authority for 809 presence information for the users in the "example.com" domain. 810 The NOTIFY contains an RLMI document describing the entire buddy 811 list (initial notifies require full state), as well as presence 812 information for the users about which it already knows. Note 813 that, since the RLS has not yet retrieved information for some 814 of the entries on the list, those elements contain no 815 elements. 817 Local RLS -> Terminal 819 NOTIFY sip:terminal.example.com SIP/2.0 820 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 821 Max-Forwards: 70 822 From: ;tag=zpNctbZq 823 To: ;tag=ie4hbb8t 824 Call-ID: cdB34qLToC@terminal.example.com 825 CSeq: 997935768 NOTIFY 826 Contact: 827 Event: presence 828 Subscription-State: active;expires=7200 829 Require: eventlist 830 Content-Type: multipart/related;type="application/rlmi+xml"; 831 start="";boundary="50UBfW7LSCVLtggUPe5z" 832 Content-Length: 1560 834 --50UBfW7LSCVLtggUPe5z 835 Content-Transfer-Encoding: binary 836 Content-ID: 837 Content-Type: application/rlmi+xml;charset="UTF-8" 839 840 843 844 846 847 848 850 851 852 854 856 --50UBfW7LSCVLtggUPe5z 857 Content-Transfer-Encoding: binary 858 Content-ID: 859 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 860 861 863 864 865 open 866 867 sip:bob@example.com 868 869 871 --50UBfW7LSCVLtggUPe5z 872 Content-Transfer-Encoding: binary 873 Content-ID: 874 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 876 877 879 880 881 closed 882 883 884 886 --50UBfW7LSCVLtggUPe5z-- 888 4. The terminal completes the transaction. 890 Terminal -> Local RLS 892 SIP/2.0 200 OK 893 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 894 From: ;tag=zpNctbZq 895 To: ;tag=ie4hbb8t 896 Call-ID: cdB34qLToC@terminal.example.com 897 CSeq: 997935768 NOTIFY 898 Contact: 899 Content-Length: 0 901 5. In order to service the subscription, the local RLS subscribes 902 to the state of the resources. In this step, the RLS attempts 903 to subscribe to the presence state of the resource 904 "sip:ed@example.net". Since the local RLS knows how to receive 905 notifications for list subscriptions, it includes the 906 "Supported: eventlist" header field in its request. Although 907 the linkage between this subscription and the one sent by the 908 terminal is left up to the application, this message 909 demonstrates some reasonable behavior by including "Accept" 910 header fields for all of the body types it knows the subscriber 911 (Terminal) supports. This is safe to do, since the local RLS 912 will only pass these formats through to the subscriber, and does 913 not need to actually understand them. 915 Local RLS -> Presence Server in example.net 917 SUBSCRIBE sip:ed@example.net SIP/2.0 918 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 919 Max-Forwards: 70 920 To: 921 From: ;tag=aM5icQu9 922 Call-ID: Ugwz5ARxNw@pres.example.com 923 CSeq: 870936068 SUBSCRIBE 924 Contact: 925 Event: presence 926 Expires: 3600 927 Supported: eventlist 928 Accept: application/cpim-pidf+xml 929 Accept: application/rlmi+xml 930 Accept: multipart/related 931 Accept: multipart/signed 932 Accept: multipart/encrypted 933 Content-Length: 0 935 6. The Presence Server in example.net completes the SUBSCRIBE 936 transaction. Note that authentication would normally take place 937 at this point in the call flow. Those steps are omitted for 938 brevity. 940 Presence Server in example.net -> Local RLS 942 SIP/2.0 200 OK 943 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 944 To: ;tag=e45TmHTh 945 From: ;tag=aM5icQu9 946 Call-ID: Ugwz5ARxNw@pres.example.com 947 CSeq: 870936068 SUBSCRIBE 948 Contact: 949 Expires: 3600 950 Content-Length: 0 952 7. In this example, we assume that the server at example.net 953 doesn't have enough authorization information to reject or 954 accept our subscription. The initial notify, therefore, 955 contains a "Subscription-State" of "pending". Presumably, the 956 party responsible for accepting or denying authorization for the 957 resource is notified of this change; however, those steps are 958 not included in this call flow for brevity. 960 Presence Server in example.net -> Local RLS 962 NOTIFY sip:pres.example.com SIP/2.0 963 Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW 964 Max-Forwards: 70 965 From: ;tag=e45TmHTh 966 To: ;tag=aM5icQu9 967 Call-ID: Ugwz5ARxNw@pres.example.com 968 CSeq: 1002640632 NOTIFY 969 Contact: 970 Subscription-State: pending;expires=3600 971 Event: presence 972 Require: eventlist 973 Content-Length: 0 975 8. The local RLS completes the NOTIFY transaction. Note that, at 976 this point, the Local RLS has new information to report to the 977 subscriber. Whether it chooses to report the information 978 immediately or spool it up for later delivery is completely up 979 to the application. For this example, we assume that the RLS 980 will wait for a short period of time before doing so, in order 981 to allow the subscriptions it sent out sufficient time to 982 provide useful data. 984 Local RLS -> Presence Server in example.net 986 SIP/2.0 200 OK 987 Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW 988 From: ;tag=e45TmHTh 989 To: ;tag=aM5icQu9 990 Call-ID: Ugwz5ARxNw@pres.example.com 991 CSeq: 1002640632 NOTIFY 992 Contact: 993 Content-Length: 0 995 9. The Local RLS subscribes to the state of the other non-local 996 resource. 998 Local RLS -> RLS in example.org 1000 SUBSCRIBE sip:adam-friends@example.org SIP/2.0 1001 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 1002 Max-Forwards: 70 1003 To: 1004 From: ;tag=a12eztNf 1005 Call-ID: kBq5XhtZLN@pres.example.com 1006 CSeq: 980774491 SUBSCRIBE 1007 Contact: 1008 Event: presence 1009 Expires: 3600 1010 Supported: eventlist 1011 Accept: application/cpim-pidf+xml 1012 Accept: application/rlmi+xml 1013 Accept: multipart/related 1014 Accept: multipart/signed 1015 Accept: multipart/encrypted 1016 Content-Length: 0 1018 10. The RLS in example.org completes the SUBSCRIBE transaction. 1019 Note that authentication and would normally take place at this 1020 point in the call flow. Those steps are omitted for brevity. 1022 RLS in example.org -> Local RLS 1024 SIP/2.0 200 OK 1025 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 1026 To: ;tag=JenZ40P3 1027 From: ;tag=a12eztNf 1028 Call-ID: kBq5XhtZLN@pres.example.com 1029 CSeq: 980774491 SUBSCRIBE 1030 Contact: 1031 Expires: 3600 1032 Content-Length: 0 1034 11. In this example, we are assuming that the RLS in example.org is 1035 also an authority for presence information for the users in the 1036 "example.org" domain. The NOTIFY contains an RLMI document 1037 describing the contained buddy list, as well as presence 1038 information for those users. In this particular case, the RLS 1039 in example.org has chosen to sign [12] the body of the NOTIFY 1040 message. As described in RFC 2633, signing is performed by 1041 creating a multipart/signed document which has two parts. The 1042 first part is the document to be signed (in this example, the 1043 multipart/related document that describes the list resource 1044 states), while the second part is the actual signature. 1046 RLS in example.org -> Local RLS 1048 NOTIFY sip:pres.example.com SIP/2.0 1049 Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI 1050 Max-Forwards: 70 1051 From: ;tag=JenZ40P3 1052 To: ;tag=a12eztNf 1053 Call-ID: kBq5XhtZLN@pres.example.com 1054 CSeq: 294444656 NOTIFY 1055 Contact: 1056 Event: presence 1057 Subscription-State: active;expires=3600 1058 Require: eventlist 1059 Content-Type: multipart/signed; 1060 protocol="application/pkcs7-signature"; 1061 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1062 Content-Length: 2038 1064 --l3WMZaaL8NpQWGnQ4mlU 1065 Content-Transfer-Encoding: binary 1066 Content-ID: 1067 Content-Type: multipart/related;type="application/rlmi+xml"; 1068 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 1070 --tuLLl3lDyPZX0GMr2YOo 1071 Content-Transfer-Encoding: binary 1072 Content-ID: 1073 Content-Type: application/rlmi+xml;charset="UTF-8" 1075 1076 1079 1080 1081 1082 1083 1084 1085 1087 --tuLLl3lDyPZX0GMr2YOo 1088 Content-Transfer-Encoding: binary 1089 Content-ID: 1090 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1092 1093 1095 1096 1097 open 1098 1099 sip:joe@example.org 1100 1101 1103 --tuLLl3lDyPZX0GMr2YOo 1104 Content-Transfer-Encoding: binary 1105 Content-ID: 1106 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1108 1109 1111 1112 1113 closed 1114 1115 1117 1119 --tuLLl3lDyPZX0GMr2YOo-- 1121 --l3WMZaaL8NpQWGnQ4mlU 1122 Content-Transfer-Encoding: binary 1123 Content-ID: 1124 Content-Type: application/pkcs7-signature 1126 [PKCS #7 signature here] 1128 --l3WMZaaL8NpQWGnQ4mlU-- 1130 12. The Local RLS completes the NOTIFY transaction. 1132 Local RLS -> RLS in example.org 1134 SIP/2.0 200 OK 1135 Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI 1136 From: ;tag=JenZ40P3 1137 To: ;tag=a12eztNf 1138 Call-ID: kBq5XhtZLN@pres.example.com 1139 CSeq: 294444656 NOTIFY 1140 Contact: 1141 Content-Length: 0 1143 13. At this point, the Local RLS decides it has collected enough 1144 additional information to warrant sending a new notification to 1145 the user. Although sending a full notification would be 1146 perfectly acceptable, the RLS decides to send a partial 1147 notification instead. The RLMI document contains only 1148 information for the updated resources, as indicated by setting 1149 the "fullState" parameter to "false". To avoid corrupting the 1150 S/MIME signature on the data received from the RLS in 1151 example.org, the local RLS copies the entire application/signed 1152 body as-is into the notification that it sends. 1154 Local RLS -> Terminal 1156 NOTIFY sip:terminal.example.com SIP/2.0 1157 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1158 Max-Forwards: 70 1159 From: ;tag=zpNctbZq 1160 To: ;tag=ie4hbb8t 1161 Call-ID: cdB34qLToC@terminal.example.com 1162 CSeq: 997935769 NOTIFY 1163 Contact: 1164 Event: presence 1165 Subscription-State: active;expires=7200 1166 Require: eventlist 1167 Content-Type: multipart/related;type="application/rlmi+xml"; 1168 start="<2BEI83@pres.example.com>";boundary="TfZxoxgAvLqgj4wRWPDL" 1169 Content-Length: 2862 1171 --TfZxoxgAvLqgj4wRWPDL 1172 Content-Transfer-Encoding: binary 1173 Content-ID: <2BEI83@pres.example.com> 1174 Content-Type: application/rlmi+xml;charset="UTF-8" 1176 1177 1180 1181 1182 1183 1185 1187 1188 1190 --TfZxoxgAvLqgj4wRWPDL 1191 Content-Transfer-Encoding: binary 1192 Content-ID: <1KQhyE@pres.example.com> 1193 Content-Type: multipart/signed; 1194 protocol="application/pkcs7-signature"; 1195 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1197 --l3WMZaaL8NpQWGnQ4mlU 1198 Content-Transfer-Encoding: binary 1199 Content-ID: 1200 Content-Type: multipart/related;type="application/rlmi+xml"; 1201 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 1203 --tuLLl3lDyPZX0GMr2YOo 1204 Content-Transfer-Encoding: binary 1205 Content-ID: 1206 Content-Type: application/rlmi+xml;charset="UTF-8" 1208 1209 1212 1213 1214 1215 1216 1217 1218 1220 --tuLLl3lDyPZX0GMr2YOo 1221 Content-Transfer-Encoding: binary 1222 Content-ID: 1223 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1225 1226 1228 1229 1230 open 1231 1232 sip:joe@example.org 1233 1234 1236 --tuLLl3lDyPZX0GMr2YOo 1237 Content-Transfer-Encoding: binary 1238 Content-ID: 1239 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1241 1242 1244 1245 1246 closed 1247 1248 1249 1251 --tuLLl3lDyPZX0GMr2YOo-- 1253 --l3WMZaaL8NpQWGnQ4mlU 1254 Content-Transfer-Encoding: binary 1255 Content-ID: 1256 Content-Type: application/pkcs7-signature 1258 [PKCS #7 signature here] 1260 --l3WMZaaL8NpQWGnQ4mlU-- 1262 --TfZxoxgAvLqgj4wRWPDL-- 1264 14. The terminal completes the NOTIFY transaction. 1266 Terminal -> Local RLS 1268 SIP/2.0 200 OK 1269 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1270 From: ;tag=zpNctbZq 1271 To: ;tag=ie4hbb8t 1272 Call-ID: cdB34qLToC@terminal.example.com 1273 CSeq: 997935769 NOTIFY 1274 Contact: 1275 Content-Length: 0 1277 7. Security Considerations 1279 Note that the mechanisms for obtaining state information for 1280 resources in a list are generally left to the RLS implementor. Some 1281 of the security issues below are specific to the the circumstance 1282 that a SIP back-end subscription is used for such a purpose. Non-SIP 1283 mechanisms for obtaining state information of resources in a list 1284 will typically have their own security issues associated with doing 1285 so; however, exhaustively enumerating such access methods is not 1286 possible in this document. Implementors using such mechanisms must 1287 analyze their chosen access methods for relevant security issues. 1289 7.1 Authentication 1291 If back-end subscriptions are required to retrieve resource state 1292 information, the end user is no longer the direct subscriber to the 1293 state of the resource. If the notifier for the resource demands end- 1294 to-end authentication, the RLS will need to be provided appropriate 1295 credentials to access those resources (e.g. shared secrets for 1296 Digest authentication). This requires a certain level of trust 1297 between the user and their RLS. This specification does not describe 1298 any particular means of providing such credentials to the RLS (such 1299 as uploading a shared secret). However, any such upload mechanism 1300 MUST ensure privacy of the key data; using HTTPS [14] to fill out a 1301 form is a reasonable method. 1303 If the notifier for the resource is using a transitive trust model to 1304 validate the subscriber, then this works well with the RLS concept 1305 and back-end subscriptions. The RLS would authenticate the 1306 subscriber, and then MAY use the SIP extensions for authenticated 1307 identity assertion [7] to provide an authenticated identity to the 1308 notifiers for the resource. 1310 7.2 Risks of Improper Aggregation 1312 A resource list server typically serves information to multiple 1313 subscribers at once. In many cases, resources may be present in 1314 several lists; additionally, it is quite possible that resource list 1315 servers will have two users subscribe to the same list. 1317 In these cases, misguided RLS implementations may attempt to minimize 1318 network load by maintaining only one back-end subscription to a 1319 resource in a list, and presenting the result of such a subscription 1320 to more than one user. Of course, doing so circumvents any 1321 authorization policy that the notifier for the resource maintains. 1322 It is important to keep in mind that authorization is often much more 1323 than a simple binary "allowed/not allowed" decision; resources may 1324 render very different -- and even conflicting -- resource states, 1325 depending on the identity of the subscribing user. 1327 Implementations MUST NOT attempt to perform this type of optimization 1328 unless adequate access to complete authorization policy can be 1329 guaranteed. Note that this is a very difficult problem to solve 1330 correctly. Even in the cases that such access is believed possible, 1331 this mode of operation is NOT RECOMMENDED. 1333 7.3 Signing and Sealing 1335 Implementors should keep in mind that any section of the MIME body 1336 may be signed and/or encrypted as necessary. Resource List Servers 1337 should take care not to modify any MIME bodies they receive from any 1338 back-end subscriptions, and should not generally rely on being able 1339 to read them. 1341 In order to facilitate security, resource list servers SHOULD pass 1342 along indication for support of "multipart/signed" and "multipart/ 1343 encrypted" content types to any SIP back-end subscriptions, if the 1344 subscriber includes them in the initial SUBSCRIBE message. Not doing 1345 so may actually result in resources refusing to divulge state (if 1346 notifier policy requires encryption, but the RLS fails to convey 1347 support), or subscribers discarding valid state (if subscriber policy 1348 requires a signature, but the RLS fails to convey support). 1350 Note that actual implementation of encryption and signing by the RLS 1351 is not necessary to be able to pass through signed and/or encrypted 1352 bodies. 1354 7.4 Infinite Loops 1356 One risk introduced by the ability to nest resource lists is the 1357 possibility of creating lists which ultimately contain themselves as 1358 a sub-list. Detection and handling of such a case is trivial when 1359 the RLS services all of the virtual subscriptions internally. When 1360 back-end subscriptions are created to service virtual subscriptions, 1361 however, detection of such situations becomes a more difficult 1362 problem. 1364 Implementors of RLSes that create back-end subscriptions MUST 1365 implement safeguards to prevent such nestings from creating an 1366 infinite loop of subscriptions. Typically, such mechanisms will 1367 require support in the back-end subscription protocol. In 1368 particular, applying filters to the back-end subscriptions can be an 1369 effective way to preclude such problems. 1371 8. IANA Considerations 1373 8.1 New SIP Option Tag: eventlist 1375 This section defines a new option tag for the registry established by 1376 section 27.1 of RFC 3261[1]. 1378 Option Tag Name: eventlist 1380 Description: Extension to allow subscriptions to lists of resources 1382 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1383 with the RFC number of this document when published]] 1385 8.2 New MIME type for Resource List Meta-Information 1387 MIME Media Type Name: application 1389 MIME subtype name: rlmi+xml 1391 Required parameters: None 1393 Optional parameters: charset 1395 See RFC 3023 [11] for a discussion of the charset parameter on 1396 XML-derived MIME types. Since this MIME type is used exclusively 1397 in SIP, the use of UTF-8 encoding is strongly encouraged. 1399 Encoding considerations: 8-bit text 1401 Security considerations: Security considerations specific to uses of 1402 this this MIME type are discussed in RFC xxxx [[Note to RFC 1403 editor: replace xxxx with the RFC number of this document when 1404 published]]. RFC 1874 [10] and RFC 3023 [11] discuss security 1405 issues common to all uses of XML. 1407 Interoperability considerations: The use of this MIME body is 1408 intended to be generally interoperable. No unique considerations 1409 have been identified. 1411 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1412 with the RFC number of this document when published]] 1414 Applications which use this media type: This media type is used to 1415 convey meta-information for the state of lists of resources within 1416 a Session Initiation Protocol (SIP) subscription. 1418 Additional information: 1420 Magic Number(s): None. 1422 File Extension(s): None. 1424 Macintosh File Type Code(s): None. 1426 Object Identifier(s) or OID(s): None. 1428 Intended usage: Limited Use 1430 Other Information/General Comment: None. 1432 Person to contact for further information: 1434 Name: Adam Roach 1436 E-Mail: adam@dynamicsoft.com 1438 Author/Change Controller: The specification of this MIME type is a 1439 work product of the SIMPLE working group, and was authored by 1440 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1441 change control over its specification. 1443 8.3 URN Sub-Namespace 1445 URI: urn:ietf:params:xml:ns:rlmi 1447 Description: This is the XML namespace URI for XML elements defined 1448 by [RFCXXXX] to describe information about subscriptions when such 1449 subscriptions are aggregated within a single SIP subscription. It 1450 is used in the application/rlmi+xml body type. 1452 Registrant Contact: 1454 Name: Adam Roach 1456 E-Mail: adam@dynamicsoft.com 1458 Author/Change Controller: The specification of this MIME type is a 1459 work product of the SIMPLE working group, and was authored by 1460 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1461 change control over its specification. 1463 XML: 1465 BEGIN 1466 1467 1469 1470 1471 1473 Namespace for SIP Event Resource List 1474 Meta-Information 1475 1476 1477

Namespace for SIP Event Resource List 1478 Meta-Information

1479

application/rlmi+xml

1480

See 1481 RFCXXXX.

1482 1483 1484 END 1486 9. Acknowledgements 1488 Thanks to Sean Olson for a review of and corrections to the usage of 1489 XML in this protocol. 1491 Thanks also to Hisham Khartabil, Paul Kyzivat, Keith Drage and Robert 1492 Sparks for their careful reviews of and comments on this document. 1494 Normative References 1496 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1497 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1498 Session Initiation Protocol", RFC 3261, June 2002. 1500 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1501 Notification", RFC 3265, June 2002. 1503 [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 1504 Extensions) Part One: Mechanisms for Specifying and Describing 1505 the Format of Internet Message Bodies", RFC 1521, September 1506 1993. 1508 [4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 1509 2387, August 1998. 1511 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1512 Levels", BCP 14, RFC 2119, March 1997. 1514 Non-Normative References 1516 [6] Rosenberg, J., "A Presence Event Package for the Session 1517 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 1518 in progress), January 2003. 1520 [7] Peterson, J., "Enhancements for Authenticated Identity 1521 Management in the Session Initiation Protocol (SIP)", draft- 1522 ietf-sip-identity-02 (work in progress), May 2004. 1524 [8] Olson, S., "A Mechanism for Content Indirection in Session 1525 Initiation Protocol (SIP) Messages", draft-ietf-sip-content- 1526 indirect-mech-02 (work in progress), February 2003. 1528 [9] Crocker, D. and J. Peterson, "Common Profile for Presence 1529 (CPP)", draft-ietf-impp-pres-02 (work in progress), February 1530 2003. 1532 [10] Levinson, E., "SGML Media Types", RFC 1874, December 1995. 1534 [11] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1535 3023, January 2001. 1537 [12] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 1538 2633, June 1999. 1540 [13] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security 1541 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 1542 RFC 1847, October 1995. 1544 [14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1546 Authors' Addresses 1548 Adam Roach 1549 dynamicsoft 1550 5100 Tennyson Pkwy 1551 Suite 1200 1552 Plano, TX 75024 1553 US 1555 EMail: adam@dynamicsoft.com 1556 Jonathan Rosenberg 1557 dynamicsoft 1558 600 Lanidex Plaza 1559 Parsippany, NJ 07054-2711 1560 US 1562 EMail: jdrosen@dynamicsoft.com 1564 Ben Campbell 1565 dynamicsoft 1566 5100 Tennyson Pkwy 1567 Suite 1200 1568 Plano, TX 75024 1569 US 1571 EMail: bcampbell@dynamicsoft.com 1573 Appendix A. Changes 1575 Note that this section will be removed before publication as an RFC. 1577 A.1 Changes since -04 1579 Removed references to P-Asserted-Identity mechanism. 1581 Removed some leftover cruft from the section on constructing coherent 1582 resource state. 1584 A.2 Changes since -03 1586 o Changed Content-Encoding in examples from 8bit to binary. 1588 o Adjusted formatting to comply with RFC 2223. 1590 A.3 Changes since -02 1592 o Added discussion in security section about infinite loops. 1594 o Fixed several places where the document said "one or more" instead 1595 of "zero or more", when referring to the number of resources that 1596 can appear in a list and the number of instances that can appear 1597 in a resource. 1599 o Tiny editorial cleanup (mostly spelling gaffes). 1601 A.4 Changes since -01 1603 o Several editorial updates. Change "collection" to "list" 1604 everywhere. 1606 o Added terminology section. 1608 o Added restriction that cid attributes can only point to documents 1609 at the same level as the RLMI document in which they appear. 1611 o Clarified description of how to construct resource state by 1612 splitting discussion of full state notifications apart from 1613 discussion of partial-state notifications. 1615 A.5 Changes since -00 1617 o Removed text in several places which went into detail about 1618 specific implementations which used SIP SUB/NOT for back-end 1619 subscriptions. Some of this text will probably be published later 1620 as part of an implementors' guide. 1622 o Removed specific semantics for "Event" header field parameters and 1623 SUBSCRIBE bodies. These will be defined on a per-package basis, 1624 probably by the filtering work. 1626 o Added "cid" attribute to elements. 1628 o Reworked XML schema definition for meta-information. 1630 o Added IANA registration for XML namespace. 1632 o Minor editorial fixes 1634 Appendix B. Intellectual Property Statement 1636 The IETF takes no position regarding the validity or scope of any 1637 intellectual property or other rights that might be claimed to 1638 pertain to the implementation or use of the technology described in 1639 this document or the extent to which any license under such rights 1640 might or might not be available; neither does it represent that it 1641 has made any effort to identify any such rights. 1643 Information on the IETF's procedures with respect to rights in 1644 standards-track and standards-related documentation can be found in 1645 BCP-11. Copies of claims of rights made available for publication 1646 and any assurances of licenses to be made available, or the result of 1647 an attempt made to obtain a general license or permission for the use 1648 of such proprietary rights by implementors or users of this 1649 specification can be obtained from the IETF Secretariat. 1651 The IETF invites any interested party to bring to its attention any 1652 copyrights, patents or patent applications, or other proprietary 1653 rights which may cover technology that may be required to practice 1654 this standard. Please address the information to the IETF Executive 1655 Director. 1657 Full Copyright Statement 1659 Copyright (C) The Internet Society (2004). This document is subject 1660 to the rights, licenses and restrictions contained in BCP 78, and 1661 except as set forth therein, the authors retain all their rights. 1663 This document and the information contained herein are provided on an 1664 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1665 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1666 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1667 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1668 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1669 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1671 Acknowledgement 1673 Funding for the RFC Editor function is currently provided by the 1674 Internet Society.