idnits 2.17.1 draft-ietf-simple-view-sharing-02.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.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1422. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 20 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 363: '...criber. The RLS MUST generate a back-...' RFC 2119 keyword, line 364: '...ce P and event package E, and MUST use...' RFC 2119 keyword, line 368: '... rejected. The RLS SHOULD NOT perform...' RFC 2119 keyword, line 375: '...at case, the RLS SHOULD NOT generate a...' RFC 2119 keyword, line 386: '...quires. The RLS MUST generate a back-...' (64 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 3, 2008) is 5646 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) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-16 == Outdated reference: A later version (-08) exists of draft-ietf-simple-interdomain-scaling-analysis-05 == Outdated reference: A later version (-05) exists of draft-ietf-simple-intradomain-federation-01 == Outdated reference: A later version (-03) exists of draft-ietf-sipping-presence-scaling-requirements-01 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft S. Donovan 4 Intended status: Standards Track K. McMurry 5 Expires: May 7, 2009 Cisco 6 November 3, 2008 8 Optimizing Federated Presence with View Sharing 9 draft-ietf-simple-view-sharing-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Presence federation refers to the exchange of presence information 43 between systems. One of the primary challenges in presence 44 federation is scale. With a large number of watchers in one domain 45 obtaining presence for many presentities in another, the amount of 46 notification traffic is large. This document describes an extension 47 to the Session Initiation Protocol (SIP) event framework, called view 48 sharing. View sharing can substantially reduce the amount of 49 traffic, but requires a certain level of trust between domains. View 50 sharing allows the amount of presence traffic between domains to 51 achieve the theoretical lower bound on information exchange in any 52 presence system. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 58 3. RLS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1. On Receipt of a Resource List Subscription Request . . . . 8 60 3.1.1. Find a Matching Back-End Subscription . . . . . . . . 8 61 3.1.2. Generating a Back-End Subscription . . . . . . . . . 9 62 3.2. Processing NOTIFY Requests . . . . . . . . . . . . . . . . 10 63 3.2.1. Processing ACL-Infos . . . . . . . . . . . . . . . . . 10 64 3.2.2. Processing State Documents . . . . . . . . . . . . . . 11 65 3.2.3. Processing Back-End Terminations . . . . . . . . . . . 11 66 4. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 12 67 4.1. Authentication and Authorization . . . . . . . . . . . . . 12 68 4.2. Processing Initial SUBSCRIBE Requests . . . . . . . . . . 12 69 4.3. SUBSCRIBE Refreshes . . . . . . . . . . . . . . . . . . . 13 70 4.4. Policy Changes . . . . . . . . . . . . . . . . . . . . . . 13 71 4.5. Event State Changes . . . . . . . . . . . . . . . . . . . 15 72 5. ACL Format . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 5.1. Document Structure and Semantics . . . . . . . . . . . . . 15 74 5.2. Trust Considerations when Construcing ACLs . . . . . . . . 17 75 5.3. Example Documents . . . . . . . . . . . . . . . . . . . . 18 76 5.4. Rule Determination Algorithm . . . . . . . . . . . . . . . 19 77 5.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 21 78 6. Performance Analysis . . . . . . . . . . . . . . . . . . . . . 21 79 7. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 22 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 8.1. Privacy Considerations of the Serving Domain . . . . . . . 24 82 8.2. Privacy Considerations of the Watched Resource . . . . . . 25 83 8.3. Interactions with S/MIME . . . . . . . . . . . . . . . . . 26 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 85 9.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 26 86 9.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 27 87 9.3. Schema Registration . . . . . . . . . . . . . . . . . . . 28 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 93 Intellectual Property and Copyright Statements . . . . . . . . . . 32 95 1. Introduction 97 Presence refers to the ability, willingness and desire to communicate 98 across differing devices, mediums and services [RFC2778]. Presence 99 is described using presence documents [RFC3863] [RFC4479], exchanged 100 using a SIP-based event package [RFC3856]. 102 Presence federation refers to the interconnection of disparate 103 systems for the purposes of sharing presence information. This 104 interconnection involves passing of subscriptions from one system to 105 another, and then the passing of notifications in the opposite 106 direction. Federation can be occur between different domains, where 107 it is referred to as inter-domain federation. However, federation 108 can also occur within a domain, where it is referred to as intra- 109 domain federation [I-D.ietf-simple-intradomain-federation]. 111 [I-D.ietf-simple-interdomain-scaling-analysis] has analyzed the 112 amount of traffic, in terms of messages and in terms of bytes, which 113 flow between systems in various federated use cases. These numbers 114 demonstrate that presence traffic can be a substantial source of 115 overhead. The root cause of this scale challenge is the so-called 116 multiplicative effect of presence data. If there are N users, each 117 of which have B buddies on their buddy list, and each buddy changes 118 state L times per hour, the amount of notification traffic is 119 proportional to N*B*L. For example, in the case of two extremely 120 large public IM providers that federate with each other (each with 20 121 million users), [I-D.ietf-simple-interdomain-scaling-analysis] shows 122 that the amount of traffic due to these steady state notifications is 123 18.4 billion messages per day, an astoundingly large number. 124 Overhead for subscription maintenance and refreshes brings the total 125 to 25.6 billion per day. 127 The overhead for SIP-based presence can be reduced using SIP 128 optimizations. In particular, [I-D.ietf-sip-subnot-etags] can reduce 129 the amount of traffic due to refreshes and polls. However, this 130 optimization targets the overhead, and doesn't address the core 131 scaling problem - the multiplicative effect of presence data. 133 For this reason, there is a clear need to improve the scale of SIMPLE 134 in federated envrionments. 135 [I-D.ietf-sipping-presence-scaling-requirements] has laid out a set 136 of requirements for optimizations. The essence of these requirements 137 are that the extension should improve performance, while being 138 backwards compatible and supporting the privacy and policy 139 requirements of users. 141 This document defines a mechanism called view sharing in support of 142 those requirements. The key idea with view sharing is that when 143 there are many watchers in one system to a single presentity in 144 another system, each of which is actually going to get the exact same 145 presence document, the watcher's system extends a single subscription 146 to the system of the presentity, and the system of the presentity 147 sends a single copy of the presence document back to the system of 148 the watcher. Consequently, a "view" is a particular sequence of 149 presence documents that come about as a consequence of a particular 150 composition, authorization and privacy policy. Two watchers which 151 share the same view will always receive the same presence document 152 when the state of the presentity changes. 154 Though this mechanism can be applied intra-domain as well as inter- 155 domain, the specification considers only the inter-domain case. In 156 addition, though the principal application of view sharing is for 157 presence, it is a general extension to the SIP events framework and 158 specified in that way. 160 In the case of a pair of large providers that are peering with each 161 other, this mechanism can result in a significant savings. Assuming 162 a symmetrical system whereby the average buddies per watcher is B and 163 the average number of watchers for a user is also B, if most buddies 164 are in one domain or the other, this optimization can reduce the 165 overall subscription overhead and notification traffic by a factor of 166 B/2. In cases where there are a large number of small domains, this 167 mechanism is less useful. Of course, in such cases, the amount of 168 traffic between any pair of domains is small anyway. 170 2. Overview of Operation 172 The extension works in the environment shown in Figure 1. For 173 explanatory purposes, the environment assumes two domains. There are 174 some number of subscribers (W1 - W3) in the domain on the left, which 175 we call the subscribing domain. All of those subscribers are 176 interested in the state of a single resource P1 in the domain on the 177 right, which we call the serving domain. The subscribers all make 178 use of a resource list server (RLS) [RFC4662] which stores their 179 resource lists and performs the list expansion. Consequently, when 180 each subscriber subscribes to their resource list on the RLS, in 181 absence of any optimizations, the RLS will generate three separate 182 subscriptions to P1, each of which reaches the notifier in the 183 serving domain. 185 . 186 +--------------+ . +--------------+ 187 | | . | | 188 | | SUB . | | 189 | | -------.---> | | 190 | RLS | NOT . | Notifier | 191 | | <------.---- | | 192 | | . | | 193 | | . | | 194 +--------------+ . +--------------+ 195 ^ ^ ^ . ^ 196 List | | | . | PUB 197 SUB | | | . | 198 | | | . | 199 +----+ +----+ +----+ . +----+ 200 | | | | | | . | | 201 | W1 | | W2 | | W3 | . | P1 | 202 | | | | | | . | | 203 +----+ +----+ +----+ . +----+ 204 . 205 . 206 . 207 Subscribing . Serving 208 Domain . Domain 209 . 211 Figure 1: Deployment Model 213 Of course, in practice each domain will act as both a subscribing 214 domain and a serving domain, thus implementing both sides of the 215 system. 217 The initial SUBSCRIBE generated by the RLS includes a SIP option tag 218 "view-share" in the Supported header field, indicating that the RLS 219 supports the view sharing extension. If the notifier also supports 220 the extension, it makes use of it and includes an indication of this 221 fact in the Require header field in the SUBSCRIBE response and in 222 NOTIFY requests it generates. 224 View sharing requires a level of trust between the two domains. 225 Typically, TLS will be deployed between them, and the notifier uses 226 it to determine if the subscribing domain is authorized. 228 If this is the first subscription from domain 1 for that particular 229 resource, the notifier accepts the subscription (assuming the 230 subscriber is authorized of course). The notifications sent to the 231 RLS include two separate pieces of state. One is the actual state 232 for the resource. The other is an Access Control List (ACL) 233 document. This document describes the set of other subscribers from 234 the originating domain, if any, who are authorized to see exactly the 235 same document - in other words, the set of users that share the same 236 view. Should one of those subscribers seek the state of that 237 resource for the same event package, the RLS from the originating 238 domain does not need to generate a back-end subscription; rather, it 239 just uses the document it is receiving from the original 240 subscription, and passes it to both subscribers. The ACL can also 241 list users in the originating domain that are authorized to subscribe 242 to that resource, but who will end up receiving a different view. 243 Should one of those subscribers subscribe, the RLS knows that it must 244 perform a back-end subscription to obtain that view. The ACL can 245 also list subscribers in the originating domain that are not 246 authorized at all, in which case the RLS could immediately reject 247 their subscriptions. Finally, if the ACL says nothing about a 248 particular subscriber, it means that the notifier has elected to say 249 nothing about what view this subscriber will receive. Consequently, 250 the RLS must perform a back-end subscription should that subscriber 251 subscribe to the resource. 253 Other subsequent subscriptions to the same resource from the same 254 originating domain are processed in a similar way. However, the 255 notifier in the serving domain will keep track of the set of 256 subscriptions to the same resource for the same event package from 257 the same RLS which are to receive the same view. When a presence 258 notification is to be sent, instead of sending it on all such 259 subscriptions, the notification is sent on just a single 260 subscription. 262 Should the authorization policies in the serving domain change, an 263 updated ACL is sent, informing the subscribing domain of the new 264 policies. This may require the subscribing domain to extend a back- 265 end subscription to obtain a view, or may change the view an existing 266 subscriber is receiving, and so on. 268 The ACL allows the serving domain a great deal of flexibility in the 269 level of trust it imparts to the watching domain. The following are 270 all possible approaches that the serving domain can utilize: 272 No Trust: When a notifier receives the subscription, it elects not 273 to use this mechanism at all using the negotiation techniques 274 defined here. 276 Minimal Trust: When a subscriber subscribes to a resource, the ACL 277 generated for that subscription includes only that subscriber, 278 along with an identifier for their view. Consequently, for each 279 subscriber in domain 1 there will be a backend subscription to 280 domain 2. However, should multiple subscribers share the same 281 view, the notifier in domain 2 sends a single document on one of 282 the subscriptions, and the RLS uses this for all of the other 283 subscribers with the same view. With this approach, domain 2 284 never discloses the list of authorized subscribers ahead of time, 285 and it has full knowledge of each subscriber that is subscribed. 286 However, it gets the performance benefits of reducing the amount 287 of notification traffic. 289 Partial Trust: When a subscriber subscribes to a resource, the ACL 290 generated for that subscription includes that subscriber and all 291 other subscribers authorized for that same view. Consequently, 292 there will only be one backend subscription from the RLS to the 293 notifier for each view. However, the full set of authorized 294 subscribers is not disclosed ahead of time, only those that will 295 get the same view. With partial trust, the notifier will not know 296 the full set of subscribers currently subscribed. 298 Full Trust: When a subscriber subscribes to a resource, the ACL 299 generated for that subscription includes that subscriber and all 300 other subscribers that are authorized for that view, and all other 301 views, along with a rule that says that all other subscribers get 302 rejected. In this case, as with partial trust, there is only one 303 backend subscription from the RLS to the notifier for each view. 304 The full set of subscribers is disclosed ahead of time as well. 305 The notifier will not know the full set of subscribers currently 306 subscribed. 308 Depending on the level of trust, the mechanism trades off inter- 309 domain messaging traffic for increased processing load in the RLS to 310 handle the ACL documents. 312 3. RLS Behavior 314 This section defines the procedures that are to be followed by the 315 RLS. It is important to note that, even though this specification 316 defines an extension to the SIP events framework, the extension is 317 only useful for the back-end subscriptions generated by an RLS. The 318 extension defined here is not applicable or useful for individual 319 users generating subscriptions. Indeed, if it were utilized by 320 individual users, it has the potential for violations of user 321 privacy. See Section 8 for a discussion. 323 3.1. On Receipt of a Resource List Subscription Request 325 When the RLS receives a subscription to a resource list which 326 includes some resource P in another domain or system, it follows the 327 rules defined here. The processing depends on whether the RLS 328 already has a backend subscription to the resource that is in the 329 active state, and for which an ACL has been received. 331 3.1.1. Find a Matching Back-End Subscription 333 First, the RLS determines if it has a back-end subscription in place 334 whose view corresponds to that of the new subscriber. Let P be the 335 target resource, E the desired event package, and W the identity of 336 the subscriber. 338 Based on the procedures of Section 3.2.1, the RLS will keep, for each 339 resource and event package, the list of the most recent ACLs received 340 on each back-end subscription currently in place. This is called the 341 current ACL list. Using this ACL list, the RLS performs the rule 342 determination algorithm of Section 5.4 to compute the rule ID R for 343 the subscriber W. This represents the view that the subscriber is 344 supposed to receive. 346 Next, the RLS goes through all subscriptions it currently has for 347 resource P and event package E. For each one, it takes the identity 348 of the subscriber for that actual subscription. The identity for the 349 subscriber for that actual subscription is equal to the asserted 350 identity included in the back-end subscription. For example, if SIP 351 Identity [RFC4474] is utilized, this would be the URI present in the 352 From header field of the back-end SUBSCRIBE. Call the subscriber 353 identity for each subscription Wj. 355 Next, the RLS computes the rule determination algorithm of 356 Section 5.4 to compute the rule ID Rj for the subscriber Wj on each 357 subscription j. This represents the rule ID for the view being 358 delivered on that subscription. 360 Then, processing depends on the values of R and Rj: 362 o If R is null, it means that no ACL in the list specifies the view 363 for this subscriber. The RLS MUST generate a back-end 364 subscription to resource P and event package E, and MUST use 365 subscriber W as the identity in the back-end subscription. 367 o If R is not null, but the associated rule is blocked, it means 368 that the subscriber will be rejected. The RLS SHOULD NOT perform 369 another back-end subscription, and must act as if it had created a 370 back-end subscription which was rejected. 372 o If R is not null, and there is at least one subscription j for 373 which Rj = R, it means that subscription j is already generating 374 notifications for the view that subscriber W is supposed to 375 receive. In that case, the RLS SHOULD NOT generate a back-end 376 subscription for P on behalf of W. Rather, it should treat the 377 existing back end subscription j as if it were the back-end 378 subscription for W, and follow the guidelines of RFC 4662 379 [RFC4662] based on that. Subscription j is called the generating 380 subscription for subscriber W, and the actual subscriber 381 associated with subscription j, Wj, is called the generating 382 subscriber Wgen for subscriber W. 384 o If R is not null, but there is no subscription j for which Rj=R, 385 it means that the RLS is not yet receiving the view that 386 subscriber W requires. The RLS MUST generate a back-end 387 subscription to resource P, and MUST use subscriber W as the 388 identity in the back-end subscription. 390 3.1.2. Generating a Back-End Subscription 392 If, based on the processing of the previous section, a new back-end 393 subscription is needed, the rules in this section are followed. 395 The RLS MUST include a Supported header field in the request with the 396 option tag "view-share". The Accept header field MUST be present in 397 the request and MUST include the "application/viewshare-acl+xml" MIME 398 type amongst the list of supported types. The RLS MUST include an 399 +sip.instance Contact header field parameter [I-D.ietf-sip-outbound] 400 to uniquely identify the RLS instance. 402 Note that it is possible that two subscribers, in a short period of 403 time, both subscribe to their resource lists, both of which include 404 resource P. This will cause the RLS to generate two back-end 405 subscriptions at around the same time. The RLS is forced to generate 406 the second back-end subscription because it doesn't have an active 407 back-end subscription that has yet generated an ACL. Once both 408 subscriptions become active and generate ACLs, if the subscribers are 409 receiving the same view and both ACLs contain both subscribers, the 410 RLS SHOULD terminate one of the back-end subscriptions. 412 3.2. Processing NOTIFY Requests 414 If a NOTIFY request arrives with a Require header field that includes 415 the "view-share" option tag, it MUST be processed according to the 416 rules of this specification. 418 3.2.1. Processing ACL-Infos 420 If the contents of the NOTIFY are of type "application/ 421 viewshare-acl+xml", the subscriber processes the body as described 422 here. 424 For each resource that the RLS has at least one back-end subscription 425 for, the RLS MUST remember the most recent viewshare-acl received on 426 each back-end subscription. This is called the current ACL list for 427 the resource. This set of viewshare-acl is used in the processing of 428 subscription requests, as described in Section 3.1.1. 430 The serving domain can change policies at any time. When it does, it 431 sends an updated ACL on one or more subscriptions. The RLS MUST 432 store this ACL, replacing any previous ACL's received on this 433 subscription. Furthermore, the ACL might impact the views being 434 received by subscribers, and may impact the state of the back-end 435 subscriptions. 437 The RLS computes the set of subscribers Wi which have a resource list 438 subscription that includes the resource P for whom an updated ACL has 439 just been received. For each Wi, it performs the view determination 440 algorithm (see Section 5.4 on the current ACL set. Let Ri be the 441 view associated with subscriber Wi. If Ri has not changed from prior 442 to the receipt of the new ACL, no action is taken. However, if it 443 has changed, the RLS takes the set of current back-end subscriptions, 444 and for each subscription j, computes the view determination 445 algorithm for its associated subscriber Wj, to produce Rj. The 446 action to take depends on what has changed: 448 o If Ri is now null, it means that the serving domain has changed 449 the views associated with subscriber Wi, and this new view is not 450 known to the RLS. The RLS MUST generate a new back-end 451 subscription on behalf of subscriber Wi for resource P to obtain 452 this view. 454 o If Ri is now a blocked rule, it means that the serving domain has 455 now blocked Wi from obtaining the presence of the resource. The 456 RLS must act as if it had a back-end subscription on behalf of 457 subscriber Wi which was terminated. 459 o If Ri is not null and not blocked, and if there is an Rj which 460 matches the new Ri, it means that the serving domain has changed 461 the views associated with subscriber Wi, and changed them to 462 another view already being received by the RLS. The RLS MUST 463 treat this back-end subscription j as if it were the back-end 464 subscription to resource P for subscriber Wi. If the most recent 465 presence document received on this back-end subscription is not a 466 semantic match for the presence document most recently delivered 467 to Wi for resource P, the RLS MUST send this most recent presence 468 document to subscriber Wi. 470 o If Ri is not null and not blocked, but there is no Rj which 471 matches the new Ri, it means that the serving domain has changed 472 the views associated with subscriber Wi, and this new view is not 473 one currently being delivered to the RLS. The RLS MUST generate a 474 new back-end subscription on behalf of subscriber Wi for resource 475 P to obtain this view. 477 Furthermore, if there are now two back-end subscriptions j1 and j2 478 which have identical ACLs, RLS SHOULD terminate one of those two 479 subscriptions. Two ACL documents are considered equal if they 480 enumerate the same set of rules with the same members for each rule. 482 3.2.2. Processing State Documents 484 If the contents of the NOTIFY is a state document for the given event 485 package, the RLS follows the procedures defined here. 487 Let Wj be the subscriber on the subscription j on which the document 488 was just received. Let Rj be the results of running the rule 489 determination algorithm on Wj using the current ACL set. Next, the 490 RLS takes the set of subscribers Wi which have resource P on their 491 resource lists. The RLS then runs the rule determination algorithm 492 on each Wi using the current ACL set, producting Ri for each 493 subscriber Wi. For each Ri that is equal to Rj, the RLS MUST utilize 494 the document just received as if the back-end subscription j was in 495 fact for subscriber Wi. This will typically cause that document to 496 be sent in a NOTIFY request to each such subscriber, though each 497 subscriber may have some kind of filtering policy which causes the 498 RLS to modify the document prior to delivery. 500 3.2.3. Processing Back-End Terminations 502 If the NOTIFY request from the serving domain terminates the back-end 503 subscription, it may be because the subscriber Wj associated with 504 that subscription is no longer permitted to view the state of the 505 resource. 507 The ACL associated with the subscription MUST be removed from the 508 current ACL set. The procedures of Section 3.2.1 MUST be performed 509 to adjust back-end subscriptions, if needed. 511 4. Notifier Behavior 513 When a notifier receives a SUBSCRIBE request containing a Supported 514 header with the value "view-share", and it wishes to utilize view 515 sharing for this subscription, it follows the procedures defined 516 here. 518 4.1. Authentication and Authorization 520 The principle concern of the notifier is to determine the domain of 521 the RLS, and assess whether the subscribing entity is an RLS 522 authorized to operate on behalf of that domain. In order to utilize 523 view sharing, a notifier MUST determine both. This information is 524 necessary in order to compute the ACL to be sent to that domain, and 525 if done incorrectly, may reveal sensitive information to the watching 526 domain. 528 To determine the domain of the subscribing RLS, TLS with mutual 529 authentication SHOULD be used. In such a case, the notifier can 530 determine the domain of the RLS from the subjectAltName in the 531 certificate presented from its peer. 533 This specification does not define any automated mechanism for a 534 notifier to determine whether the subscribing entity is, in fact, an 535 RLS authorized to operate on behalf of the watching domain. 536 Section 8 discusses why this determination is important. Absent an 537 automated mechanism, notifiers SHOULD support a configuration option 538 which allows the administrator to enumerate a set of domains for 539 which it is known that an entity holding a certificate for that 540 domain is an authorized RLS. In such a case, the subject from the 541 certificate can be compared against that list, and if a match is 542 found, view sharing can be utilized for this subscription. 544 4.2. Processing Initial SUBSCRIBE Requests 546 First, the subscription is processed as it normally would be, 547 including authorization and policy around the document to be 548 delivered to the subscriber. Furthermore, if the notifier wishes to 549 utilize view sharing for this subscription, it MUST include a Require 550 header field in the first NOTIFY request (and indeed any subsequent 551 ones) it sends confirming this subscription, and that NOTIFY MUST 552 contain the "view-share" option tag. That option tag MUST NOT be 553 present in the Require header field of notifications unless the 554 corresponding dialog-forming SUBSCRIBE contained it in a Supported 555 header field. 557 Furthermore, the initial state sent by the notifier MUST include an 558 ACL document. It is formatted according to the rules and 559 considerations in Section 5. 561 The initial state sent by the notifier might include an actual state 562 document. In particular, a state document MUST be sent if one of the 563 following is true: 565 o There is only one subscription from the watching domain to this 566 resource that has the view associated with the subscriber. 568 o There is more than one subscription from the watching domain to 569 this resource with the same view, but the +sip.instance parameter 570 for the remote target (as conveyed in the Contact header field of 571 the SUBSCRIBE) differs. In other words, these subscriptions are 572 from the same domain, but from different RLS in the watching 573 domain. Each RLS in the watching domain needs to get their own 574 copy of the view for a particular resource. 576 If one of these conditions is not true, the notifier SHOULD NOT send 577 an initial state document on this subscription. 579 If an ACL and a state document are to be delivered, they MUST be 580 delivered separate NOTIFY requests unless the subscriber indicated 581 support for multipart, in which case the content MAY be included in a 582 single NOTIFY with mulitpart content. 584 4.3. SUBSCRIBE Refreshes 586 When the notifier receives a SUBSCRIBE refresh, it MUST send the most 587 recent ACL document, and if state documents are being sent for this 588 subscription, the most recent state document. 590 4.4. Policy Changes 592 There are several different types of policy changes that can occur: 594 o If the definitions for a particular rule change, the notifier MUST 595 assign a new rule ID for that rule. For each subscription to a 596 resource which contained that rule, the notifier MUST send an 597 updated ACL which includes a rule with this new rule ID. 599 o If some subscriber W was previously associated with rule X and is 600 now associated with rule Y, the notifier checks if it has any 601 subscriptions from subscriber W. If it does, it MUST send an 602 updated ACL on that subscription. Based on the rules in 603 Section 5, this ACL will contain rule Y and will at least include 604 W amongst the list of members. Furthermore, if there were 605 subscriptions from other subscribers, but the notifier had 606 previously sent an ACL on the subscription which was a match for 607 W, it MUST send an updated ACL on that subscription. This updated 608 ACL MAY omit a statement about rule Y or MAY include it. However, 609 the updated ACL MUST NOT claim that subscriber W will receive rule 610 X. 612 o If some subscriber W was previously associated with rule X and is 613 now blocked, the notifier checks if it has any subscriptions from 614 subscriber W. If it does, it MUST terminate the back-end 615 subscription. If it doesn't, but it has a subscription from some 616 other subscriber which had included a rule that was a match for W, 617 the notifier MUST send an updated ACL on that subscription. This 618 updated ACL MAY omit any statement about subscriber W, or MAY 619 include them as part of a blocked rule in that ACL. 621 o If some subscriber W was previously blocked and is now permitted 622 and associated with some rule X, the notifier checks if it had any 623 subscriptions from some other subscriber which included a blocked 624 rule that matched subscriber W. If it had, it MUST send an updated 625 ACL on that subscription. That updated ACL MAY omit any statement 626 about subscriber W, or MAY indicate that subscriber W is now 627 associated with rule X. 629 Of course, a policy change will also potentially alter the state 630 documents that are associated with a view. If so, the notifier MUST 631 send an updated document on a subscription if one of the following is 632 true: 634 o There is only one subscription from the watching domain to this 635 resource that has the view associated with the subscriber. 637 o There is more than one subscription from the watching domain to 638 this resource with the same view, but the +sip.instance Contact 639 header field in the request differs between them. 641 If neither is true, the notifier MUST select one subscription amongst 642 the several which share the same resource, view, and Contact 643 +sip.instance header field parameter, and sent an updated 644 notification on that subscription. The choice of subscriptions is 645 arbitrary and MAY change for each notification. 647 4.5. Event State Changes 649 If the state of some resource changes, the notifier may need to send 650 an updated notification on a subscription. The notifier MUST send an 651 update on a subscription if one of the following is true: 653 o There is only one subscription from the watching domain to this 654 resource that has the view associated with the subscriber. 656 o There is more than one subscription from the watching domain to 657 this resource with the same view, but the +sip.instance Contact 658 header field in the request differs between them. 660 If neither is true, the notifier MUST select one subscription amongst 661 the several which share the same resource, view, and Contact 662 +sip.instance header field parameter, and sent an updated 663 notification on that subscription. The choice of subscriptions is 664 arbitrary and MAY change for each notification. 666 5. ACL Format 668 An ACL document is an XML [W3C.REC-xml-20001006] document that MUST 669 be well-formed and MUST be valid according to schemas, including 670 extension schemas, available to the validater and applicable to the 671 XML document. ACL documents MUST be based on XML 1.0 and MUST be 672 encoded using UTF-8. This specification makes use of XML namespaces 673 for identifying ACL documents and document fragments. The namespace 674 URI for elements defined by this specification is a URN [RFC2141], 675 using the namespace identifier 'ietf' defined by RFC 2648 [RFC2648] 676 and extended by RFC 3688 [RFC3688]. This URN is: 678 urn:ietf:params:xml:ns:viewshare-acl 680 5.1. Document Structure and Semantics 682 An ACL document informs a watching domain of the set of views that 683 can be received by that domain, and associates specific subscribers 684 with specific views. It is very important to understand that the ACL 685 document does not convey the actual processing that will be applied 686 by the serving domain. It does not indicate, for example, whether 687 geolocation is present in a presence document, or which rich presence 688 [RFC4480] data elements will be conveyed. It merely provides 689 grouping - indicating which subscribers from the subscribing domain 690 will receive the same view. 692 Each ACL document starts with the enclosing root element . 693 This contains the list of rules defined by the ACL. Each rule is 694 represented by the element. Each rule represents a specific 695 view, which is generated by the notifier based on its authorization, 696 composition and filtering policies. Each rule is associated with a 697 rule ID, which is a mandatory attribute of the element. This 698 ID is scoped within a single resource. That is, the IDs for two 699 rules for different presentities are unrelated. 701 The element also contains an optional "blocked" boolean 702 attribute. If "true", it means that the rule specifies that the 703 associated set of subscribers will be rejected, should they 704 subscribe. This can be used by the watching domain to avoid 705 performing back-end subscriptions to users which will only be blocked 706 anyway. 708 Each contains the set of users that will receive the 709 corresponding view. This can be described by an enumerated set or by 710 a default. If it is an enumerated set, the is followed by a 711 sequence of elements, each of which contains a SIP URI for 712 the subscriber that will receive that view. 714 The default view is specified by including a single child element for 715 - . The default view applies to all subscribers except 716 those enumerated by other rules. For this reason, an ACL document 717 which contains a default view MUST include the rule IDs and 718 associated members for all other views that are delivered to 719 subscribers. For example, consider a resource that has three views. 720 View 1 is delivered to subscribers A and B. View 2 is delivered to 721 subscriber C. View 3 is delivered to everyone else. An ACL document 722 that includes the default view must also include views 1 and 2 with 723 subscribers A, B, and C. 725 In contrast, an ACL document that does not include a default does not 726 need to include all views, and it does not need to include all 727 members for a particular view. Using the example above, it is valid 728 to include an ACL document which includes only view 1 with subscriber 729 1. 731 If two URI are present within elements within the same 732 , it represents an indication by the notifier that both users 733 MUST get the same view. Formally, if the notifier were to receive a 734 subscription from each subscriber, both subscriptions would be 735 accepted or both would be rejected, and if accepted, each 736 subscription would receive semantically identical presence documents 737 at approximately the same time. 739 Even if two users will receive the same view, a notifier MAY assign 740 each to a different view ID. There is no requirement that two unique 741 views actually contain different presence data. The only requirement 742 is that, if two users are listed within the same rule, that they do 743 in fact receive the same view. 745 An ACL document delivered in a subscription from subscriber W MUST 746 include the view associated with subscriber W and MUST include 747 subscriber W explicitly in a element or implicitly by 748 presence of an element. 750 5.2. Trust Considerations when Construcing ACLs 752 The semantics above give very little guidance about what a notifier 753 should include in an ACL. The amount of information to convey 754 depends on the level of trust between the subscribing and serving 755 domains. 757 Firstly, in all cases, any subscriber listed in a rule MUST be one 758 that the subscribing RLS is authorized to perform subscriptions for. 759 Typically, this is all of the subscribers in the domain of the RLS. 760 For example, if a view-sharing subscription is received from 761 example.com, only subscribers whose domain is example.com should be 762 included in the ACL. However, in cases where view sharing is used 763 between a clearinghouse provider and clearinghouse members, the ACL 764 could include subscribers in other domains, based on the policy of 765 the serving domain. 767 Optimal performance is achieved when the ACL document for a resource 768 includes all views that the server might ever deliver to subscribers 769 from the watching domain, and includes all members from that domain 770 for each view, including any defaults and blocked rules. However, 771 this informs the watching domain of the set of allowed and blocked 772 subscribers from its own domain, and associated groupings amongst 773 subscribers. 775 Slightly worse performance is achieved when the ACL document for a 776 resource sent in a subscription from subscriber W includes only a 777 single view - the one for subscriber W - along with the full set of 778 subscribers from that domain which will also receive that view, 779 assuming it is not the default view. If the view is the default 780 view, the document can include just subscriber W. This approach will 781 cause back-end subscriptions from every subscriber that will receive 782 the default, but it discloses less information to the watching 783 domain. In particular, the full set and number of views is never 784 known by the watching domain. The fact that a view is default is 785 never known by the watching domain. The full set of users that are 786 permitted to view the state of the resource is never disclosed to the 787 watching domain. The performance of this approach is still 788 reasonably good when the default rule is blocked. However it is much 789 less effective when the default is not blocked, and many subscribers 790 receive the default. 792 Another choice for construction of ACL documents is to include, in a 793 subscription from subscriber W, a single rule containing the rule ID 794 for the view that subscriber W will receive, along with a single 795 member - W. This approach will still result in a back-end 796 subscription from each subscriber. However, a single notification is 797 sent for each view, rather than one per subscriber. The benefit of 798 this construction is that it provides the watching domain no 799 additional information about the authorization policies of the 800 resource than if this extension were not in use at all. 802 5.3. Example Documents 804 The example document in Figure 2 shows the case when there is maximum 805 trust between domains. The full set of subscribers, include a 806 blocked default, is included. 808 809 810 811 812 sip:user1@example.com 813 sip:user2@example.com 814 sip:user3@example.com 815 sip:user4@example.com 816 sip:user5@example.com 817 818 819 sip:user6@example.com 820 821 822 sip:user7@example.com 823 sip:user8@example.com 824 sip:user9@example.comm 825 sip:user10@example.com 826 sip:user11@example.com 827 828 829 830 831 833 Figure 2: Example with Maximum Trust 835 The example in Figure 3 shows a moderate level of trust. This ACL 836 only shows the view associated with the subscriber user1. 838 839 840 841 842 sip:user1@example.com 843 sip:user2@example.com 844 sip:user3@example.com 845 sip:user4@example.com 846 sip:user5@example.com 847 848 850 Figure 3: Example with Partial Trust 852 The example in Figure 4 shows the minimal level of trust. This ACL 853 would be sent in a subscription to user1. 855 856 857 858 859 sip:user1@example.com 860 861 863 Figure 4: Example with Minimal Trust 865 5.4. Rule Determination Algorithm 867 Several steps in the processing of the ACL require that the RLS in 868 the watching domain execute the rule determination algorithm for 869 subscriber W on an ACL set. This algorithm is a simple algorithm 870 which takes, as input, a subscriber W with a given SIP URI, and a set 871 of ACL documents Ai, and returns as output, a rule ID R, which is the 872 rule ID for the view that, according to the set of ACLs, subscriber W 873 should receive. 875 The algorithm proceeds as follows. First, each Ai is matched to W. 876 ACL Ai is a match for subscriber W if: 878 o ACL Ai contains a tag whose URI is a match, based on URI 879 equality, for W, or 881 o none of the tags in Ai contain a URI that is a match, 882 based on URI equality, for W, but there is an element in 883 Ai 885 If no ACL Ai matched, the algorithm returns a null result. 887 For each ACL Ai that matches based on the rules above, take the id of 888 the enclosing element that contained the or 889 element that caused the match. For ACL Ai, this is rule Ri. For 890 example, consider the following ACL: 892 893 894 895 sip:user1@example.com 896 sip:user2@example.com 897 898 899 sip:user3@example.com 900 901 902 903 904 906 If this document is A1, and the subscriber is sip:user3@example.com, 907 the associated rule R1 is 2. If the subscriber is 908 sip:user1@example.com or sip:user2@example.com, the rule R1 is 1. If 909 the subscriber is anyone else from example.com, such as 910 sip:user4@example.com, the rule R1 is 3. 912 If all Ri are equal, denote R = Ri. Thus, R is the rule ID 913 associated with this subscriber. Normally, all Ri will be equal. 914 However, during transient periods of changes in authorization state, 915 it is possible that inconsistent ACL documents exist. In that case, 916 R is assigned the value Ri from the ACL Ai which is the most recently 917 received amonst all ACLs. 919 5.5. XML Schema 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 944 6. Performance Analysis 946 This section considers the performance improvement of the mechanism 947 when it is maximally exercised. The performance is examined in the 948 context of an inter-domain presence federation. In this example, the 949 full ACL, including blocked senders, is returned in the first 950 subscription to a presentity. This analysis assumes there is a 951 single, monolithic notifier serving each domain. 953 The optimizations improve ramp-up, steady state, and termination 954 message loads. In particular, each of those loads, without the 955 optimization described here, is proportional to C04, the total number 956 of federated presentities per watcher. If we assume symmetry, such 957 that the number of federated presentities per watcher is equal to the 958 number of watchers per federated presentity, then each of the load 959 figures is reduced by C04. That is, the system behaves identically 960 to the case where there is a single subscriber per federated 961 presentity, and assuming symmetric, the same as if there is a single 962 federated presentity per subscriber - e.g., C04 = 1. 964 Consider then the very large network peering model in 965 [I-D.ietf-simple-interdomain-scaling-analysis]. In this model, the 966 assumption is two large peering domains with 20 million users each, 967 with a value of 10 for C04. With this optimization, the number of 968 steady state notifications due to presence state changes drops from 969 18.4 billion per day to 1.84 billion per day. The number of messages 970 per second overall is reduced from 654,167 per second to 65,417 per 971 second. Still a big number, of course, but it can't actually get 972 much smaller. 974 Indeed, it can be readily shown that, assuming the federated domains 975 do not actually share raw presence inputs and the actual policies 976 that govern operation of their servers, no protocol can do better 977 (constants, such as mesage size and the need for protocol responses 978 and acknowledgements aside). Consider a domain with N presentities. 979 Each resource changes state P times per hour. Every time the state 980 changes, the domain applies its authorization and composition 981 policies. The resulting presence document cannot be known to the 982 watching domain. Thus, there must be at least one message from the 983 serving to watching domain, per view, in order to inform it of that 984 view. This means that the steady state rate of messages can never be 985 better than N*P, and this is exactly the factor governing the rate of 986 messages when this optimization is applied. 988 7. Requirements Analysis 990 This section analyzes the requirements in 991 [I-D.ietf-sipping-presence-scaling-requirements] to show how they are 992 met by the mechanism proposed here. 994 REQ-001: The solution should not hinder the ability of existing 995 SIMPLE clients and/or servers from peering with a domain or client 996 implementing the solution. No changes may be required of existing 997 servers to interoperate. This requirement is met by usage of the 998 Supported and Require mechanisms and SIP which negotiate its 999 usage. 1001 REQ-002: It does NOT constrain any existing RFC functional or 1002 security requirements for presence. The mechanism does not change 1003 anything that is possible without it. It does, however, introduce 1004 new privacy considerations, described below in Section 8. 1006 REQ-003: Systems that are not using the new additions to the 1007 protocol should operate at the same level as they do today. This 1008 requirement is met by usage of the Supported and Require 1009 mechanisms in SIP. 1011 REQ-004: The solution does not limit the ability for presentities to 1012 present different views of presence to different watchers. This 1013 requirement is met by usage of the ACL document, which allows the 1014 serving domain to associate a subscriber with any view it likes, 1015 and to change it over time. 1017 REQ-005: The solution does not restrict the ability of a presentity 1018 to obtain its list of watchers. The mechanism does allow a 1019 presence server to know the list of subscribers, at the expense of 1020 non-optimal performance. In particular, it will receive a 1021 subscription from each subscriber. However, it only generates one 1022 notification per view on presence changes. The fully optimized 1023 solution will result in a loss of knowledge of the set of 1024 watchers. However, it is a policy decision at the presence agent 1025 about whether it would like to make this tradeoff. 1027 REQ-006: The solution MUST NOT create any new or make worse any 1028 existing privacy holes. This requirement is met, but only when 1029 carefully provisioned. See Section 8. 1031 REQ-007: It is highly desirable for any presence system (intra or 1032 inter-domain) to scale linearly as number of watchers and 1033 presentities increase linearly. When the most optimal technique 1034 is used, there is always one subscription per view per presentity, 1035 independent of the number of watchers in the remote domain or the 1036 number of averages buddies per buddy list. Since the number of 1037 views is not proportional to the number of users, the total 1038 traffic volume in a domain is linear with its number of 1039 presentities, and is independent of the number of users in the 1040 peering domain. 1042 REQ-008: The solution SHOULD NOT require significantly more state in 1043 order to implement the solution. The mechanism requires storage 1044 of the ACL, which has a size exactly equal to the number of 1045 subscriptions that would be required if the extension were not in 1046 place. Thus the memory usage is not worsened compared to the 1047 baseline. 1049 REQ-009: It MUST be able to scale to tens of millions of concurrent 1050 users in each domain and in each peer domain. The analysis in 1051 Section 6 shows that, when fully utilized, this mechanism is the 1052 best that can possibly be achieved in any system that does not 1053 actually share policies and raw presence data. 1055 REQ-010: It MUST support a very high level of watcher/presentity 1056 intersections in various intersection models. The mechanism is 1057 optimized for this case. 1059 REQ-011: Protocol changes MUST NOT prohibit optimizations in 1060 different deployment models esp. where there is a high level of 1061 cross subscriptions between the domains. Since standard SIP 1062 techniques are utilized to negotiate the extension, other 1063 mechansims can be defined in the future. 1065 REQ-012: New functionalities and extensions to the presence protocol 1066 SHOULD take into account scalability with respect to the number of 1067 messages, state size and management and processing load. That is 1068 exactly what this extension targets. 1070 REQ-013: The solution SHOULD allow for arbitrary federation 1071 topologies including direct peering and intermediary routing. The 1072 mechanism is optimized for direct peering. It can work in 1073 intermediary routing cases as well. 1075 8. Security Considerations 1077 The principal question with the specification is whether it alters 1078 the privacy characteristics of a non-optimized federated system. 1079 This can be considered for both the serving domain and the 1080 subscribed-to resource. In all cases, view sharing requires secure 1081 authentication and encryption between the domains that use it. This 1082 is provided by TLS. 1084 8.1. Privacy Considerations of the Serving Domain 1086 Consider first the case where the serving domain is using the minimal 1087 trust model. In that case, the ACL provided to the subscribing 1088 domain does not carry any information that the subscribing domain 1089 doesn't already know. It merely points out when two subscribers 1090 share the same view. This is something that the subscribing domain 1091 could have already ascertained by comparing presence documents 1092 delivered to each subscriber. The ACL makes this task easier, but 1093 nonetheless the subscribing domain could have already ascertained it. 1094 Consequently, there is no change whatsoever in the level of privacy 1095 afforded by the optimization when this mode is used. 1097 However, when an ACL is provided that includes other users besides 1098 the actual subscriber, this provides additional information to the 1099 subscribing domain. This is, however, information that the 1100 subscribing domain could find out anyway. If it generated a 1101 subscription from each of its users to the resource it would be able 1102 to determine who from its domain is allowed to subscribe and what 1103 view they would receive. This would be an expensive operation to be 1104 sure, but it is possible. Consequently, the optimization doesn't 1105 really provide anything new to the originating domain, even in this 1106 case. 1108 However, there is an attack possible when the information is divulged 1109 to an end user. Consider a subscribing domain that doesn't actually 1110 implement this extension at all. A user within the domain uses a 1111 client that generates a subscription to a resource in a remote 1112 domain. This subscription uses an outbound proxy in the watching 1113 domain. The outbound proxy is just a proxy, and therefore doesn't 1114 remove or modify the Supported header field in the request. The 1115 serving domain accepts the subscription and sends an ACL that 1116 contains the full set of subscribers that are permitted in the 1117 originating domain. The original subscriber now knows the set of 1118 other authorized buddies within their own domain, and what views they 1119 will see. While this is information that the domain overall would 1120 have access to, it is not information an end user would normally have 1121 access to. Consequently, this is a more serious privacy violation. 1123 It is for this reason that this specification requires that both 1124 sides of the federated link be explicitly provisioned to utilize this 1125 optimization. In the attack above, the subscribing domain would not 1126 have set up a peering relationship with the serving domain. If it 1127 had, it would have an RLS and would not have permitted the user to 1128 directly subscribe in this way. Thus, when the subscription is 1129 received by the serving domain, it will find that it has no agreement 1130 with the originating domain, and would not utilize view sharing. 1131 This thwarts the attack. 1133 This remedy is not optimal because it requires on provisioning to 1134 prevent. There does not appear to be any easy cryptographic means to 1135 prevent it, however. 1137 8.2. Privacy Considerations of the Watched Resource 1139 The principle security concern for the watched resource is whether 1140 the documents shown to subscriber meet its privacy policies. This is 1141 particularly a concern for presence. These privacy policies can be 1142 violated if presence documents are shown to subscribers to whom the 1143 resource has not granted permission, or if they contain content that 1144 the resource has not allowed the subscriber to see. 1146 Based on the mechanisms defined in this specification, view sharing 1147 gives clear guidance to the watching RLS about which additional 1148 subscribers can see a particular presence document. Consequently, 1149 under normal operating conditions, the system ensures that the 1150 privacy policies of the resource are met. It is possible that a 1151 buggy implementation might accidentally redistribute presence 1152 documents to unauthorized subscribers. Implementors SHOULD be 1153 careful to implement the ACL mechanism carefully to avoid this. A 1154 malicious RLS or domain could ignore the ACL documents defined by 1155 this document, and distribute the presence documents to unauthorized 1156 subscribers. However, such an attack is already possible in the 1157 normal operation of an RLS, and is not worsened by the view sharing 1158 mechanism defined here. 1160 8.3. Interactions with S/MIME 1162 The SIP and SIMPLE specifications do allow state documents to be 1163 signed and/or encrypted with S/MIME. When S/MIME is used strictly 1164 for message integrity, view sharing is fully compatible with S/MIME. 1165 However, when presence documents are encrypted using S/MIME, this 1166 causes an interaction with view sharing. The serving domain will 1167 send out only a single document to the watching domain for each view. 1168 This document needs to be decryptable by each authorized subscriber. 1169 Consequently, that group must either share a single key, or the 1170 serving domain needs to encrypt the content using the keys from each 1171 of the authorized subscribers. In the latter case, view sharing and 1172 S/MIME cannot be used together if the set of authorized subscribers 1173 is wildcarded. 1175 9. IANA Considerations 1177 There are several IANA considerations associated with this 1178 specification. 1180 9.1. MIME Type Registration 1182 This specification requests the registration of a new MIME type 1183 according to the procedures of RFC 2048 [RFC2048] and guidelines in 1184 RFC 3023 [RFC3023]. 1186 MIME media type name: application 1188 MIME subtype name: viewshare-acl+xml 1190 Mandatory parameters: none 1192 Optional parameters: Same as charset parameter application/xml as 1193 specified in RFC 3023 [RFC3023]. 1195 Encoding considerations: Same as encoding considerations of 1196 application/xml as specified in RFC 3023 [RFC3023]. 1198 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 1199 Section 8 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace 1200 XXXX with the RFC number of this specification]]. 1202 Interoperability considerations: none. 1204 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: 1205 Please replace XXXX with the RFC number of this specification]] 1207 Applications which use this media type: This document type has 1208 been used to support subscriptions to lists of users [RFC4662] for 1209 SIP-based presence [RFC3856]. 1211 Additional Information: 1213 Magic Number: None 1215 File Extension: .acl 1217 Macintosh file type code: "TEXT" 1219 Personal and email address for further information: Jonathan 1220 Rosenberg, jdrosen@jdrosen.net 1222 Intended usage: COMMON 1224 Author/Change controller: The IETF. 1226 9.2. URN Sub-Namespace Registration 1228 This section registers a new XML namespace, as per the guidelines in 1229 RFC 3688 [RFC3688]. 1231 URI: The URI for this namespace is 1232 urn:ietf:params:xml:ns:viewshare-acl. 1234 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1235 Jonathan Rosenberg (jdrosen@jdrosen.net). 1237 XML: 1239 BEGIN 1240 1241 1243 1244 1245 1247 ACL Info Namespace 1248 1249 1250

