idnits 2.17.1 draft-ietf-simple-event-list-06.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 1754. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 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 781 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 (October 22, 2004) is 7124 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 1520 == Unused Reference: '3' is defined on line 1575, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1598, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1610, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 1521 (ref. '3') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1766 (ref. '6') (Obsoleted by RFC 3066, RFC 3282) == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-03 == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-04 -- Obsolete informational reference (is this intentional?): RFC 3023 (ref. '12') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. '13') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '15') (Obsoleted by RFC 9110) Summary: 11 errors (**), 0 flaws (~~), 9 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 B. Campbell 3 Expires: April 22, 2005 Estacado Systems 4 J. Rosenberg 5 Cisco Systems 6 October 22, 2004 8 A Session Initiation Protocol (SIP) Event Notification Extension for 9 Resource Lists 10 draft-ietf-simple-event-list-06 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 4 of RFC3667. By submitting this Internet- 16 Draft, each author represents that any applicable patent or other IPR 17 claims of which he or she is aware have been or will be disclosed, 18 and any of which he or she become aware will be disclosed, in 19 accordance with RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 22, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document presents an extension to the Session Initiation 46 Protocol (SIP)-Specific Event Notification mechanism for subscribing 47 to a homogeneous list of resources. Instead of the subscriber 48 sending a SUBSCRIBE for each resource individually, the subscriber 49 can subscribe to an entire list, and then receive notifications when 50 the state of any of the resources in the list changes. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 6 57 4. Operation of List Subscriptions . . . . . . . . . . . . . . 7 58 4.1 Negotiation of Support for Resource Lists . . . . . . . . . 7 59 4.2 Subscription Duration . . . . . . . . . . . . . . . . . . . 8 60 4.3 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.4 RLS Processing of SUBSCRIBE Requests . . . . . . . . . . . . 8 62 4.5 RLS Generation of NOTIFY requests . . . . . . . . . . . . . 9 63 4.6 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 10 64 4.7 Handling of Forked Requests . . . . . . . . . . . . . . . . 11 65 4.8 Rate of Notifications . . . . . . . . . . . . . . . . . . . 11 66 5. Using multipart/related to Convey Aggregate State . . . . . 12 67 5.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 14 69 5.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 15 70 5.4 Name Attributes . . . . . . . . . . . . . . . . . . . . . . 15 71 5.5 Instance Attributes . . . . . . . . . . . . . . . . . . . . 15 72 5.6 Constructing Coherent Resource State . . . . . . . . . . . . 17 73 5.6.1 Processing Full State Notifications . . . . . . . . . . . . 18 74 5.6.2 Processing Partial State Notifications . . . . . . . . . . . 18 75 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 7. Security Considerations . . . . . . . . . . . . . . . . . . 32 77 7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 32 78 7.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 32 79 7.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 33 80 7.4 Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . 33 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 82 8.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 35 83 8.2 New MIME type for Resource List Meta-Information . . . . . . 35 84 8.3 URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . . 36 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 86 Normative References . . . . . . . . . . . . . . . . . . . . 39 87 Non-Normative References . . . . . . . . . . . . . . . . . . 40 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 89 A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 42 90 A.1 Changes since -05 . . . . . . . . . . . . . . . . . . . . . 42 91 A.2 Changes since -04 . . . . . . . . . . . . . . . . . . . . . 42 92 A.3 Changes since -03 . . . . . . . . . . . . . . . . . . . . . 42 93 A.4 Changes since -02 . . . . . . . . . . . . . . . . . . . . . 42 94 A.5 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 43 95 A.6 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 43 96 B. Intellectual Property Statement . . . . . . . . . . . . . . 44 97 Full Copyright Statement . . . . . . . . . . . . . . . . . . 45 99 1. Introduction 101 The SIP-specific event notification mechanism [2] allows a user (the 102 subscriber) to request to be notified of changes in the state of a 103 particular resource. This is accomplished by having the subscriber 104 generate a SUBSCRIBE request for the resource, which is processed by 105 a notifier that represents the resource. 107 In many cases, a subscriber has a list of resources they are 108 interested in. Without some aggregating mechanism, this will require 109 the subscriber generate a SUBSCRIBE request for each resource about 110 which they want information. For environments in which bandwidth is 111 limited, such as wireless networks, subscribing to each resource 112 individually is problematic. Some specific problems are: 114 o Doing so generates substantial message traffic, in the form of the 115 initial SUBSCRIBE requests for each resource, and the refreshes of 116 each individual subscription. 118 o The notifier may insist on low refresh intervals, in order to 119 avoid long lived subscription state. This means that the 120 subscriber may need to generate SUBSCRIBE refreshes faster than it 121 would like to, or has the capacity to. 123 o The notifier may generate NOTIFY requests more rapidly than the 124 subscriber desires, causing NOTIFY traffic at a greater volume 125 than is desired by the subscriber. 127 To solve these problems, this specification defines an extension to 128 RFC 3265 [2] that allows for requesting and conveying notifications 129 for lists of resources. A resource list is identified by a URI and 130 it represents a list of zero or more URIs. Each of these URIs is an 131 identifier for an individual resource for which the subscriber wants 132 to receive information. In many cases, the URI used to identify the 133 resource list will be a SIP URI [1]; however, the use of other 134 schemes (such as pres: [10]) is also foreseen. 136 The notifier for the list is called a "resource list server", or RLS. 137 In order to determine the state of the entire list, the RLS will act 138 as if it has generated a subscription to each resource in the list. 140 The resource list is not restricted to be inside the domain of the 141 subscriber. Similarly, the resources in the list are not constrained 142 to be in the domain of the resource list server. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [5]. 150 The following terms are used throughout the remainder of this 151 document. 153 Back-End Subscription: Any subscription (SIP or otherwise) that an 154 RLS creates to learn of the state of a resource. An RLS will 155 create back-end subscriptions to learn of the state of a resource 156 about which the RLS is not an authority. For back-end 157 subscriptions, RLSes act as a subscriber. 159 List Subscription: A subscription to a resource list. In list 160 subscriptions, RLSes act a the notifier. 162 Resource: A resource is any logical entity that has a state or states 163 that can be subscribed to. Resources are identified by URIs. 165 Resource List: A list of zero or more resources that can have their 166 individual states subscribed to with a single subscription. 168 RLMI: Resource List Meta-Information. RLMI is a document that 169 describes the state of the virtual subscriptions associated with a 170 list subscription. 172 RLS: Resource List Server. RLSes accept subscriptions to resource 173 lists and send notifications to update subscribers of the state of 174 the resources in a resource list. 176 Virtual Subscription: Virtual Subscriptions are a logical construct 177 within an RLS that represent subscriptions to the resources in a 178 resource list. For each list subscription it services, an RLS 179 creates at least one virtual subscription for every resource in 180 the resource list being subscribed to. In some cases, such as 181 when the RLS is not the authority for the state of the resource, 182 this virtual subscription will be associated with a back-end 183 subscription. In other cases, such as when the RLS is the 184 authority for the state of the resource, the virtual subscription 185 will not have a corresponding back-end subscription. 187 3. Overview of Operation 189 This section provides an overview of the typical mode of operation of 190 this extension. It is not normative. 192 When users wish to subscribe to the resource of a list of resources, 193 they can use the mechanisms described in this specification. The 194 first step is creation of a resource list. This resource list is 195 represented by a SIP URI. The list contains a set of URIs, each of 196 which represents a resource for which the subscriber wants to receive 197 information. The resource list can exist in any domain. The list 198 could be manipulated through a web page, through a voice response 199 system, or through some other protocol. The specific means by which 200 the list is created and maintained is outside of the scope of this 201 specification. 203 To learn the resource state of the set of elements on the list, the 204 user sends a single SUBSCRIBE request targeted to the URI of the 205 list. This will be routed to an RLS for that URI. The RLS acts as a 206 notifier, authenticates the subscriber, and accepts the subscription. 208 The RLS may have direct information about some or all of the 209 resources specified by the list. If it does not, it could subscribe 210 to any non-local resources specified by the list resource. 212 Note that subscriptions to non-local resources may or may not be SIP 213 subscriptions; any mechanism for determining such information may be 214 employed. This document uses the term "back-end subscription" to 215 refer to such a subscription, regardless of whether SIP is used to 216 establish and service it. 218 As the state of resources in the list change, the RLS generates 219 notifications to the list subscribers. The RLS can, at its 220 discretion, buffer notifications of resource changes, and send the 221 resource information to the subscriber in batches, rather than 222 individually. This allows the RLS to provide rate limiting for the 223 subscriber. 225 The list notifications contain a body of type multipart/related. The 226 root section of the multipart/related content is an XML document that 227 provides meta-information about each resource present in the list. 228 The remaining sections contain the actual state information for each 229 resource. 231 4. Operation of List Subscriptions 233 The event list extension acts, in many ways, like an event template 234 package. In particular, any single list subscription must be 235 homogeneous with respect to the underlying event package. In other 236 words, a single list subscription can apply only one event package to 237 all of the resources in the resource list. 239 It is worth noting that it is perfectly valid, for an RLS to allow 240 multiple subscriptions to the same list to use differing event 241 packages. 243 The key difference between a list subscription and templates in 244 general is that support for list subscriptions indicates support for 245 arbitrary nesting of list subscriptions. In other words, elements 246 within the list may be atomic elements, or they may be lists 247 themselves. 249 The consequence of this is that subscription to a URI that represents 250 a list actually results in a several virtual subscriptions to a tree 251 of resources. The leaf nodes of this tree are virtual subscriptions 252 of the event type given in the "Event" header field; all other nodes 253 in the tree are list subscriptions that are serviced as described in 254 this section and its subsections. 256 It is important to keep in mind that these virtual subscriptions are 257 not literal SIP subscriptions (although they may result in SIP 258 subscriptions, depending on the RLS implementation). 260 4.1 Negotiation of Support for Resource Lists 262 This specification uses the SIP option tag mechanism for negotiating 263 support for the extension defined herein. Refer to RFC3261 [1] for 264 the normative description of processing of the "Supported" and 265 "Require" header fields and the 421 (Extension Required) response 266 code. 268 A non-normative description of the implications of the use of 269 option tags follows. 271 Any client that supports the event list extension will include an 272 option tag of "eventlist" in a "Supported" header field of every 273 SUBSCRIBE message for a subscription for which it is willing to 274 process a list. If the subscription is made to a URI that 275 represents a list, the RLS will include "eventlist" in a "Require" 276 header field of the response to the SUBSCRIBE, and in all NOTIFY 277 messages within that subscription. 279 Use of "Require: eventlist" in NOTIFY messages is applied by the 280 notifier to satisfy the RFC3261 requirement that a UAC MUST insert 281 a Require header field into a request if the UAC wishes to insist 282 that a UAS understand an extension in order to process the 283 request. Because the NOTIFY would not be usable without applying 284 the eventlist option, the notifier is obligated to include it. 286 Including "eventlist" in a "Require" header field in a SUBSCRIBE 287 request serves no purpose, and is consequently NOT RECOMMENDED. 289 There is nothing in a SIP URI which indicates whether it represents a 290 list of resources or a single resource. Therefore, if a subscriber 291 sends a request to a URI that represents a list resource, but does 292 not include a Supported header field listing the "eventlist" token, 293 the notifier will typically return a 421 (Extension Required) 294 response code. RFC 3261 [1] advises servers to avoid returning a 295 421, and instead, attempt to process the request without the 296 extension. However, in this case, the URI fundamentally represents a 297 list resource, and therefore, the subscription cannot proceed without 298 this extension. 300 4.2 Subscription Duration 302 Since the primary benefit of the resource list server is to reduce 303 the overall messaging volume to a subscriber, it is RECOMMENDED that 304 the subscription duration to a list be reasonably long. The default, 305 when no duration is specified, is taken from the underlying event 306 package. Of course, the standard techniques [2] can be used to 307 increase or reduce this amount. 309 4.3 NOTIFY Bodies 311 An implementation compliant to this specification MUST support the 312 multipart/related and application/rlmi+xml MIME types. These types 313 MUST be included in an Accept header sent in SUBSCRIBE message, in 314 addition to any other types supported by the client (including any 315 types required by the event package being used). 317 4.4 RLS Processing of SUBSCRIBE Requests 319 Once the subscriber is authenticated, the RLS performs authorization 320 per its local policy. In many cases, each resource list is 321 associated with a particular user (the one who created it and manages 322 the set of elements in it), and only that user will be allowed to 323 subscribe. Of course, this mode of operation is not inherent in the 324 use of resource lists, and an RLS can use any authorization policy it 325 chooses. 327 4.5 RLS Generation of NOTIFY requests 329 This specification leaves the choice about how and when to generate 330 NOTIFY requests at the discretion of the implementor. One of the 331 value propositions of the RLS is the means by which it aggregates, 332 rate limits, or optimizes the way in which notifications are 333 generated. As a baseline behavior, the RLS MAY generate a NOTIFY to 334 the RLS subscriber whenever the state of any resource on the list 335 changes. 337 See Section 5 for a detailed definition of the syntax used to convey 338 the state of resource lists. For the purposes of the following 339 discussion, it is important to know that the overall list contains 340 zero or more resources, and that the resources contains zero or more 341 instances. Each instance has a state associated with it (pending, 342 active, or terminating), representing the state of the virtual 343 subscription. 345 Notifications contain a multipart document, the first part of which 346 always contains meta-information about the list (e.g. membership, 347 state of the virtual subscription to the resource). Remaining parts 348 are used to convey the actual state of the resources listed in the 349 meta-information. 351 The "state" attribute of each instance of a resource in the meta- 352 information is set according to the state of the virtual 353 subscription. The meanings of the "state" attribute are described in 354 RFC 3265 [2]. 356 If an instance of a resource was previously reported to the 357 subscriber but is no longer available (i.e. the virtual subscription 358 to that instance has been terminated), the resource list server 359 SHOULD include that resource instance in the meta-information in the 360 first NOTIFY message sent to the subscriber following the instance's 361 unavailability. The RLS MAY continue to do so for future 362 notifications. 364 When sending information for a terminated resource instance, the RLS 365 indicates a state of "terminated" and an appropriate reason value. 366 Valid reason values and their meanings are described in RFC 3265 [2]. 367 If the RLS will attempt to recover the resource state again at some 368 point in the future (e.g. when the reason in the meta-information is 369 "probation"), then the instance of the resource SHOULD remain in the 370 meta-information until the instance state is available, or until the 371 RLS gives up on making such state available. 373 When the first SUBSCRIBE message for a particular subscription is 374 received by a RLS, the RLS will often not know state information for 375 all of the resources specified by the resource list. For any 376 resource for which state information is not known, the corresponding 377 "uri" attribute will be set appropriately, and no elements 378 will be present for the resource. 380 For an initial notification, sections corresponding to resources for 381 which the RLS does have state will be populated with appropriate data 382 (subject, of course, to local policy decisions). This will often 383 occur if the resource list server is co-located with the server for 384 one or more of the resources specified on the list. 386 Immediate notifications triggered as a result of subsequent SUBSCRIBE 387 messages SHOULD include an RLMI document with full state indicated. 388 The RLS SHOULD also include state information for all resources in 389 the list for which the RLS has state, subject to policy restrictions. 390 This allows the subscriber to refresh their state, and to recover 391 from lost notifications. 393 4.6 Subscriber Processing of NOTIFY Requests 395 Notifications for a resource list can convey information about a 396 subset of the list elements. This means that an explicit algorithm 397 needs to be defined in order to construct coherent and consistent 398 state. 400 The XML document present in the root of the multipart/related 401 document contains a element for some or all of the 402 resources in the list. Each element contains a URI which 403 uniquely identifies the resource to which that section corresponds. 404 When a NOTIFY arrives, it can contain full or partial state (as 405 indicated by the "fullState" attribute of the top-level 406 element). If full state is indicated, then the recipient replaces 407 all state associated with the list with the entities in the NOTIFY 408 body. If full state is not indicated, the recipient of the NOTIFY 409 updates information for each identified resource. Information for 410 any resources that are not identified in the NOTIFY are not changed, 411 even if they were indicated in previous NOTIFY messages. See Section 412 5.6 for more information. 414 When full state is indicated, note that it applies only to the 415 RLMI document in which it occurs. In particular, one of the 416 elements in the document may in turn refer to another 417 list of resources. Any such sub-lists will be detailed in their 418 own RLMI documents, which may or may not have full state 419 indicated. 421 Further note that underlying event package may have its own rules 422 for compositing partial state notification. When processing data 423 related to those packages, their rules apply (i.e. the fact that 424 they were reported as part of a list does not change their partial 425 notification semantics). 427 Finally, note that a consequence of the way in which resource list 428 subscriptions work is that polling of resource state may not be 429 particularly useful. While such polls will retrieve the resource 430 list, they will not necessarily contain state for some or all of 431 the resources on the list. 433 4.7 Handling of Forked Requests 435 Forking makes little sense with subscriptions to event lists, since 436 the whole idea is a centralization of the source of notifications. 437 Therefore, a subscriber to a list MUST NOT install multiple 438 subscriptions when the initial request is forked. If multiple 439 responses are received, they are handled using the techniques 440 described in section 4.4.9 of RFC 3265[2]. 442 4.8 Rate of Notifications 444 One potential role of the RLS is to perform rate limitations on 445 behalf of the subscriber. As such, this specification does not 446 mandate any particular rate limitation, and rather leaves that to the 447 discretion of the implementation. 449 5. Using multipart/related to Convey Aggregate State 451 In order to convey the state of multiple resources, the list 452 extension uses the "multipart/related" mime type. The syntax for 453 multipart/related is defined in "The MIME Multipart/Related Content- 454 type" [4]. 456 5.1 XML Syntax 458 The root document of the multipart/related body MUST be a Resource 459 List Meta-Information (RLMI) document. It is of type "application/ 460 rlmi+xml". This document contains the meta-information for the 461 resources contained in the notification. The schema for this XML 462 document is given below. 464 465 469 470 471 472 474 476 477 478 480 482 483 484 485 486 487 488 489 491 493 494 495 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 528 An example of a document formatted using this schema follows. 530 531 534 Buddy List 535 Liste d'amis 536 540 541 542 Dave Jones 543 545 546 547 Jim 548 549 550 551 Ed 552 553 554 556 5.2 List Attributes 558 The element present in a list notification MUST contain three 559 attributes. 561 The first mandatory attribute is "uri", which contains the uri 562 that corresponds to the list. Typically, this is the URI to which 563 the SUBSCRIBE request was sent. 565 The second mandatory attribute is "version", which contains a 566 number from 0 to 2^32-1. This version number MUST be 0 for the first 567 NOTIFY message sent within a subscription, and MUST increase by 568 exactly one for each subsequent NOTIFY sent within a subscription. 570 The third mandatory attribute is "fullState". The "fullState" 571 attribute indicates whether the NOTIFY message contains information 572 for every resource in the list. If it does, the value of the 573 attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The 574 first NOTIFY sent in a subscription MUST contain full state, as must 575 the first NOTIFY sent after receipt of a SUBSCRIBE request for the 576 subscription. 578 Finally, elements MAY contain a "cid" attribute. If present, 579 the "cid" attribute identifies a section within the multipart/related 580 body that contains aggregate state information for the resources 581 contained in the list. The definition of such aggregate information 582 is outside the scope of this document, and will be defined on a per- 583 package basis as needed. The cid attribute is the Content-ID for the 584 corresponding section in the multipart body. 586 The cid attribute MUST refer only to top-level parts of the 587 multipart/related document for which the RLMI document in which it 588 appears is the root. See Section 5.5 for an example. 590 5.3 Resource Attributes 592 The resource list contains one element for each resource 593 being reported in the notification. These resource elements contain 594 attributes that identify meta-data associated with each resource. 596 The "uri" attribute identifies the resource to which the 597 element corresponds. Typically, this will be a SIP URI which, if 598 subscribed to, would return the state of the resource. This 599 attribute MUST be present. 601 5.4 Name Attributes 603 Each list and resource element contains zero or more name elements. 604 These name elements contain human readable descriptions or names for 605 the resource list or resource. The contents of these elements are 606 somewhat analogous to the "Display Name" present in the SIP name-addr 607 element. 609 Name elements contain an optional attribute, called "language". The 610 "language" attribute, if present, specifies the language of the 611 human-readable name. If this attribute is present, is MUST contain a 612 valid language tag. Language tags are defined in RFC 1766 [6]. The 613 language tag assists applications in determining which of potentially 614 several name elements should be rendered to the user. 616 5.5 Instance Attributes 618 Each resource element contains zero or more instance elements. These 619 instance elements are used to represent a single notifier for the 620 resource. For event packages that allow forking, multiple virtual 621 subscriptions may exist for a given resource. Multiple virtual 622 subscriptions are represented as multiple instance elements in the 623 corresponding resource element. For subscriptions in which forking 624 does not occur, at most one instance will be present for a given 625 resource. 627 The "id" attribute contains an opaque string used to uniquely 628 identify the instance of the resource. The "id" attribute is unique 629 only within the context of a resource. Construction of this string 630 is an implementation decision. Any mechanism for generating this 631 string is valid, as long as uniqueness within the resource is 632 assured. 634 The "state" attribute contains the subscription state for the 635 identified instance of the resource. This attribute contains one of 636 the values "active", "pending", or "terminated". The meanings for 637 these values are as defined for the "Subscription-State" header field 638 in RFC 3265 [2]. 640 If the "state" attribute indicates "terminated", then a "reason" 641 attribute MUST also be present. This "reason" attribute has the same 642 values and meanings as given for the "reason" parameter on the 643 "Subscription-State" header field in RFC 3265 [2]. Note that the 644 "reason" attribute is included for informational purposes; the list 645 subscriber is not expected to take any automated actions based on the 646 reason value. 648 Finally, the "cid" attribute, which MUST be present if the "state" 649 attribute is "active", identifies the section within the multipart/ 650 related body that contains the actual resource state. This state is 651 expressed in the content type defined by the event package for 652 conveying state. The cid attribute is the Content-ID for the 653 corresponding section in the multipart body. 655 The cid attribute MUST refer only to top-level parts of the 656 multipart/related document for which the RLMI document in which it 657 appears is the root. 659 For example, consider a multipart/related document containing 660 three parts; we'll label these parts A, B, and C. Part A is type 661 application/rlmi+xml, part B is type multipart/related, and part C 662 is type application/cpim-pidf+xml. Part B is in turn a document 663 containing three parts: D, E, and F. Part D is of type 664 application/rlmi+xml, and parts E and F are of type application/ 665 cpim-pidf+xml. 667 +-------------------------------------------+ 668 | Top Level Document: multipart/related | 669 | | 670 | +---------------------------------------+ | 671 | | Part A: application/rlmi+xml | | 672 | +---------------------------------------+ | 673 | | Part B: multipart/related | | 674 | | | | 675 | | +-----------------------------------+ | | 676 | | | Part D: application/rlmi+xml | | | 677 | | +-----------------------------------+ | | 678 | | | Part E: application/cpim-pidf+xml | | | 679 | | +-----------------------------------+ | | 680 | | | Part F: application/cpim-pidf+xml | | | 681 | | +-----------------------------------+ | | 682 | | | | 683 | +---------------------------------------+ | 684 | | Part C: application/cpim-pidf+xml | | 685 | +---------------------------------------+ | 686 | | 687 +-------------------------------------------+ 689 Any "cid" attributes in document A must refer only to parts B or 690 C. Referring to parts D, E, or F would be illegal. Similarly, 691 Any "cid" attributes in document D must refer only to parts E or 692 F. Referring to any other parts would be illegal. 694 Also note that the subscription durations of any back-end 695 subscriptions are not propagated into the meta-information state 696 in any way. 698 5.6 Constructing Coherent Resource State 700 The resource list subscriber maintains a table for each resource 701 list. The table contains a row for each resource in the resource 702 list. Each row is indexed by the URI for that resource. That URI is 703 obtained from the "uri" attribute on each element. The 704 contents of each row contain the state of that resource as conveyed 705 in the resource document. 707 For resources that provide versioning information (which is mandated 708 by [2] for any formats that allow partial notification), each row 709 also contains a resource state version number. The version number of 710 the row is initialized with the version specified in the first 711 document received, as defined by the corresponding event package. 712 This value is used when comparing versions of partial notifications 713 for a resource. 715 The processing of the resource list notification depends on whether 716 it contains full or partial state. 718 5.6.1 Processing Full State Notifications 720 If a notification contains full state, indicated by the 721 attribute "fullState" set to "true", the notification is used to 722 update the table. A check is first made to ensure that the "version" 723 attribute of the attribute in the received message is greater 724 than the local version number. If not, the received document is 725 discarded without any further processing. Otherwise, the contents of 726 the resource-list table are flushed, and repopulated from the 727 contents of the document. A new row in the table is created for each 728 "resource" element. 730 5.6.2 Processing Partial State Notifications 732 If a notification contains partial state, indicated by the 733 attribute "fullState" set to "false", a check is made to ensure that 734 no list notifications have been lost. The value of the local version 735 number (the "version" attribute of the element) is compared to 736 the version number of the new document. 738 o If the value in the new document is exactly one higher than the 739 local version number, the local version number is increased by 740 one, and the document is processed, as described below. 742 o If the version in the document is more than one higher than the 743 local version number, the local version number is set to the value 744 in the new document, and the document is processed as described 745 below. The list subscriber SHOULD also generate a refresh request 746 to trigger a full state notification. 748 o If the version in the document is less than or equal to the local 749 version, the document is discarded without any further processing. 751 For each resource listed in the document, the subscriber checks to 752 see whether a row exists for that resource. This check is done by 753 comparing the Resource-URI value with the URI associated with the 754 row. If the resource doesn't exist in the table, a row is added, and 755 its state is set to the information from that "resource" element. If 756 the resource does exist, its state is updated to be the information 757 from that "resource" element, as described in the definition of the 758 event package. If a row is updated or created such that its state is 759 now "terminated," that entry MAY be removed from the table at any 760 time. 762 6. Example 764 This section gives an example call flow. It is not normative. If a 765 conflict arises between this call flow and the normative behavior 766 described in this or any other document, the normative descriptions 767 are to be followed. 769 In this particular example, we request a subscription to a nested 770 presence list. The subscriber's address-of-record is 771 "sip:adam@example.com", and the name of the nested list resource that 772 we are subscribing to is called "sip:adam-buddies@pres.example.com". 773 The underlying event package is "presence", described by [7]. 775 In this example, the RLS has information to service some of the 776 resources on the list, but must consult other servers to retrieve 777 information for others. The implementation of the RLS in this 778 example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such 779 information. 781 Terminal pres.example.com pres.example.org 782 | | pres.example.net | 783 1 |---SUBSCRIBE--->| | | 784 2 |<-----200-------| | | 785 3 |<----NOTIFY-----| | | 786 4 |------200------>| | | 787 5 | |---SUBSCRIBE--->| | 788 6 | |<-----200-------| | 789 7 | |<----NOTIFY-----| | 790 8 | |------200------>| | 791 9 | |------------SUBSCRIBE----------->| 792 10| |<--------------200---------------| 793 11| |<-------------NOTIFY-------------| 794 12| |---------------200-------------->| 795 13|<----NOTIFY-----| | | 796 14|------200------>| | | 798 1. We initiate the subscription by sending a SUBSCRIBE message to 799 our local RLS. (There is no reason that the RLS we contact has 800 to be in our domain, of course). Note that we must advertise 801 support for application/rlmi+xml and multipart/related because 802 we support the eventlist extension, and we must advertise 803 application/cpim-pidf+xml because we are requesting a 804 subscription to presence. 806 Terminal -> Local RLS 808 SUBSCRIBE sip:adam-buddies@pres.example.com SIP/2.0 809 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 810 Max-Forwards: 70 811 To: 812 From: ;tag=ie4hbb8t 813 Call-ID: cdB34qLToC@terminal.example.com 814 CSeq: 322723822 SUBSCRIBE 815 Contact: 816 Event: presence 817 Expires: 7200 818 Supported: eventlist 819 Accept: application/cpim-pidf+xml 820 Accept: application/rlmi+xml 821 Accept: multipart/related 822 Accept: multipart/signed 823 Accept: application/pkcs7-mime 824 Content-Length: 0 826 2. The Local RLS completes the SUBSCRIBE transaction. Note that 827 authentication and authorization would normally take place at 828 this point in the call flow. Those steps are omitted for 829 brevity. 831 Local RLS -> Terminal 833 SIP/2.0 200 OK 834 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 835 To: ;tag=zpNctbZq 836 From: ;tag=ie4hbb8t 837 Call-ID: cdB34qLToC@terminal.example.com 838 CSeq: 322723822 SUBSCRIBE 839 Contact: 840 Expires: 7200 841 Require: eventlist 842 Content-Length: 0 844 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY 845 immediately upon accepting the subscription. In this example, 846 we are assuming that the local RLS is also an authority for 847 presence information for the users in the "example.com" domain. 848 The NOTIFY contains an RLMI document describing the entire buddy 849 list (initial notifies require full state), as well as presence 850 information for the users about which it already knows. Note 851 that, since the RLS has not yet retrieved information for some 852 of the entries on the list, those elements contain no 853 elements. 855 Local RLS -> Terminal 857 NOTIFY sip:terminal.example.com SIP/2.0 858 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 859 Max-Forwards: 70 860 From: ;tag=zpNctbZq 861 To: ;tag=ie4hbb8t 862 Call-ID: cdB34qLToC@terminal.example.com 863 CSeq: 997935768 NOTIFY 864 Contact: 865 Event: presence 866 Subscription-State: active;expires=7200 867 Require: eventlist 868 Content-Type: multipart/related;type="application/rlmi+xml"; 869 start="";boundary="50UBfW7LSCVLtggUPe5z" 870 Content-Length: 1560 872 --50UBfW7LSCVLtggUPe5z 873 Content-Transfer-Encoding: binary 874 Content-ID: 875 Content-Type: application/rlmi+xml;charset="UTF-8" 877 878 881 Buddy List at COM 882 Liste der Freunde an COM 883 884 Bob Smith 885 887 888 889 Dave Jones 890 892 893 894 Ed at NET 895 896 897 My Friends at ORG 898 Meine Freunde an ORG 899 900 902 --50UBfW7LSCVLtggUPe5z 903 Content-Transfer-Encoding: binary 904 Content-ID: 905 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 907 908 910 911 912 open 913 914 sip:bob@example.com 915 916 918 --50UBfW7LSCVLtggUPe5z 919 Content-Transfer-Encoding: binary 920 Content-ID: 921 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 923 924 926 927 928 closed 929 930 931 933 --50UBfW7LSCVLtggUPe5z-- 935 4. The terminal completes the transaction. 937 Terminal -> Local RLS 939 SIP/2.0 200 OK 940 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 941 From: ;tag=zpNctbZq 942 To: ;tag=ie4hbb8t 943 Call-ID: cdB34qLToC@terminal.example.com 944 CSeq: 997935768 NOTIFY 945 Contact: 946 Content-Length: 0 948 5. In order to service the subscription, the local RLS subscribes 949 to the state of the resources. In this step, the RLS attempts 950 to subscribe to the presence state of the resource 951 "sip:ed@example.net". Since the local RLS knows how to receive 952 notifications for list subscriptions, it includes the 953 "Supported: eventlist" header field in its request. Although 954 the linkage between this subscription and the one sent by the 955 terminal is left up to the application, this message 956 demonstrates some reasonable behavior by including "Accept" 957 header fields for all of the body types it knows the subscriber 958 (Terminal) supports. This is safe to do, since the local RLS 959 will only pass these formats through to the subscriber, and does 960 not need to actually understand them. 962 Local RLS -> Presence Server in example.net 964 SUBSCRIBE sip:ed@example.net SIP/2.0 965 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 966 Max-Forwards: 70 967 To: 968 From: ;tag=aM5icQu9 969 Call-ID: Ugwz5ARxNw@pres.example.com 970 CSeq: 870936068 SUBSCRIBE 971 Contact: 972 Event: presence 973 Expires: 3600 974 Supported: eventlist 975 Accept: application/cpim-pidf+xml 976 Accept: application/rlmi+xml 977 Accept: multipart/related 978 Accept: multipart/signed 979 Accept: application/pkcs7-mime 980 Content-Length: 0 981 6. The Presence Server in example.net completes the SUBSCRIBE 982 transaction. Note that authentication would normally take place 983 at this point in the call flow. Those steps are omitted for 984 brevity. 986 Presence Server in example.net -> Local RLS 988 SIP/2.0 200 OK 989 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 990 To: ;tag=e45TmHTh 991 From: ;tag=aM5icQu9 992 Call-ID: Ugwz5ARxNw@pres.example.com 993 CSeq: 870936068 SUBSCRIBE 994 Contact: 995 Expires: 3600 996 Content-Length: 0 998 7. In this example, we assume that the server at example.net 999 doesn't have enough authorization information to reject or 1000 accept our subscription. The initial notify, therefore, 1001 contains a "Subscription-State" of "pending". Presumably, the 1002 party responsible for accepting or denying authorization for the 1003 resource is notified of this change; however, those steps are 1004 not included in this call flow for brevity. 1006 Presence Server in example.net -> Local RLS 1008 NOTIFY sip:pres.example.com SIP/2.0 1009 Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW 1010 Max-Forwards: 70 1011 From: ;tag=e45TmHTh 1012 To: ;tag=aM5icQu9 1013 Call-ID: Ugwz5ARxNw@pres.example.com 1014 CSeq: 1002640632 NOTIFY 1015 Contact: 1016 Subscription-State: pending;expires=3600 1017 Event: presence 1018 Require: eventlist 1019 Content-Length: 0 1021 8. The local RLS completes the NOTIFY transaction. Note that, at 1022 this point, the Local RLS has new information to report to the 1023 subscriber. Whether it chooses to report the information 1024 immediately or spool it up for later delivery is completely up 1025 to the application. For this example, we assume that the RLS 1026 will wait for a short period of time before doing so, in order 1027 to allow the subscriptions it sent out sufficient time to 1028 provide useful data. 1030 Local RLS -> Presence Server in example.net 1032 SIP/2.0 200 OK 1033 Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW 1034 From: ;tag=e45TmHTh 1035 To: ;tag=aM5icQu9 1036 Call-ID: Ugwz5ARxNw@pres.example.com 1037 CSeq: 1002640632 NOTIFY 1038 Contact: 1039 Content-Length: 0 1041 9. The Local RLS subscribes to the state of the other non-local 1042 resource. 1044 Local RLS -> RLS in example.org 1046 SUBSCRIBE sip:adam-friends@example.org SIP/2.0 1047 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 1048 Max-Forwards: 70 1049 To: 1050 From: ;tag=a12eztNf 1051 Call-ID: kBq5XhtZLN@pres.example.com 1052 CSeq: 980774491 SUBSCRIBE 1053 Contact: 1054 Event: presence 1055 Expires: 3600 1056 Supported: eventlist 1057 Accept: application/cpim-pidf+xml 1058 Accept: application/rlmi+xml 1059 Accept: multipart/related 1060 Accept: multipart/signed 1061 Accept: application/pkcs7-mime 1062 Content-Length: 0 1064 10. The RLS in example.org completes the SUBSCRIBE transaction. 1065 Note that authentication and would normally take place at this 1066 point in the call flow. Those steps are omitted for brevity. 1068 RLS in example.org -> Local RLS 1070 SIP/2.0 200 OK 1071 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 1072 To: ;tag=JenZ40P3 1073 From: ;tag=a12eztNf 1074 Call-ID: kBq5XhtZLN@pres.example.com 1075 CSeq: 980774491 SUBSCRIBE 1076 Contact: 1077 Expires: 3600 1078 Content-Length: 0 1080 11. In this example, we are assuming that the RLS in example.org is 1081 also an authority for presence information for the users in the 1082 "example.org" domain. The NOTIFY contains an RLMI document 1083 describing the contained buddy list, as well as presence 1084 information for those users. In this particular case, the RLS 1085 in example.org has chosen to sign [14] the body of the NOTIFY 1086 message. As described in RFC 3851, signing is performed by 1087 creating a multipart/signed document which has two parts. The 1088 first part is the document to be signed (in this example, the 1089 multipart/related document that describes the list resource 1090 states), while the second part is the actual signature. 1092 RLS in example.org -> Local RLS 1094 NOTIFY sip:pres.example.com SIP/2.0 1095 Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI 1096 Max-Forwards: 70 1097 From: ;tag=JenZ40P3 1098 To: ;tag=a12eztNf 1099 Call-ID: kBq5XhtZLN@pres.example.com 1100 CSeq: 294444656 NOTIFY 1101 Contact: 1102 Event: presence 1103 Subscription-State: active;expires=3600 1104 Require: eventlist 1105 Content-Type: multipart/signed; 1106 protocol="application/pkcs7-signature"; 1107 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1108 Content-Length: 2038 1110 --l3WMZaaL8NpQWGnQ4mlU 1111 Content-Transfer-Encoding: binary 1112 Content-ID: 1113 Content-Type: multipart/related;type="application/rlmi+xml"; 1114 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 1116 --tuLLl3lDyPZX0GMr2YOo 1117 Content-Transfer-Encoding: binary 1118 Content-ID: 1119 Content-Type: application/rlmi+xml;charset="UTF-8" 1121 1122 1125 Buddy List at COM 1126 Liste der Freunde an COM 1127 1128 Joe Thomas 1129 1130 1131 1132 Mark Edwards 1133 1134 1135 1137 --tuLLl3lDyPZX0GMr2YOo 1138 Content-Transfer-Encoding: binary 1139 Content-ID: 1140 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1142 1143 1145 1146 1147 open 1148 1149 sip:joe@example.org 1150 1151 1153 --tuLLl3lDyPZX0GMr2YOo 1154 Content-Transfer-Encoding: binary 1155 Content-ID: 1156 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1158 1159 1161 1162 1163 closed 1164 1165 1166 1168 --tuLLl3lDyPZX0GMr2YOo-- 1170 --l3WMZaaL8NpQWGnQ4mlU 1171 Content-Transfer-Encoding: binary 1172 Content-ID: 1173 Content-Type: application/pkcs7-signature 1175 [PKCS #7 signature here] 1177 --l3WMZaaL8NpQWGnQ4mlU-- 1179 12. The Local RLS completes the NOTIFY transaction. 1181 Local RLS -> RLS in example.org 1183 SIP/2.0 200 OK 1184 Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI 1185 From: ;tag=JenZ40P3 1186 To: ;tag=a12eztNf 1187 Call-ID: kBq5XhtZLN@pres.example.com 1188 CSeq: 294444656 NOTIFY 1189 Contact: 1190 Content-Length: 0 1192 13. At this point, the Local RLS decides it has collected enough 1193 additional information to warrant sending a new notification to 1194 the user. Although sending a full notification would be 1195 perfectly acceptable, the RLS decides to send a partial 1196 notification instead. The RLMI document contains only 1197 information for the updated resources, as indicated by setting 1198 the "fullState" parameter to "false". To avoid corrupting the 1199 S/MIME signature on the data received from the RLS in 1200 example.org, the local RLS copies the entire multipart/signed 1201 body as-is into the notification that it sends. 1203 Local RLS -> Terminal 1205 NOTIFY sip:terminal.example.com SIP/2.0 1206 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1207 Max-Forwards: 70 1208 From: ;tag=zpNctbZq 1209 To: ;tag=ie4hbb8t 1210 Call-ID: cdB34qLToC@terminal.example.com 1211 CSeq: 997935769 NOTIFY 1212 Contact: 1213 Event: presence 1214 Subscription-State: active;expires=7200 1215 Require: eventlist 1216 Content-Type: multipart/related;type="application/rlmi+xml"; 1217 start="<2BEI83@pres.example.com>";boundary="TfZxoxgAvLqgj4wRWPDL" 1218 Content-Length: 2862 1220 --TfZxoxgAvLqgj4wRWPDL 1221 Content-Transfer-Encoding: binary 1222 Content-ID: <2BEI83@pres.example.com> 1223 Content-Type: application/rlmi+xml;charset="UTF-8" 1225 1226 1229 Buddy List at COM 1230 Liste der Freunde an COM 1231 1232 Ed at NET 1233 1234 1235 1236 My Friends at ORG 1237 Meine Freunde an ORG 1238 1240 1241 1243 --TfZxoxgAvLqgj4wRWPDL 1244 Content-Transfer-Encoding: binary 1245 Content-ID: <1KQhyE@pres.example.com> 1246 Content-Type: multipart/signed; 1247 protocol="application/pkcs7-signature"; 1248 micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" 1250 --l3WMZaaL8NpQWGnQ4mlU 1251 Content-Transfer-Encoding: binary 1252 Content-ID: 1253 Content-Type: multipart/related;type="application/rlmi+xml"; 1254 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 1256 --tuLLl3lDyPZX0GMr2YOo 1257 Content-Transfer-Encoding: binary 1258 Content-ID: 1259 Content-Type: application/rlmi+xml;charset="UTF-8" 1261 1262 1265 Buddy List at ORG 1266 Liste der Freunde an ORG 1267 1268 Joe Thomas 1269 1270 1271 1272 Mark Edwards 1273 1274 1275 1277 --tuLLl3lDyPZX0GMr2YOo 1278 Content-Transfer-Encoding: binary 1279 Content-ID: 1280 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1282 1283 1285 1286 1287 open 1288 1289 sip:joe@example.org 1290 1291 1293 --tuLLl3lDyPZX0GMr2YOo 1294 Content-Transfer-Encoding: binary 1295 Content-ID: 1296 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1298 1299 1301 1302 1303 closed 1304 1305 1306 1308 --tuLLl3lDyPZX0GMr2YOo-- 1310 --l3WMZaaL8NpQWGnQ4mlU 1311 Content-Transfer-Encoding: binary 1312 Content-ID: 1313 Content-Type: application/pkcs7-signature 1315 [PKCS #7 signature here] 1317 --l3WMZaaL8NpQWGnQ4mlU-- 1319 --TfZxoxgAvLqgj4wRWPDL-- 1321 14. The terminal completes the NOTIFY transaction. 1323 Terminal -> Local RLS 1325 SIP/2.0 200 OK 1326 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1327 From: ;tag=zpNctbZq 1328 To: ;tag=ie4hbb8t 1329 Call-ID: cdB34qLToC@terminal.example.com 1330 CSeq: 997935769 NOTIFY 1331 Contact: 1332 Content-Length: 0 1334 7. Security Considerations 1336 Note that the mechanisms for obtaining state information for 1337 resources in a list are generally left to the RLS implementor. Some 1338 of the security issues below are specific to the the circumstance 1339 that a SIP back-end subscription is used for such a purpose. Non-SIP 1340 mechanisms for obtaining state information of resources in a list 1341 will typically have their own security issues associated with doing 1342 so; however, exhaustively enumerating such access methods is not 1343 possible in this document. Implementors using such mechanisms must 1344 analyze their chosen access methods for relevant security issues. 1346 7.1 Authentication 1348 If back-end subscriptions are required to retrieve resource state 1349 information, the end user is no longer the direct subscriber to the 1350 state of the resource. If the notifier for the resource demands end- 1351 to-end authentication, the RLS will need to be provided appropriate 1352 credentials to access those resources (e.g. shared secrets for 1353 Digest authentication). This requires a certain level of trust 1354 between the user and their RLS. This specification does not describe 1355 any particular means of providing such credentials to the RLS (such 1356 as uploading a shared secret). However, any such upload mechanism 1357 MUST ensure privacy of the key data; using HTTPS [15] to fill out a 1358 form is a reasonable method. Any upload mechanism MUST also seek the 1359 explicit consent of the user before transferring any user secrets 1360 used for authentication. 1362 Open Issue: The IESG has requested that this specification define 1363 or cite a mandatory-to-implement mechanism for transfer of such 1364 credentials. 1366 If the notifier for the resource is using a transitive trust model to 1367 validate the subscriber, then this works well with the RLS concept 1368 and back-end subscriptions. The RLS would authenticate the 1369 subscriber, and then MAY use the SIP extensions for authenticated 1370 identity assertion [8] to provide an authenticated identity to the 1371 notifiers for the resource. 1373 7.2 Risks of Improper Aggregation 1375 A resource list server typically serves information to multiple 1376 subscribers at once. In many cases, resources may be present in 1377 several lists; additionally, it is quite possible that resource list 1378 servers will have two users subscribe to the same list. 1380 In these cases, misguided RLS implementations may attempt to minimize 1381 network load by maintaining only one back-end subscription to a 1382 resource in a list, and presenting the result of such a subscription 1383 to more than one user. Of course, doing so circumvents any 1384 authorization policy that the notifier for the resource maintains. 1385 It is important to keep in mind that authorization is often much more 1386 than a simple binary "allowed/not allowed" decision; resources may 1387 render very different -- and even conflicting -- resource states, 1388 depending on the identity of the subscribing user. 1390 To prevent the transmission of event information to anyone other than 1391 the intended recipient, implementations MUST NOT present the result 1392 of one back-end subscription to more than one user unless: 1394 a. The RLS has adequate access to the complete authorization policy 1395 associated with the resource to which the back-end subscription 1396 has been made, AND 1398 b. The RLS can and has determined that presenting the information to 1399 more than one user does not violate such policy. 1401 Note that this is a very difficult problem to solve correctly. Even 1402 in the cases that such access is believed possible, this mode of 1403 operation is NOT RECOMMENDED. 1405 7.3 Signing and Sealing 1407 Implementors should keep in mind that any section of the MIME body 1408 may be signed and/or encrypted as necessary. Resource List Servers 1409 should take care not to modify any MIME bodies they receive from any 1410 back-end subscriptions, and should not generally rely on being able 1411 to read them. 1413 In order to facilitate security, resource list servers SHOULD pass 1414 along indication for support of "multipart/signed" and "application/ 1415 pkcs7-mime" content types to any SIP back-end subscriptions, if the 1416 subscriber includes them in the initial SUBSCRIBE message. Not doing 1417 so may actually result in resources refusing to divulge state (if 1418 notifier policy requires encryption, but the RLS fails to convey 1419 support), or subscribers discarding valid state (if subscriber policy 1420 requires a signature, but the RLS fails to convey support). 1422 Note that actual implementation of encryption and signing by the RLS 1423 is not necessary to be able to pass through signed and/or encrypted 1424 bodies. 1426 7.4 Infinite Loops 1428 One risk introduced by the ability to nest resource lists is the 1429 possibility of creating lists which ultimately contain themselves as 1430 a sub-list. Detection and handling of such a case is trivial when 1431 the RLS services all of the virtual subscriptions internally. When 1432 back-end subscriptions are created to service virtual subscriptions, 1433 however, detection of such situations becomes a more difficult 1434 problem. 1436 Implementors of RLSes that create back-end subscriptions MUST 1437 implement safeguards to prevent such nestings from creating an 1438 infinite loop of subscriptions. Typically, such mechanisms will 1439 require support in the back-end subscription protocol. In 1440 particular, applying filters to the back-end subscriptions can be an 1441 effective way to preclude such problems. 1443 8. IANA Considerations 1445 8.1 New SIP Option Tag: eventlist 1447 This section defines a new option tag for the registry established by 1448 section 27.1 of RFC 3261[1]. 1450 Option Tag Name: eventlist 1452 Description: Extension to allow subscriptions to lists of resources 1454 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1455 with the RFC number of this document when published]] 1457 8.2 New MIME type for Resource List Meta-Information 1459 MIME Media Type Name: application 1461 MIME subtype name: rlmi+xml 1463 Required parameters: None 1465 Optional parameters: charset 1467 See RFC 3023 [12] for a discussion of the charset parameter on 1468 XML-derived MIME types. Since this MIME type is used exclusively 1469 in SIP, the use of UTF-8 encoding is strongly encouraged. 1471 Encoding considerations: 8-bit text 1473 Security considerations: Security considerations specific to uses of 1474 this this MIME type are discussed in RFC xxxx [[Note to RFC 1475 editor: replace xxxx with the RFC number of this document when 1476 published]]. RFC 1874 [11] and RFC 3023 [12] discuss security 1477 issues common to all uses of XML. 1479 Interoperability considerations: The use of this MIME body is 1480 intended to be generally interoperable. No unique considerations 1481 have been identified. 1483 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1484 with the RFC number of this document when published]] 1486 Applications which use this media type: This media type is used to 1487 convey meta-information for the state of lists of resources within 1488 a Session Initiation Protocol (SIP) subscription. 1490 Additional information: 1492 Magic Number(s): None. 1494 File Extension(s): None. 1496 Macintosh File Type Code(s): None. 1498 Object Identifier(s) or OID(s): None. 1500 Intended usage: Limited Use 1502 Other Information/General Comment: None. 1504 Person to contact for further information: 1506 Name: Adam Roach 1508 E-Mail: adam@estacado.net 1510 Author/Change Controller: The specification of this MIME type is a 1511 work product of the SIMPLE working group, and was authored by 1512 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1513 change control over its specification. 1515 8.3 URN Sub-Namespace 1517 URI: urn:ietf:params:xml:ns:rlmi 1519 Description: This is the XML namespace URI for XML elements defined 1520 by [RFCXXXX] to describe information about subscriptions when such 1521 subscriptions are aggregated within a single SIP subscription. It 1522 is used in the application/rlmi+xml body type. 1524 Registrant Contact: 1526 Name: Adam Roach 1528 E-Mail: adam@estacado.net 1530 Author/Change Controller: The specification of this MIME type is a 1531 work product of the SIMPLE working group, and was authored by 1532 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1533 change control over its specification. 1535 XML: 1537 BEGIN 1538 1539 1541 1542 1543 1545 Namespace for SIP Event Resource List 1546 Meta-Information 1547 1548 1549

Namespace for SIP Event Resource List 1550 Meta-Information

1551

application/rlmi+xml

1552

See 1553 RFCXXXX.

1554 1555 1556 END 1558 9. Acknowledgements 1560 Thanks to Sean Olson for a review of and corrections to the usage of 1561 XML in this protocol. 1563 Thanks also to Hisham Khartabil, Paul Kyzivat, Keith Drage and Robert 1564 Sparks for their careful reviews of and comments on this document. 1566 Normative References 1568 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1569 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1570 Session Initiation Protocol", RFC 3261, June 2002. 1572 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1573 Notification", RFC 3265, June 2002. 1575 [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 1576 Extensions) Part One: Mechanisms for Specifying and Describing 1577 the Format of Internet Message Bodies", RFC 1521, September 1578 1993. 1580 [4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 1581 2387, August 1998. 1583 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1584 Levels", BCP 14, RFC 2119, March 1997. 1586 [6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1587 1766, March 1995. 1589 Non-Normative References 1591 [7] Rosenberg, J., "A Presence Event Package for the Session 1592 Initiation Protocol (SIP)", RFC 3856, August 2004. 1594 [8] Peterson, J., "Enhancements for Authenticated Identity 1595 Management in the Session Initiation Protocol (SIP)", draft- 1596 ietf-sip-identity-03 (work in progress), September 2004. 1598 [9] Olson, S., "A Mechanism for Content Indirection in Session 1599 Initiation Protocol (SIP) Messages", draft-ietf-sip-content- 1600 indirect-mech-04 (work in progress), July 2004. 1602 [10] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 1603 August 2004. 1605 [11] Levinson, E., "SGML Media Types", RFC 1874, December 1995. 1607 [12] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1608 3023, January 2001. 1610 [13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/ 1611 MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 1613 [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security 1614 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 1615 RFC 1847, October 1995. 1617 [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1619 Authors' Addresses 1621 Adam Roach 1622 Estacado Systems 1624 US 1626 EMail: adam@estacado.net 1627 Ben Campbell 1628 Estacado Systems 1630 US 1632 EMail: ben@estacado.net 1634 Jonathan Rosenberg 1635 Cisco Systems 1636 600 Lanidex Plaza 1637 Parsippany, NJ 07054-2711 1638 US 1640 EMail: jdrosen@dynamicsoft.com 1642 Appendix A. Changes 1644 Note that this section will be removed before publication as an RFC. 1646 A.1 Changes since -05 1648 o Added open issue regarding transfer of user secrets to the RLS. 1650 o Removed all references to multipart/encrypted. Replaced with 1651 application/pkcs7-mime, to align with RFC 3261 and RFC 3851. 1653 o Formally restricted state attribute in schema to reflect the three 1654 valid values outlined in the text 1656 o Changed "name" from an attribute to an element for both and 1657 elements. This allows for multiple names to be 1658 present, each with an appropriate language tag. 1660 o Minor editorial updates. 1662 A.2 Changes since -04 1664 o Removed references to P-Asserted-Identity mechanism. 1666 o Removed some leftover cruft from the section on constructing 1667 coherent resource state. 1669 A.3 Changes since -03 1671 o Changed Content-Encoding in examples from 8bit to binary. 1673 o Adjusted formatting to comply with RFC 2223. 1675 A.4 Changes since -02 1677 o Added discussion in security section about infinite loops. 1679 o Fixed several places where the document said "one or more" instead 1680 of "zero or more", when referring to the number of resources that 1681 can appear in a list and the number of instances that can appear 1682 in a resource. 1684 o Tiny editorial cleanup (mostly spelling gaffes). 1686 A.5 Changes since -01 1688 o Several editorial updates. Change "collection" to "list" 1689 everywhere. 1691 o Added terminology section. 1693 o Added restriction that cid attributes can only point to documents 1694 at the same level as the RLMI document in which they appear. 1696 o Clarified description of how to construct resource state by 1697 splitting discussion of full state notifications apart from 1698 discussion of partial-state notifications. 1700 A.6 Changes since -00 1702 o Removed text in several places which went into detail about 1703 specific implementations which used SIP SUB/NOT for back-end 1704 subscriptions. Some of this text will probably be published later 1705 as part of an implementors' guide. 1707 o Removed specific semantics for "Event" header field parameters and 1708 SUBSCRIBE bodies. These will be defined on a per-package basis, 1709 probably by the filtering work. 1711 o Added "cid" attribute to elements. 1713 o Reworked XML schema definition for meta-information. 1715 o Added IANA registration for XML namespace. 1717 o Minor editorial fixes 1719 Appendix B. Intellectual Property Statement 1721 The IETF takes no position regarding the validity or scope of any 1722 intellectual property or other rights that might be claimed to 1723 pertain to the implementation or use of the technology described in 1724 this document or the extent to which any license under such rights 1725 might or might not be available; neither does it represent that it 1726 has made any effort to identify any such rights. 1728 Information on the IETF's procedures with respect to rights in 1729 standards-track and standards-related documentation can be found in 1730 BCP-11. Copies of claims of rights made available for publication 1731 and any assurances of licenses to be made available, or the result of 1732 an attempt made to obtain a general license or permission for the use 1733 of such proprietary rights by implementors or users of this 1734 specification can be obtained from the IETF Secretariat. 1736 The IETF invites any interested party to bring to its attention any 1737 copyrights, patents or patent applications, or other proprietary 1738 rights which may cover technology that may be required to practice 1739 this standard. Please address the information to the IETF Executive 1740 Director. 1742 Full Copyright Statement 1744 Copyright (C) The Internet Society (2004). This document is subject 1745 to the rights, licenses and restrictions contained in BCP 78, and 1746 except as set forth therein, the authors retain all their rights. 1748 This document and the information contained herein are provided on an 1749 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1750 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1751 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1752 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1753 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1754 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1756 Acknowledgement 1758 Funding for the RFC Editor function is currently provided by the 1759 Internet Society.