idnits 2.17.1 draft-ietf-simple-event-list-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 177: '..., any single list subscription MUST be...' RFC 2119 keyword, line 213: '..., and is consequently NOT RECOMMENDED....' RFC 2119 keyword, line 229: '... a handset, it is RECOMMENDED that the...' RFC 2119 keyword, line 237: '...to this specification MUST support the...' RFC 2119 keyword, line 239: '... MUST be included in an Accept heade...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 28, 2003) is 7698 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 1310 == Unused Reference: '3' is defined on line 1360, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1383, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1395, 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 (-10) exists of draft-ietf-simple-presence-07 == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-01 -- Obsolete informational reference (is this intentional?): RFC 3023 (ref. '10') (Obsoleted by RFC 7303) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft J. Rosenberg 4 Expires: September 26, 2003 B. Campbell 5 dynamicsoft 6 March 28, 2003 8 A Session Initiation Protocol (SIP) Event Notification Extension for 9 Collections 10 draft-ietf-simple-event-list-01 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 26, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document presents an extension to the Session Initiation 42 Protocol (SIP)-Specific Event Notification mechanism for subscribing 43 to a homogenous collection of event packages. Instead of the 44 subscriber sending a SUBSCRIBE for each resource individually, the 45 subscriber can subscribe to an entire collection, and then receive 46 notifications when the state of any of the resources in the 47 collection changes. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 53 3. Operation of List Subscriptions . . . . . . . . . . . . . . . 5 54 3.1 Negotiation of Support for Resource Lists . . . . . . . . . . 5 55 3.2 Subscription Duration . . . . . . . . . . . . . . . . . . . . 6 56 3.3 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.4 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 6 58 3.5 Notifier Generation of NOTIFY requests . . . . . . . . . . . . 6 59 3.6 Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 8 60 3.7 Handling of Forked Requests . . . . . . . . . . . . . . . . . 8 61 3.8 Rate of Notifications . . . . . . . . . . . . . . . . . . . . 9 62 3.9 State Agents . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4. Using multipart/related to Convey Aggregate State . . . . . . 10 64 4.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . . 12 67 4.4 Instance Attributes . . . . . . . . . . . . . . . . . . . . . 12 68 4.5 Constructing Coherent Resource State . . . . . . . . . . . . . 13 69 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 71 6.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 28 72 6.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . . 28 73 6.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . . 29 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 75 7.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . . 30 76 7.2 New MIME type for Resource List Meta-Information . . . . . . . 30 77 7.3 URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . . . 31 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 79 Normative References . . . . . . . . . . . . . . . . . . . . . 34 80 Non-Normative References . . . . . . . . . . . . . . . . . . . 35 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35 82 A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 83 A.1 Changes since -00 . . . . . . . . . . . . . . . . . . . . . . 37 84 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 38 86 1. Introduction 88 The SIP-specific event notification mechanism [2] allows a user (the 89 subscriber) to request to be notified of changes in the state of a 90 particular resource. This is accomplished by having the subscriber 91 generate a SUBSCRIBE request for the resource, which is processed by 92 a notifier that represents the resource. In many cases, a subscriber 93 has a collection of resources they are interested in. 95 For environments in which bandwidth is limited, such as wireless 96 networks, subscribing to each resource individually is problematic. 97 Some specific problems are: 99 o Doing so generates substantial message traffic, in the form of the 100 initial SUBSCRIBE requests for each resource, and the refreshes of 101 each individual subscription. 103 o The notifier may insist on low refresh intervals, in order to 104 avoid long lived subscription state. This means that the 105 subscriber may need to generate subscriptions faster than it would 106 like to, or has the capacity to. 108 o The notifier may generate NOTIFY requests more rapidly than the 109 subscriber desires, causing NOTIFY traffic at a greater volume 110 than is desired by the subscriber. 112 To solve these problems, this specification defines an extension that 113 allows for requesting and conveying notifications for collections of 114 resources. A resource list is identified by a URI and it represents 115 a list of zero or more URIs. Each of these URIs is an identifier for 116 an individual resource for which the subscriber wants to receive 117 information. In many cases, the URI will be a SIP URI [1]; however, 118 the use of other schemes (such as pres:) is also forseen. 120 The notifier for the collection is called a "resource list server", 121 or RLS. In order to determine the state of the entire list, the RLS 122 will act as if it has typically generated a subscription to each 123 resource in the list. 125 The resource list is not restricted to be inside the domain of the 126 subscriber. Similarly, the resources in the list are not 127 contstrained to be in the domain of the resource list server. 129 2. Overview of Operation 131 This section provides an overview of the typical mode of operation of 132 this extension. It is not normative. 134 When a user wishes to subscribe to the resource of a list of 135 resources, they create a resource list. This resource list is 136 represented by a SIP URI. The list contains a set of URIs, each of 137 which represents a resource for which the subscriber wants to receive 138 information. The resource list can exist in any domain. Typically, 139 the user who creates the list (and subsequently subscribes to it) 140 will have a trust relationship with the domain that hosts the list. 141 The list could be manipulated through a web page, through a voice 142 response system, or through some other protocol. The specific means 143 by which the list is created and maintained is outside of the scope 144 of this specification. 146 To learn the resource state of the set of elements on the list, the 147 user sends a single SUBSCRIBE request targeted to the URI of the 148 list. This will be routed to an RLS for that URI. The RLS acts as a 149 notifier, authenticates the subscriber, and accepts the subscription. 151 The RLS may have direct information about some or all of the 152 resources specified by the list. If it does not, it could subscribe 153 to any non-local resources specified by the list resource. 155 Note that subscriptions to non-local resources may or may not be SIP 156 subscriptions; any mechanism for determining such information may be 157 employed. This document uses the term "back-end subscription" to 158 refer to such a subscription, regardless of whether SIP is used to 159 establish and service them. 161 As the state of resources in the list change, the RLS generates 162 notifications to the list subscribers. The RLS can, at its 163 discretion, buffer notifications of resource changes, and send the 164 resource information to the subscriber in batches, rather than 165 individually. This allows the RLS to provide rate limiting for the 166 subscriber. 168 The list notifications contain a body of type multipart/related. The 169 root section of the multipart/related content is an XML document that 170 provides meta-information about each resource present in the list. 171 The remaining sections contain the actual state information for each 172 resource. 174 3. Operation of List Subscriptions 176 A list subscription acts, in many ways, like an event template 177 package. In particular, any single list subscription MUST be 178 homogenous with respect to the underlying event package. In other 179 words, a single list subscription cannot contain subscriptions to 180 different kinds of event packages. 182 The key difference between a list subscription and templates in 183 general is that support for list subscriptions indicates support for 184 arbitrary nesting of list subscriptions. In other words, elements 185 within the list may be atomic elements, or they may be lists 186 themselves. 188 The consequence of this is that subscription to a URI that represents 189 a list actually results in a virtual subscription to a tree of 190 resources. The leaf nodes of this tree are virtual subscriptions of 191 the event type given in the "Event" header; all other nodes in the 192 tree are list subscriptions that are serviced as described in this 193 section and its subsections. 195 It is important to keep in mind that these virtual subscriptions are 196 not literal SIP subscriptions (although they may result in SIP 197 subscriptions, depending on the RLS implementation). 199 3.1 Negotiation of Support for Resource Lists 201 This specification uses the SIP option tag mechanism for negotiating 202 support of the extension defined herein. Refer to RFC3261 [1] for 203 the normative description of processing of the "Supported" and 204 "Require" headers and the 421 (Extension Required) response code. 206 Any client that supports the event list extension will include an 207 option tag of "eventlist" in a "Supported" header of every SUBSCRIBE 208 message for a subscription for which it is willing to process a list. 209 If the subscription is made to a URI that represents a list, the RLS 210 will include "eventlist" in a "Require" header of the response to the 211 SUBSCRIBE, and in all NOTIFY messages within that subscription. Note 212 that including "eventlist" in a "Require" header in a SUBSCRIBE 213 request serves no purpose, and is consequently NOT RECOMMENDED. 215 As described in RFC3265 [2], a subscription to a particular state of 216 a resource is identified by the Request-URI and the event package 217 used. Because it is quite reasonable for an RLS to contain a 218 resource that is inherently a list (e.g. 219 "sip:buddylist@example.com"), it is perfectly reasonable to expect 220 that RLSes will return a 421 (Extension Required) response code if 221 the "eventlist" option tag is not indicated in a request to subscribe 222 to that resource. Because of the forgoing situation, this 223 specification relaxes the "NOT RECOMMENED" provision described in 224 RFC3261 [1], section 8.2.4 for the extension described herein. 226 3.2 Subscription Duration 228 Since the primary benefit of the resource list server is to reduce 229 the overall messaging volume to a handset, it is RECOMMENDED that the 230 subscription duration to a list be reasonably long. The default, 231 when no duration is specified, is taken from the underlying event 232 package. Of course, the standard techniques [2] can be used to 233 increase or reduce this amount. 235 3.3 NOTIFY Bodies 237 An implementation compliant to this specification MUST support the 238 multipart/related and application/rlmi+xml MIME types. These types 239 MUST be included in an Accept header sent in SUBSCRIBE message, in 240 addition to any other types supported by the client. 242 3.4 Notifier Processing of SUBSCRIBE Requests 244 All subscriptions for resource lists SHOULD be authenticated. The 245 use of the SIP HTTP Digest mechanism [1] over TLS is RECOMMENDED. 247 Once the subscriber is authenticated, the RLS performs authorization 248 per its local policy. In many cases, each resource list is 249 associated with a particular user (the one who created it and manages 250 the set of elements in it), and only that user will be allowed to 251 subscribe. Of course, this mode of operation is not inherent in the 252 use of resource lists, and a notifier can use any authorization 253 policy it chooses. 255 3.5 Notifier Generation of NOTIFY requests 257 This specification leaves the choice about how and when to generate 258 NOTIFY requests at the discretion of the implementor. One of the 259 value propositions of the RLS is the means by which it aggregates, 260 rate limits, or optimizes the way in which notifications are 261 generated. As a baseline behavior, the RLS MAY generate a NOTIFY to 262 the RLS subscriber whenever the state of any resource on the list 263 changes. 265 See Section 4 for a detailed definition of the syntax used to convey 266 resource lists. For the purposes of the following discussion, it is 267 important to know that the overall list contains one or more 268 resources, and that the resources contains one or more instances of 269 the resource. Each instance of the resource has a state associated 270 with it (pending, active, or terminating), representing the state of 271 the subscription. 273 Notifications contain a multipart document, the first part of which 274 always contains meta-information about the list (e.g. membership, 275 state of the virtual subscription to the resource). Remaining parts 276 are used to convey the actual state of the resources listed in the 277 meta-information. 279 The "state" attribute of each instance of a resource in the meta- 280 information is set according to the state of the virtual 281 subscription. The meanings of the "state" attribute are described in 282 RFC 3265 [2]. 284 If an instance of a resource was previously reported to the 285 subscriber but is no longer available (i.e. the virtual subscription 286 to that instance has been terminated), the resource list server 287 SHOULD include that resource instance in the meta-information in the 288 first NOTIFY message sent to the subscriber following the instance's 289 unavailability. The RLS MAY continue to do so for future 290 notifications. 292 When sending information for a terminated resource instance, the RLS 293 indicates a state of "terminated" and an appropriate reason value. 294 Valid reason values and their meanings are described in RFC 3265 [2]. 295 If the RLS will attempt to recover the resource state again at some 296 point in the future (e.g. when the reason in the meta-informaion is 297 "probation"), then the instance of the resource SHOULD remain in the 298 meta-information until the instance state is available, or until the 299 RLS gives up on making such state available. 301 When the first SUBSCRIBE message for a particular subscription is 302 received by a resource list notifier, the notifier will often not 303 know state information for all of the resources specified by the 304 resource list. For any resource for which state information is not 305 known, the corresponding "uri" attribute will be set appropriately, 306 and no elements will be present for the resource. 308 For an initial notification, sections corresponding to resources for 309 which the resource list notifier does have state will be populated 310 with appropriate data (subject, of course, to local policy 311 decisions). This will often occur if the resource list server is 312 colocated with the server for one or more of the resources specified 313 on the list. 315 Immediate notifications triggered as a result of subsequent SUBSCRIBE 316 messages SHOULD result in full meta-information about the list of 317 resources. The RLS SHOULD also include state information for all 318 resources in the list for which the RLS has state, subject to policy 319 restrictions. This allows the subscriber to refresh their state, and 320 to recover from lost notifications. 322 Note that a consequence of the way in which resource list 323 subscriptions work, polling of resource state will often not be 324 particularly useful. While such polls will retrieve the resource 325 list (and potentially even some of the states if a resource on the 326 list is colocated with the resource list server), they will often not 327 contain state for some or all of the resources on the list. 329 3.6 Subscriber Processing of NOTIFY Requests 331 Notifications for a resource list can convey information about a 332 subset of the list elements. This means that an explicit algorithm 333 needs to be defined in order to construct coherent and consistent 334 state. 336 The XML document present in the root of the multipart/related 337 document contains a element for each resource in the list. 338 Each element contains a URI which uniquely identifies the 339 resource to which that section corresponds. When a NOTIFY arrives, 340 it can contain full or partial state (as indicate by the "fullState" 341 attribute of the top-level element). If full state is 342 indicated, then the recipient replaces all state associated with the 343 list with the entities in the NOTIFY body. If full state is not 344 indicated, the recipient of the NOTIFY updates information for each 345 identified resource. Information for any resources that are not 346 identified in the NOTIFY are not changed, even if they were indicated 347 in previous NOTIFY mesages. See section Section 4.5 for more 348 information. 350 Note that the underlying event package may have its own rules for 351 compositing partial state notification. When processing data related 352 to those packages, their rules apply (i.e. the fact that they were 353 reported as part of a collection does not change their partial 354 notification semantics). 356 3.7 Handling of Forked Requests 358 Forking makes little sense with subscriptions to event lists, since 359 the whole idea is a centralization of the source of notifications. 360 Therefore, a subscriber MUST create just a single dialog as a result 361 of a single subscription request, using the techniques described in 362 RFC 3265[2]. 364 3.8 Rate of Notifications 366 One potential role of the RLS is to perform rate limitations on 367 behalf of the subscriber. As such, this specification does not 368 mandate any particular rate limitation, and rather leaves that to the 369 discretion of the implementation. 371 3.9 State Agents 373 Effectively, a resource list server is nothing more than a state 374 agent for the resource event type. 376 The usage of an RLS does introduce some security considerations. The 377 end user is no longer the direct subscriber to the state of the 378 resource. If the notifier for the resource demands end-to-end 379 authentication, the RLS will need to be provided appropriate 380 credentials to access those resources (e.g. shared secrets for 381 Digest authentication). This requires a certain level of trust 382 between the user and their RLS. This specification does not describe 383 any particular means of providing such credentials to the RLS (such 384 as uploading a shared secret). However, any such upload mechanism 385 MUST ensure privacy of the key data; using HTTPS to fill out a form 386 is a reasonable method. 388 If the notifier for the resource is using a transitive trust model to 389 validate the subscriber, then this works well with the RLS concept. 390 The RLS would authenticate the subscriber, and then MAY use the SIP 391 extensions for network asserted identity (see [6] and [7]) to provide 392 an authenticated identity to any downstream servers. It is even 393 conceivable that the subscriber may provide an authenticated ID in 394 its original subscribe request for use by the RLS for the dual 395 purpose of local authentication and use in any generated SUBSCRIBE 396 messages. 398 4. Using multipart/related to Convey Aggregate State 400 In order to convey the state of multiple resources, the list template 401 package uses the "multipart/related" mime type. The syntax for 402 multipart/related is defined in "The MIME Multipart/Related Content- 403 type" [4]. 405 4.1 XML Syntax 407 The root document of the multipart/related body is always a Resource 408 List Meta-Information (RLMI) document. It is of type "application/ 409 rlmi+xml". This document containes the meta-information for the 410 resources contained in the notification. The schema for this XML 411 document is given below. 413 414 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 446 447 448 449 450 451 452 453 454 456 An example of a document formatted using this schema follows. 458 460 461 462 463 464 465 466 467 468 469 470 471 472 474 4.2 List Attributes 476 The element present in a list notification MUST contain three 477 attributes. 479 The first mandatory attribute is "uri", which contains the uri 480 that corresponds to the list. Typically, this is the URI to which 481 the SUBSCRIBE request was sent. 483 The second mandatory attribute is "version", which contains a 484 number from 0 to 2^32-1. This version number MUST be 0 for the first 485 NOTIFY message sent within a subscription (typically in response to a 486 SUBSCRIBE request), and MUST increase by exactly one for each 487 subsequent NOTIFY sent within a subscription. 489 The third mandatory attribute is "fullState". The "fullState" 490 attribute indicates whether the NOTIFY message contains information 491 for every resource in the collection. If it does, the value of the 492 attribute is "true" (or "1"); otherwise, it is "false" (or "0"). 493 Note that the first NOTIFY sent in a subscription MUST contain full 494 state, as must the first NOTIFY sent after receipt of a SUBSCRIBE 495 request for the subscription. 497 The optional "name" attribute can contain a human readable 498 description or name for the resource list. This attribute is 499 somewhat analogous to the "Display Name" present in the SIP name-addr 500 element. 502 Finally, elements may contain a "cid" attribute. If present, 503 the "cid" attribute identifies a section within the multipart/related 504 body that contains aggregate state information for the resources 505 contained in the list. The definition of such aggregate information 506 is outside the scope of this document, and will be defined on a per- 507 package basis as needed. The cid attribute is the Content-ID for the 508 corresponding section in the multipart body. 510 4.3 Resource Attributes 512 The resource list contains one element for each resource 513 being reported in the notification. These resource elements contain 514 attributes that identify meta-data assocated with each resource. 516 The "uri" attribute identifies the resource to which the 517 element corresponds. Typically, this will be a SIP URI which, if 518 subscribed to, would return the state of the resource. This 519 attribute must be present. 521 The optional "name" attribute can contain a human readable 522 description or name for the resource. This attribute is somewhat 523 analogous to the "Display Name" present in the SIP name-addr element. 525 4.4 Instance Attributes 527 Each resource element contains one or more instance elements. These 528 instance elements are used to represent a single notifier for the 529 resource. For event packages that allow forking, multiple virtual 530 subscriptions may exist for a given resource. Multiple virtual 531 subscriptions are represented as multiple instance elements in the 532 corresponding resource element. For subscriptions in which forking 533 does not occur, at most one instance will be present for a given 534 resource. 536 The "id" attribute contains an opaque string used to uniquely 537 identify the instance of the resource. The "id" attribute is unique 538 only within the context of a resource. Composition of this string is 539 an implementation decision. Any mechanism for generating this string 540 is valid, as long as uniqueness within the resource is assured. 542 The "state" attribute contains the subscription state for the 543 identified instance of the resource. This attribute contains one of 544 the values "active", "pending", or "terminated". The meanings for 545 these values are as defined for the "Subscription-State" header in 546 RFC 3265 [2]. 548 If the "state" attribute indicates "terminated", then a "reason" 549 attribute MUST also be present. This "reason" attribute has the same 550 values and meanings as given for the "reason" parameter on the 551 "Subscription-State" header in RFC 3265 [2]. Note that the reason is 552 included for informational purposes; the list subscriber is not 553 expected to take any automated actions based on the reason value. 555 Finally, the "cid" attribute, which must be present if the "state" 556 attribute is "active", identifies the section within the multipart/ 557 related body that contains the actual resource state. This state is 558 expressed in the content type defined by the event package for 559 conveying state. The cid attribute is the Content-ID for the 560 corresponding section in the multipart body. 562 Note that the subscription durations of any back-end subscriptions 563 are not propagated into the meta-information state in any way. 565 4.5 Constructing Coherent Resource State 567 The resource list subscriber maintains a table for each resource 568 list. The table contains a row for each resource in the resource 569 list. Each row is indexed by the URI for that resource. That URI is 570 obtained from the "uri" attribute on each element. The 571 contents of each row contain the state of that resource as conveyed 572 in the resource document. 574 For resources that provide versioning information (which is mandated 575 by [2] for any formats that allow partial notification), each row 576 also contains a resource state version number. The version number of 577 the row is initialized with the version specified in the first 578 document received, as defined by the corrsponding event package. 579 This value is used when comparing versions of partial notifications 580 for a resource. 582 The processing of the resource list notification depends on whether 583 it contains full or partial state. If it contains full state, 584 indicated by the value of the attribute "fullState", the 585 contents of the resource-list table are flushed. They are 586 repopulated from the document. A new row in the table is created for 587 each "resource" element. 589 First, a check is made to ensure that no list notifications have been 590 lost. The value of the local version number (the "version" attribute 591 of the element) is compared to the version number of the new 592 document. 594 o If the value in the new document is exactly one higher than the 595 local version number, the local version number is increased by 596 one, and the document is processed, as described below. 598 o If the version in the document is more than one higher than the 599 local version number, the local version number is set to the value 600 in the new document, and the document is processed as described 601 below. Further, if the notification does not contain full state 602 (as indicated by the "fullState" attribute of the element), 603 the list subscriber SHOULD generate a refresh request to trigger a 604 full state notification. 606 o If the version in the document is less than or equal to the local 607 version, the document is discarded without any further processing. 609 If the resource list document contains partial state, the 610 notification is used to update the table. For each resource listed 611 in the document, the subscriber checks to see whether a row exists 612 for that resource. This check is done by comparing the Resource-URI 613 value with the URI associated with the row. If the resource doesn't 614 exist in the table, a row is added, and its state is set to the 615 information from that "resource" element. If the resource does 616 exist, its state is updated to be the information from that 617 "resource" element, as described in the definition of the event 618 package. If a row is updated or created such that its state is now 619 "terminated," that entry MAY be removed from the table at any time. 621 5. Example 623 This section gives an example callflow. It is not normative. If a 624 conflict arises between this callflow and the normative behavior 625 described in this or any other document, the normative descriptions 626 are to be followed. 628 In this particular example, we request a subscription to a nested 629 presence list. The subscriber's address-of-record is 630 "sip:adam@example.com", and the name of the nested list resource that 631 we are subscribing to is called "sip:adam-buddies@pres.example.com". 632 The underlying event package is "presence", described by [5]. 634 In this example, the RLS has information to service some of the 635 resources on the list, but must consult other servers to retrive 636 information for others. The implementation of the RLS in this 637 example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such 638 information. 640 1. We initate the subscription by sending a SUBSCRIBE message to 641 our local RLS. (There is no reason that the RLS we contact has 642 to be in our domain, of course). Note that we must advertise 643 support for application/rlmi+xml and multipart/related because 644 we support the eventlist extension, and we must advertise 645 application/cpim-pidf+xml because we are requesting a 646 subscription to a list. 648 Terminal -> Local RLS 650 SUBSCRIBE sip:adam-buddies@pres.example.com SIP/2.0 651 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 652 Max-Forwards: 70 653 To: 654 From: ;tag=ie4hbb8t 655 Call-ID: cdB34qLToC@terminal.example.com 656 CSeq: 322723822 SUBSCRIBE 657 Contact: 658 Event: presence 659 Expires: 7200 660 Supported: eventlist 661 Accept: application/cpim-pidf+xml 662 Accept: application/rlmi+xml 663 Accept: multipart/related 664 Accept: multipart/signed 665 Accept: multipart/encrypted 666 Content-Length: 0 667 2. The Local RLS completes the SUBSCRIBE transaction. Note that 668 authentication and authorization would normally take place at 669 this point in the callflow. Those steps are omitted for 670 brevity. 672 Local RLS -> Terminal 674 SIP/2.0 200 OK 675 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 676 To: ;tag=zpNctbZq 677 From: ;tag=ie4hbb8t 678 Call-ID: cdB34qLToC@terminal.example.com 679 CSeq: 322723822 SUBSCRIBE 680 Contact: 681 Expires: 7200 682 Require: eventlist 683 Content-Length: 0 685 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY 686 immediately upon accepting the subscription. In this example, 687 we are asserting that the local RLS is also an authority for 688 presence information for the users in the "example.com" domain. 689 The NOTIFY contains an RLMI document describing the entire buddy 690 list (initial notifies require full state), as well as presence 691 information for the users about which it already knows. Note 692 that, since the RLS has not yet retrieved information for some 693 of the entries on the list, those elements contain no 694 elements. 696 Local RLS -> Terminal 698 NOTIFY sip:terminal.example.com SIP/2.0 699 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 700 Max-Forwards: 70 701 From: ;tag=zpNctbZq 702 To: ;tag=ie4hbb8t 703 Call-ID: cdB34qLToC@terminal.example.com 704 CSeq: 997935768 NOTIFY 705 Contact: 706 Event: presence 707 Subscription-State: active;expires=7200 708 Require: eventlist 709 Content-Type: multipart/related;type="application/rlmi+xml"; 710 start="";boundary="50UBfW7LSCVLtggUPe5z" 711 Content-Length: 1560 712 --50UBfW7LSCVLtggUPe5z 713 Content-Transfer-Encoding: 8bit 714 Content-ID: 715 Content-Type: application/rlmi+xml;charset="UTF-8" 717 718 720 721 722 723 724 725 726 727 728 730 --50UBfW7LSCVLtggUPe5z 731 Content-Transfer-Encoding: 8bit 732 Content-ID: 733 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 735 736 738 739 740 open 741 742 sip:bob@example.com 743 744 746 --50UBfW7LSCVLtggUPe5z 747 Content-Transfer-Encoding: 8bit 748 Content-ID: 749 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 751 752 754 755 756 closed 757 758 759 760 --50UBfW7LSCVLtggUPe5z-- 762 4. The terminal completes the transaction. 764 Terminal -> Local RLS 766 SIP/2.0 200 OK 767 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm 768 From: ;tag=zpNctbZq 769 To: ;tag=ie4hbb8t 770 Call-ID: cdB34qLToC@terminal.example.com 771 CSeq: 997935768 NOTIFY 772 Contact: 773 Content-Length: 0 775 5. In order to service the subscription, the local RLS subscribes 776 to the state of the resources. In this step, the RLS attempts 777 to subscribe to the presence state of the resource 778 "sip:ed@example.com". Since the local RLS knows how to receive 779 notifications for list subscriptions, it includes the 780 "Supported: eventlist" header in its request. Although the 781 linkage between this subscription and the one sent by the 782 terminal is left up to the application, this message 783 demonstrates some reasonable behavior by including "Accept" 784 headers for all of the body types it knows the subscriber 785 (Terminal) supports. This is safe to do, since the local RLS 786 will only pass these formats through to the subscriber, and does 787 not need to actually understand them. 789 Local RLS -> Presence Server in example.net 791 SUBSCRIBE sip:ed@example.net SIP/2.0 792 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 793 Max-Forwards: 70 794 To: 795 From: ;tag=aM5icQu9 796 Call-ID: Ugwz5ARxNw@pres.example.com 797 CSeq: 870936068 SUBSCRIBE 798 Contact: 799 Event: presence 800 Expires: 3600 801 Supported: eventlist 802 Accept: application/cpim-pidf+xml 803 Accept: application/rlmi+xml 804 Accept: multipart/related 805 Accept: multipart/signed 806 Accept: multipart/encrypted 807 Content-Length: 0 809 6. The Presence Server in example.net completes the SUBSCRIBE 810 transaction. Note that authentication and would normally take 811 place at this point in the callflow. Those steps are omitted 812 for brevity. 814 Presence Server in example.net -> Local RLS 816 SIP/2.0 200 OK 817 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH 818 To: ;tag=e45TmHTh 819 From: ;tag=aM5icQu9 820 Call-ID: Ugwz5ARxNw@pres.example.com 821 CSeq: 870936068 SUBSCRIBE 822 Contact: 823 Event: presence 824 Expires: 3600 825 Content-Length: 0 827 7. In this example, we assume that the server at example.net 828 doesn't have enough authorization information to reject or 829 accept our subscription. The initial notify, therefore, 830 contains a "Subscription-State" of "pending". Presumably, the 831 party responsible for accepting or denying authorization for the 832 resource is notified of this change; however, those steps are 833 not included in this call flow for brevity. 835 Presence Server in example.net -> Local RLS 837 NOTIFY sip:pres.example.com SIP/2.0 838 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKfwpklPxmrW 839 Max-Forwards: 70 840 From: ;tag=e45TmHTh 841 To: ;tag=aM5icQu9 842 Call-ID: Ugwz5ARxNw@pres.example.com 843 CSeq: 1002640632 NOTIFY 844 Contact: 845 Subscription-State: pending;expires=3600 846 Event: presence 847 Require: eventlist 848 Content-Length: 0 850 8. The local RLS completes the NOTIFY transaction. Note that, at 851 this point, the Local RLS has new information to report to the 852 subscriber. Whether it chooses to report the information 853 immediately or spool it up for later delivery is completely up 854 to the application. For this example, we assume that the RLS 855 will wait for a short period of time before doing so, in order 856 to allow the subscriptions it sent out sufficient time to 857 provide useful data. 859 Local RLS -> Presence Server in example.net 861 SIP/2.0 200 OK 862 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKfwpklPxmrW 863 From: ;tag=e45TmHTh 864 To: ;tag=aM5icQu9 865 Call-ID: Ugwz5ARxNw@pres.example.com 866 CSeq: 1002640632 NOTIFY 867 Contact: 868 Event: presence 869 Content-Length: 0 871 9. The Local RLS subscribes to the state of the other non-local 872 resource. 874 Local RLS -> RLS in example.org 876 SUBSCRIBE sip:adam-friends@example.org SIP/2.0 877 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 878 Max-Forwards: 70 879 To: 880 From: ;tag=a12eztNf 881 Call-ID: kBq5XhtZLN@pres.example.com 882 CSeq: 980774491 SUBSCRIBE 883 Contact: 884 Event: presence 885 Expires: 3600 886 Supported: eventlist 887 Accept: application/cpim-pidf+xml 888 Accept: application/rlmi+xml 889 Accept: multipart/related 890 Accept: multipart/signed 891 Accept: multipart/encrypted 892 Content-Length: 0 894 10. The RLS in example.org completes the SUBSCRIBE transaction. 895 Note that authentication and would normally take place at this 896 point in the callflow. Those steps are omitted for brevity. 898 RLS in example.org -> Local RLS 900 SIP/2.0 200 OK 901 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL 902 To: ;tag=JenZ40P3 903 From: ;tag=a12eztNf 904 Call-ID: kBq5XhtZLN@pres.example.com 905 CSeq: 980774491 SUBSCRIBE 906 Contact: 907 Event: presence 908 Expires: 3600 909 Content-Length: 0 911 11. In this example, we are asserting that the RLS in example.org is 912 also an authority for presence information for the users in the 913 "example.org" domain. The NOTIFY contains an RLMI document 914 describing the contained buddy list, as well as presence 915 information for those users. In this particular case, the RLS 916 in example.org has chosen to PGP sign [11] the body of the 917 NOTIFY message. 919 RLS in example.org -> Local RLS 921 NOTIFY sip:pres.example.com SIP/2.0 922 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKmGL1nyZfQI 923 Max-Forwards: 70 924 From: ;tag=JenZ40P3 925 To: ;tag=a12eztNf 926 Call-ID: kBq5XhtZLN@pres.example.com 927 CSeq: 294444656 NOTIFY 928 Contact: 929 Event: presence 930 Subscription-State: pending 931 Require: eventlist 932 Content-Type: multipart/signed;protocol="application/pgp-signature"; 933 micalc="pgp-md5";boundary="l3WMZaaL8NpQWGnQ4mlU" 934 Content-Length: 2038 936 --l3WMZaaL8NpQWGnQ4mlU 937 Content-Transfer-Encoding: 8bit 938 Content-ID: 939 Content-Type: multipart/related;type="application/rlmi+xml"; 940 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 942 --tuLLl3lDyPZX0GMr2YOo 943 Content-Transfer-Encoding: 8bit 944 Content-ID: 945 Content-Type: application/rlmi+xml;charset="UTF-8" 947 948 950 951 952 953 954 955 956 958 --tuLLl3lDyPZX0GMr2YOo 959 Content-Transfer-Encoding: 8bit 960 Content-ID: 961 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 963 964 966 967 968 open 969 970 sip:joe@example.org 971 972 974 --tuLLl3lDyPZX0GMr2YOo 975 Content-Transfer-Encoding: 8bit 976 Content-ID: 977 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 979 980 982 983 984 closed 985 986 987 989 --tuLLl3lDyPZX0GMr2YOo-- 991 --l3WMZaaL8NpQWGnQ4mlU 992 Content-Transfer-Encoding: 8bit 993 Content-ID: 994 Content-Type: application/pgp-signature 996 -----BEGIN PGP MESSAGE----- 997 Version: 2.6.2 999 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 1000 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 1001 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 1002 HOxEa44b+EI= 1003 =ndaj 1004 -----END PGP MESSAGE----- 1006 --l3WMZaaL8NpQWGnQ4mlU-- 1008 12. The Local RLS completes the NOTIFY transaction. 1010 Local RLS -> RLS in example.org 1012 SIP/2.0 200 OK 1013 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKmGL1nyZfQI 1014 From: ;tag=JenZ40P3 1015 To: ;tag=a12eztNf 1016 Call-ID: kBq5XhtZLN@pres.example.com 1017 CSeq: 294444656 NOTIFY 1018 Contact: 1019 Event: presence 1020 Content-Length: 0 1022 13. At this point, the Local RLS decides it has collected enough 1023 additional information to warrant sending a new notification to 1024 the user. Although sending a full notification would be 1025 perfectly acceptable, the RLS decides to send a partial 1026 notification instead. The RLMI document contains only 1027 information for the updated resources, as indicated by setting 1028 the "fullState" parameter to "false". 1030 Local RLS -> Terminal 1032 NOTIFY sip:terminal.example.com SIP/2.0 1033 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1034 Max-Forwards: 70 1035 From: ;tag=zpNctbZq 1036 To: ;tag=ie4hbb8t 1037 Call-ID: cdB34qLToC@terminal.example.com 1038 CSeq: 997935769 NOTIFY 1039 Contact: 1040 Event: presence 1041 Subscription-State: active;expires=7200 1042 Require: eventlist 1043 Content-Type: multipart/related;type="application/rlmi+xml"; 1044 start="<2BEI83@pres.example.com>";boundary="TfZxoxgAvLqgj4wRWPDL" 1045 Content-Length: 2862 1047 --TfZxoxgAvLqgj4wRWPDL 1048 Content-Transfer-Encoding: 8bit 1049 Content-ID: <2BEI83@pres.example.com> 1050 Content-Type: application/rlmi+xml;charset="UTF-8" 1052 1053 1055 1056 1057 1058 1059 1060 1061 1063 --TfZxoxgAvLqgj4wRWPDL 1064 Content-Transfer-Encoding: 8bit 1065 Content-ID: <1KQhyE@pres.example.com> 1066 Content-Type: multipart/signed;protocol="application/pgp-signature"; 1067 micalc="pgp-md5";boundary="l3WMZaaL8NpQWGnQ4mlU" 1069 --l3WMZaaL8NpQWGnQ4mlU 1070 Content-Transfer-Encoding: 8bit 1071 Content-ID: 1072 Content-Type: multipart/related;type="application/rlmi+xml"; 1073 start="";boundary="tuLLl3lDyPZX0GMr2YOo" 1075 --tuLLl3lDyPZX0GMr2YOo 1076 Content-Transfer-Encoding: 8bit 1077 Content-ID: 1078 Content-Type: application/rlmi+xml;charset="UTF-8" 1080 1081 1083 1084 1085 1086 1087 1088 1089 1091 --tuLLl3lDyPZX0GMr2YOo 1092 Content-Transfer-Encoding: 8bit 1093 Content-ID: 1094 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1096 1097 1099 1100 1101 open 1102 1103 sip:joe@example.org 1105 1106 1108 --tuLLl3lDyPZX0GMr2YOo 1109 Content-Transfer-Encoding: 8bit 1110 Content-ID: 1111 Content-Type: application/cpim-pidf+xml;charset="UTF-8" 1113 1114 1116 1117 1118 closed 1119 1120 1121 1123 --tuLLl3lDyPZX0GMr2YOo-- 1125 --l3WMZaaL8NpQWGnQ4mlU 1126 Content-Transfer-Encoding: 8bit 1127 Content-ID: 1128 Content-Type: application/pgp-signature 1130 -----BEGIN PGP MESSAGE----- 1131 Version: 2.6.2 1133 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 1134 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 1135 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 1136 HOxEa44b+EI= 1137 =ndaj 1138 -----END PGP MESSAGE----- 1140 --l3WMZaaL8NpQWGnQ4mlU-- 1142 --TfZxoxgAvLqgj4wRWPDL-- 1144 14. The terminal completes the NOTIFY transaction. 1146 Terminal -> Local RLS 1148 SIP/2.0 200 OK 1149 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 1150 From: ;tag=zpNctbZq 1151 To: ;tag=ie4hbb8t 1152 Call-ID: cdB34qLToC@terminal.example.com 1153 CSeq: 997935769 NOTIFY 1154 Contact: 1155 Content-Length: 0 1157 6. Security Considerations 1159 Note that the mechanisms for obtaining state information for 1160 resources in a list are generally left to the RLS implementor. Some 1161 of the security issues below are specific to the the circumstance 1162 that a SIP back-end subscription is used for such a purpose. Non-SIP 1163 mechanisms for obtaining state information of resources in a list 1164 will typically have their own security issues associated with doing 1165 so; however, exhaustively enumerating such access methods is not 1166 possible in this document. Implementors using such mechanisms must 1167 analyse their chosen access methods for relevant security issues. 1169 6.1 Authentication 1171 The usage of the RLS does introduce some security considerations. If 1172 back-end subscriptions are required to retrieve resource state 1173 information, the end user is no longer the direct subscriber to the 1174 state of the resource. If the notifier for the resource demands end- 1175 to-end authentication, the RLS will need to be provided appropriate 1176 credentials to access those resources (e.g. shared secrets for 1177 Digest authentication). This requires a certain level of trust 1178 between the user and their RLS. This specification does not describe 1179 any particular means of providing such credentials to the RLS (such 1180 as uploading a shared secret). However, any such upload mechanism 1181 MUST ensure privacy of the key data; using HTTPS to fill out a form 1182 is a reasonable method. 1184 If the notifier for the resource is using a transitive trust model to 1185 validate the subscriber, then this works well with the RLS concept 1186 and back-end subscriptions. The RLS would authenticate the 1187 subscriber, and then MAY use the SIP extensions for network asserted 1188 identity [6][7] to provide an authenticated identity to the notifiers 1189 for the resource. 1191 6.2 Risks of Improper Aggregation 1193 A resource list server typically serves information to multiple 1194 subscribers at once. In many cases, resources may be present in 1195 several lists; additionally, it is quite possible that resource list 1196 servers will have two users subscribe to the same list. 1198 In these cases, misguided RLS implementations may attempt to minimize 1199 network load by maintaining only one back-end subscription to a 1200 resource in a list, and presenting the result of such a subscription 1201 to more than one user. Of course, doing so circumvents any 1202 authorization policy that the notifier for the resource maintains. 1203 It is important to keep in mind that authorization is often much more 1204 than a simple binary "allowed/not allowed" decision; resources may 1205 render very different -- and even conflicting -- resource states, 1206 depending on the identity of the subscribing user. 1208 Implementations MUST NOT attempt to perform this type of optimization 1209 unless adequate access to complete authorizaton policy can be 1210 guaranteed. Note that this is a very difficult problem to solve 1211 correctly; even in the cases that such access is beleived possible, 1212 this mode of operation is NOT RECOMMENDED. 1214 6.3 Signing and Sealing 1216 Implementors should keep in mind that any section of the MIME body 1217 may be signed and/or encrypted as necessary. Resource List Servers 1218 should take care not to modify any MIME bodies they receive from any 1219 back-end subscriptions, and should not generally rely on being able 1220 to read them. 1222 In order to facilitate security, resource list servers SHOULD pass 1223 along indication for support of "multipart/signed" and "multipart/ 1224 encrypted" content types to any SIP back-end subscriptions, if the 1225 subscriber includes them in the initial SUBSCRIBE message. Not doing 1226 so may actually result in resources refusling to divulge state (if 1227 notifier policy requires encryption, but the RLS fails to convey 1228 support), or subscribers discarding valid state (if subscriber policy 1229 requires a signature, but the RLS fails to convey support). 1231 Note that actual implemetation of encryption and signing by the RLS 1232 is not necessary to be able to pass through signed and/or encrypted 1233 bodies. 1235 7. IANA Considerations 1237 7.1 New SIP Option Tag: eventlist 1239 Option Tag Name: eventlist 1241 Description: Extension to allow subscriptions to collections of 1242 resources 1244 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1245 with the RFC number of this document when published]] 1247 7.2 New MIME type for Resource List Meta-Information 1249 MIME Media Type Name: application 1251 MIME subtype name: rlmi+xml 1253 Required parameters: None 1255 Optional parameters: charset 1257 See RFC 3023 [10] for a discussion of the charset parameter on 1258 XML-derived MIME types. Since this MIME type is used exclusively 1259 in SIP, the use of UTF-8 encoding is strongly encouraged. 1261 Encoding considerations: 8-bit text 1263 Security considerations: Security considerations specific to uses of 1264 this this MIME type are discussed in RFC xxxx [[Note to RFC 1265 editor: replace xxxx with the RFC number of this document when 1266 published]]. RFC 1874 [9] and RFC 3023 [10] discuss security 1267 issues common to all uses of XML. 1269 Interoperability considerations: The use of this MIME body is 1270 intended to be generally interoperable. No unique considerations 1271 have been identified. 1273 Published specification: RFC xxxx [[Note to RFC editor: replace xxxx 1274 with the RFC number of this document when published]] 1276 Applications which use this media type: This media type is used to 1277 convey meta-information for the state of collections of resources 1278 within a Session Initiation Protocol (SIP) subscription. 1280 Additional information: 1282 Magic Number(s): None. 1284 File Extension(s): None. 1286 Macintosh File Type Code(s): None. 1288 Object Identifier(s) or OID(s): None. 1290 Intended usage: Limited Use 1292 Other Information/General Comment: None. 1294 Person to contact for further information: 1296 Name: Adam Roach 1298 E-Mail: adam@dynamicsoft.com 1300 Author/Change Controller: The specification of this MIME type is a 1301 work product of the SIMPLE working group, and was authored by 1302 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1303 change control over its specification. 1305 7.3 URN Sub-Namespace 1307 URI: urn:ietf:params:xml:ns:rlmi 1309 Description: This is the XML namespace URI for XML elements defined 1310 by [RFCXXXX] to describe information about subscriptions when such 1311 subscriptions are aggregated within a single SIP subscription. It 1312 is used in the application/rlmi+xml body type. 1314 Registrant Contact: 1316 Name: Adam Roach 1318 E-Mail: adam@dynamicsoft.com 1320 Author/Change Controller: The specification of this MIME type is a 1321 work product of the SIMPLE working group, and was authored by 1322 Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 1323 change control over its specification. 1325 XML: 1327 BEGIN 1328 1329 1331 1332 1333 1335 Namespace for SIP Event Resource List 1336 Meta-Information 1337 1338 1339