Namespace for ACL Info

1251

urn:ietf:params:xml:ns:viewshare-acl

1252

See RFCXXXX [NOTE 1253 TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this 1254 specification.].

1255 1256 1257 END 1259 9.3. Schema Registration 1261 This section registers an XML schema per the procedures in [RFC3688]. 1263 URI: urn:ietf:params:xml:schema:viewshare-acl 1265 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1266 Jonathan Rosenberg (jdrosen@jdrosen.net). 1268 The XML for this schema can be found as the sole content of 1269 Section 5.5. 1271 10. Acknowledgements 1273 The authors would like to thank Avshalom Houri, Richard Barnes, and 1274 Michael Froman for their comments on this document. 1276 11. References 1278 11.1. Normative References 1280 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1281 Initiation Protocol (SIP) Event Notification Extension for 1282 Resource Lists", RFC 4662, August 2006. 1284 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1285 Authenticated Identity Management in the Session 1286 Initiation Protocol (SIP)", RFC 4474, August 2006. 1288 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1290 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1291 August 1999. 1293 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1294 January 2004. 1296 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1297 Internet Mail Extensions (MIME) Part Four: Registration 1298 Procedures", BCP 13, RFC 2048, November 1996. 1300 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1301 Types", RFC 3023, January 2001. 1303 [W3C.REC-xml-20001006] 1304 Maler, E., Paoli, J., Bray, T., and C. Sperberg-McQueen, 1305 "Extensible Markup Language (XML) 1.0 (Second Edition)", 1306 World Wide Web Consortium FirstEdition REC-xml-20001006, 1307 October 2000, 1308 . 1310 [I-D.ietf-sip-outbound] 1311 Jennings, C. and R. Mahy, "Managing Client Initiated 1312 Connections in the Session Initiation Protocol (SIP)", 1313 draft-ietf-sip-outbound-16 (work in progress), 1314 October 2008. 1316 11.2. Informative References 1318 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for 1319 Presence and Instant Messaging", RFC 2778, February 2000. 1321 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 1322 W., and J. Peterson, "Presence Information Data Format 1323 (PIDF)", RFC 3863, August 2004. 1325 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 1326 July 2006. 1328 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1329 Initiation Protocol (SIP)", RFC 3856, August 2004. 1331 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 1332 Rosenberg, "RPID: Rich Presence Extensions to the Presence 1333 Information Data Format (PIDF)", RFC 4480, July 2006. 1335 [I-D.ietf-simple-interdomain-scaling-analysis] 1336 Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., 1337 and H. Schulzrinne, "Presence Interdomain Scaling Analysis 1338 for SIP/SIMPLE", 1339 draft-ietf-simple-interdomain-scaling-analysis-05 (work in 1340 progress), October 2008. 1342 [I-D.ietf-simple-intradomain-federation] 1343 Rosenberg, J., Houri, A., and C. Smyth, "Models for Intra- 1344 Domain Presence and Instant Messaging (IM) Federation", 1345 draft-ietf-simple-intradomain-federation-01 (work in 1346 progress), July 2008. 1348 [I-D.ietf-sip-subnot-etags] 1349 Niemi, A., "An Extension to Session Initiation Protocol 1350 (SIP) Events for Conditional Event Notification", 1351 draft-ietf-sip-subnot-etags-03 (work in progress), 1352 July 2008. 1354 [I-D.ietf-sipping-presence-scaling-requirements] 1355 Houri, A., Parameswar, S., Aoki, E., Singh, V., and H. 1356 Schulzrinne, "Scaling Requirements for Presence in SIP/ 1357 SIMPLE", 1358 draft-ietf-sipping-presence-scaling-requirements-01 (work 1359 in progress), July 2008. 1361 Authors' Addresses 1363 Jonathan Rosenberg 1364 Cisco 1365 Iselin, NJ 1366 US 1368 Email: jdrosen@cisco.com 1369 URI: http://www.jdrosen.net 1371 Steve Donovan 1372 Cisco 1373 Richardson, TX 1374 US 1376 Email: stdonova@cisco.com 1377 Kathleen McMurry 1378 Cisco 1379 Richardson, TX 1380 US 1382 Email: kmcmurry@cisco.com 1384 Full Copyright Statement 1386 Copyright (C) The IETF Trust (2008). 1388 This document is subject to the rights, licenses and restrictions 1389 contained in BCP 78, and except as set forth therein, the authors 1390 retain all their rights. 1392 This document and the information contained herein are provided on an 1393 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1394 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1395 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1396 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1397 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1398 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1400 Intellectual Property 1402 The IETF takes no position regarding the validity or scope of any 1403 Intellectual Property Rights or other rights that might be claimed to 1404 pertain to the implementation or use of the technology described in 1405 this document or the extent to which any license under such rights 1406 might or might not be available; nor does it represent that it has 1407 made any independent effort to identify any such rights. Information 1408 on the procedures with respect to rights in RFC documents can be 1409 found in BCP 78 and BCP 79. 1411 Copies of IPR disclosures made to the IETF Secretariat and any 1412 assurances of licenses to be made available, or the result of an 1413 attempt made to obtain a general license or permission for the use of 1414 such proprietary rights by implementers or users of this 1415 specification can be obtained from the IETF on-line IPR repository at 1416 http://www.ietf.org/ipr. 1418 The IETF invites any interested party to bring to its attention any 1419 copyrights, patents or patent applications, or other proprietary 1420 rights that may cover technology that may be required to implement 1421 this standard. Please address the information to the IETF at 1422 ietf-ipr@ietf.org. 1424 Acknowledgment 1426 Funding for the RFC Editor function is provided by the IETF 1427 Administrative Support Activity (IASA).