Namespace for SIP Event Resource List Meta-Information

1340

application/rlmi+xml

1341

See RFCXXXX.

1342 1343 1344 END 1346 8. Acknowledgements 1348 Thanks to Sean Olson for a review of and corrections to the usage of 1349 XML in this protocol. 1351 Normative References 1353 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1354 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1355 Session Initiation Protocol", RFC 3261, June 2002. 1357 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1358 Notification", RFC 3265, June 2002. 1360 [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 1361 Extensions) Part One: Mechanisms for Specifying and Describing 1362 the Format of Internet Message Bodies", RFC 1521, September 1363 1993. 1365 [4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 1366 2387, August 1998. 1368 Non-Normative References 1370 [5] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions 1371 for Presence", draft-ietf-simple-presence-07 (work in 1372 progress), May 2002. 1374 [6] Watson, M., Peterson, J. and C. Jennings, "Private Extensions 1375 to the Session Initiation Protocol (SIP) for Asserted Identity 1376 within Trusted Networks", draft-ietf-sip-asserted-identity-02 1377 (work in progress), August 2002. 1379 [7] Peterson, J., "Enhancements for Authenticated Identity 1380 Management in the Session Initiation Protocol (SIP)", draft- 1381 peterson-sip-identity-01 (work in progress), July 2002. 1383 [8] Olson, S., "A Mechanism for Content Indirection in Session 1384 Initiation Protocol (SIP) Messages", draft-ietf-sip-content- 1385 indirect-mech-01 (work in progress), November 2002. 1387 [9] Levinson, E., "SGML Media Types", RFC 1874, December 1995. 1389 [10] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1390 3023, January 2001. 1392 [11] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME 1393 Security with OpenPGP", RFC 3156, August 2001. 1395 [12] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security 1396 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 1397 RFC 1847, October 1995. 1399 Authors' Addresses 1401 Adam Roach 1402 dynamicsoft 1403 5100 Tennyson Pkwy 1404 Suite 1200 1405 Plano, TX 75024 1406 US 1408 EMail: adam@dynamicsoft.com 1409 Jonathan Rosenberg 1410 dynamicsoft 1411 72 Eagle Rock Ave. 1412 First Floor 1413 East Hanover, NJ 07936 1414 US 1416 EMail: jdrosen@dynamicsoft.com 1418 Ben Campbell 1419 dynamicsoft 1420 5100 Tennyson Pkwy 1421 Suite 1200 1422 Plano, TX 75024 1423 US 1425 EMail: bcampbell@dynamicsoft.com 1427 Appendix A. Changes 1429 Note that this section will be removed before publication as an RFC. 1431 A.1 Changes since -00 1433 o Removed text in several places which went into detail about 1434 specific implementations which used SIP SUB/NOT for back-end 1435 subscriptions. Some of this text will probably be published later 1436 as part of an implementors' guide. 1438 o Removed specific semantics for "Event" header parameters and 1439 SUBSCRIBE bodies. These will be defined on a per-package basis, 1440 probably by the filtering work. 1442 o Added "cid" attribute to elements. 1444 o Reworked XML schema definition for meta-information. 1446 o Added IANA registration for XML namespace. 1448 o Minor editorial fixes 1450 Full Copyright Statement 1452 Copyright (C) The Internet Society (2003). All Rights Reserved. 1454 This document and translations of it may be copied and furnished to 1455 others, and derivative works that comment on or otherwise explain it 1456 or assist in its implementation may be prepared, copied, published 1457 and distributed, in whole or in part, without restriction of any 1458 kind, provided that the above copyright notice and this paragraph are 1459 included on all such copies and derivative works. However, this 1460 document itself may not be modified in any way, such as by removing 1461 the copyright notice or references to the Internet Society or other 1462 Internet organizations, except as needed for the purpose of 1463 developing Internet standards in which case the procedures for 1464 copyrights defined in the Internet Standards process must be 1465 followed, or as required to translate it into languages other than 1466 English. 1468 The limited permissions granted above are perpetual and will not be 1469 revoked by the Internet Society or its successors or assigns. 1471 This document and the information contained herein is provided on an 1472 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1473 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1474 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1475 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1476 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1478 Acknowledgement 1480 Funding for the RFC Editor function is currently provided by the 1481 Internet Society.