idnits 2.17.1 draft-ietf-simple-view-sharing-01.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 1325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1349. 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 314: '... First, the RLS MUST check a configur...' RFC 2119 keyword, line 320: '...f not, the extension MUST NOT be used....' RFC 2119 keyword, line 322: '... Next, the RLS MUST send the SUBSCRI...' RFC 2119 keyword, line 323: '...nnection. The RLS MUST check that the...' RFC 2119 keyword, line 335: '... The RLS MUST generate a back-end su...' (67 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 (July 14, 2008) is 5764 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-15 == Outdated reference: A later version (-08) exists of draft-ietf-simple-interdomain-scaling-analysis-04 == Outdated reference: A later version (-03) exists of draft-ietf-sip-subnot-etags-02 == Outdated reference: A later version (-03) exists of draft-ietf-sipping-presence-scaling-requirements-00 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: January 15, 2009 Cisco 6 July 14, 2008 8 Optimizing Federated Presence with View Sharing 9 draft-ietf-simple-view-sharing-01 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 January 15, 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. Authentication and Authorization . . . . . . . . . . . 8 61 3.1.2. No Active Back-End Subscription . . . . . . . . . . . 8 62 3.1.3. Active Back-End Subscription . . . . . . . . . . . . . 9 63 3.2. Processing NOTIFY Requests . . . . . . . . . . . . . . . . 10 64 3.2.1. Processing ACL-Infos . . . . . . . . . . . . . . . . . 10 65 3.2.2. Processing Presence Documents . . . . . . . . . . . . 11 66 3.2.3. Processing Back-End Terminations . . . . . . . . . . . 12 67 4. Presence Agent Behavior . . . . . . . . . . . . . . . . . . . 12 68 4.1. Authentication and Authorization . . . . . . . . . . . . . 12 69 4.2. Processing Initial SUBSCRIBE Requests . . . . . . . . . . 12 70 4.3. SUBSCRIBE Refreshes . . . . . . . . . . . . . . . . . . . 13 71 4.4. Policy Changes . . . . . . . . . . . . . . . . . . . . . . 13 72 4.5. Presence State Changes . . . . . . . . . . . . . . . . . . 15 73 5. ACL Format . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 5.1. Document Structure and Semantics . . . . . . . . . . . . . 15 75 5.2. Trust Considerations when Construcing ACLs . . . . . . . . 17 76 5.3. Example Documents . . . . . . . . . . . . . . . . . . . . 18 77 5.4. Rule Determination Algorithm . . . . . . . . . . . . . . . 19 78 5.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 21 79 6. Performance Analysis . . . . . . . . . . . . . . . . . . . . . 21 80 7. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 22 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 83 9.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 25 84 9.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 26 85 9.3. Schema Registration . . . . . . . . . . . . . . . . . . . 27 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 28 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 91 Intellectual Property and Copyright Statements . . . . . . . . . . 30 93 1. Introduction 95 Presence refers to the ability, willingness and desire to communicate 96 across differing devices, mediums and services [RFC2778]. Presence 97 is described using presence documents [RFC3863] [RFC4479], exchanged 98 using a SIP-based event package [RFC3856]. 100 Presence federation refers to the interconnection of disparate 101 systems for the purposes of sharing presence information. This 102 interconnection involves passing of subscriptions from one system to 103 another, and then the passing of notifications in the opposite 104 direction. 106 [I-D.ietf-simple-interdomain-scaling-analysis] has analyzed the 107 amount of traffic, in terms of messages and in terms of bytes, which 108 flow between systems in various federated use cases. These numbers 109 demonstrate that presence traffic can be a substantial source of 110 overhead. The root cause of this scale challenge is the so-called 111 multiplicative effect of presence data. If there are N users, each 112 of which have B buddies on their buddy list, and each buddy changes 113 state L times per hour, the amount of notification traffic is 114 proportional to N*B*L. For example, in the case of two extremely 115 large public IM providers that federate with each other (each with 20 116 million users), [I-D.ietf-simple-interdomain-scaling-analysis] shows 117 that the amount of traffic due to these steady state notifications is 118 18.4 billion messages per day, an astoundingly large number. 119 Overhead for subscription maintenance and refreshes brings the total 120 to 25.6 billion per day. 122 The overhead for SIP-based presence can be reduced using SIP 123 optimizations. In particular, [I-D.ietf-sip-subnot-etags] can reduce 124 the amount of traffic due to refreshes and polls. However, this 125 optimization targets the overhead, and doesn't address the core 126 scaling problem - the multiplicative effect of presence data. 128 For this reason, there is a clear need to improve the scale of SIMPLE 129 in federated envrionments. 130 [I-D.ietf-sipping-presence-scaling-requirements] has laid out a set 131 of requirements for optimizations. The essence of these requirements 132 are that the extension should improve performance, while being 133 backwards compatible and supporting the privacy and policy 134 requirements of users. 136 This document defines a mechanism called view sharing in support of 137 those requirements. The key idea with view sharing is that when 138 there are many watchers in a domain to a single presentity in another 139 domain, each of which is actually going to get the exact same 140 presence document, the domain of the watchers extends a single 141 subscription to the domain of the presentity, and the domain of the 142 presentity sends a single copy of the presence document back to the 143 domain of the watcher. 145 In the case of a pair of large providers that are peering with each 146 other, this mechanism can result in a significant savings. Assuming 147 a symmetrical system whereby the average buddies per watcher is B and 148 the average number of watchers for a user is also B, if most buddies 149 are in one domain or the other, this optimization can reduce the 150 overall subscription overhead and notification traffic by a factor of 151 B/2. In cases where there are a large number of small domains, this 152 mechanism is less useful. Of course, in such cases, the amount of 153 traffic between any pair of domains is small anyway. 155 2. Overview of Operation 157 The extensions works in the environment shown in Figure 1. The 158 environment assumes two domains. There are some number of watchers 159 (W1 - W3) in the domain on the left, which we call the watching 160 domain. All of those watchers are interested in the presence of a 161 single presentity P1 in the domain on the right, which we call the 162 serving domain. The watchers all make use of a resource list server 163 (RLS) [RFC4662] which stores their buddy lists and performs the buddy 164 list expansion. Consequently, when each watcher subscribes to their 165 buddy list on the RLS, in absence of any optimizations, the RLS will 166 generate three separate subscriptions to P1, each of which reaches 167 the presence server in the serving domain. 169 . 170 +--------------+ . +--------------+ 171 | | . | | 172 | | SUB . | | 173 | | -------.---> | Presence | 174 | RLS | NOT . | Server | 175 | | <------.---- | | 176 | | . | | 177 | | . | | 178 +--------------+ . +--------------+ 179 ^ ^ ^ . ^ 180 List | | | . | PUB 181 SUB | | | . | 182 | | | . | 183 +----+ +----+ +----+ . +----+ 184 | | | | | | . | | 185 | W1 | | W2 | | W3 | . | P1 | 186 | | | | | | . | | 187 +----+ +----+ +----+ . +----+ 188 . 189 . 190 . 191 Watching . Serving 192 Domain . Domain 193 . 195 Figure 1: Deployment Model 197 Of course, in practice each domain will act as both a watching domain 198 and a serving domain, thus implementing both sides of the system. 200 The initial SUBSCRIBE generated by the RLS includes a SIP option tag 201 "view-share" in the Supported header field, indicating that the RLS 202 supports the view sharing extension. If the presence server also 203 supports the extension, it makes use of it and includes an indication 204 of this fact in the Require header field in the SUBSCRIBE response 205 and in NOTIFY requests it generates. 207 View sharing requires a level of trust between the two domains. 208 Consequently, the connection between them utilizes TLS with mutual 209 authentication. The presence server verifies that the certificate 210 presented in the mutual authentication matches the domain of the 211 watcher. 213 If this is the first subscription from domain 1 for that particular 214 presentity, the presence server accepts the subscription (assuming 215 the watcher is authorized of course). The notifications sent to the 216 RLS include two separate pieces of state. One is the actual presence 217 state for the presentity. The other is an Access Control List (ACL) 218 document. This document describes the set of other watchers from the 219 originating domain, if any, who are authorized to see exactly the 220 same presence document - in other words, the set of users that share 221 the same view. Should one of those watchers seek the presence of 222 that presentity, the RLS from the originating domain does not need to 223 generate a back-end subscription; rather, it just uses the presence 224 document it is receiving from the original subscription, and passes 225 it to both watchers. The ACL can also list users in the originating 226 domain that are authorized to subscribe to that presentity, but who 227 will end up receiving a different view. Should one of those watchers 228 subscribe, the RLS knows that it must perform a back-end subscription 229 to obtain that view. The ACL can also list watchers in the 230 originating domain that are not authorized at all, in which case the 231 RLS could immediately reject their subscriptions. Finally, if the 232 ACL says nothing about a particular watcher, it means that the 233 presence server has elected to say nothing about what view this 234 watcher will receive. Consequently, the RLS must perform a back-end 235 subscription should that watcher subscribe to the presentity. 237 Other subsequent subscriptions to the same presentity from the same 238 originating domain are processed in a similar way. However, the 239 presence server in the serving domain will keep track of the set of 240 subscriptions to the same presentity from the same RLS which are to 241 receive the same view. When a presence notification is to be sent, 242 instead of sending it on all subscriptions, the notification is sent 243 on just a single subscription. 245 Should the authorization policies in the serving domain change, an 246 updated ACL is sent, informing the watching domain of the new 247 policies. This may require the watching domain to extend a back-end 248 subscription to obtain a view, or may change the view an existing 249 watcher is receiving, and so on. 251 The ACL allows the serving domain a great deal of flexibility in the 252 level of trust it imparts to the watching domain. The following are 253 all possible approaches that the serving domain can utilize: 255 No Trust: When a presence server receives the subscription, it 256 elects not to use this mechanism at all using the negotiation 257 techniques defined here. 259 Minimal Trust: When a watcher subscribes to a presentity, the ACL 260 generated for that subscription includes only that watcher, along 261 with an identifier for their view. Consequently, for each watcher 262 in domain 1 there will be a backend subscription to domain 2. 263 However, should multiple watchers share the same view, the 264 presence server in domain 2 sends a single presence document on 265 one of the subscriptions, and the RLS uses this for all of the 266 other watchers with the same view. With this approach, domain 2 267 never discloses the list of authorized watchers ahead of time, and 268 it has full knowledge of each watcher that is subscribed. 269 However, it gets the performance benefits of reducing the amount 270 of notification traffic. 272 Partial Trust: When a watcher subscribes to a presentity, the ACL 273 generated for that subscription includes that watcher and all 274 other watchers authorized for that same view. Consequently, there 275 will only be one backend subscription from the RLS to the presence 276 server for each view. However, the full set of authorized 277 watchers is not disclosed ahead of time, only those that will get 278 the same view. With partial trust, the presence server will not 279 know the full set of watchers currently subscribed. 281 Full Trust: When a watcher subscribes to a presentity, the ACL 282 generated for that subscription includes that watcher and all 283 other watchers that are authorized for that view, and all other 284 views, along with a rule that says that all other watchers get 285 rejected. In this case, as with partial trust, there is only one 286 backend subscription from the RLS to the presence server for each 287 view. The full set of watchers is disclosed ahead of time as 288 well. The presence server will not know the full set of watchers 289 currently subscribed. 291 Depending on the level of trust, the mechanism trades off inter- 292 domain messaging traffic for increased processing load in the RLS to 293 handle the ACL documents. 295 3. RLS Behavior 297 This section defines the procedures that are to be followed by the 298 RLS. It is important to note that, even though this specification 299 defines an extension to the SIP events framework, that extension is 300 only useful for the back-end subscriptions generated by an RLS. The 301 extension defined here is not applicable or useful for individual 302 users generating subscriptions. Indeed, if it were utilized by 303 individual users, it has the potential for violations of user 304 privacy. See Section 8 for a discussion. 306 3.1. On Receipt of a Resource List Subscription Request 308 When the RLS receives a subscription to a resource list which 309 includes some presentity P in another domain, it follows the rules 310 defined here. 312 3.1.1. Authentication and Authorization 314 First, the RLS MUST check a configured list of peer domains for which 315 this extension is to be applied. Because of the potential privacy 316 disclosures involved in unauthorized use of this facility, it can 317 only be used between pairs of domains which have a pre-arranged 318 agreement to utilize it. If the domain of the presentity P matches 319 one of the configured list of peer domains, the RLS is permitted to 320 utilize this extension. If not, the extension MUST NOT be used. 322 Next, the RLS MUST send the SUBSCRIBE request over a mutually 323 authenticated TLS connection. The RLS MUST check that the 324 subjectAltName in the certificate of its peer contains a domain name 325 that is a match for the domain of the URI of the presentity. If they 326 are not a match, view sharing cannot be utilized for this 327 subscription. 329 The procedures followed by the RLS after this point depend on whether 330 the RLS already has a backend subscription to the presentity that is 331 in the active state, and for which an ACL has been received. 333 3.1.2. No Active Back-End Subscription 335 The RLS MUST generate a back-end subscription to obtain the state of 336 the presentity. The RLS MUST include a Supported header field in the 337 request with the option tag "view-share". The Accept header field 338 MUST be present in the request and MUST include the "application/ 339 aclinfo+xml" MIME type amongst the list of supported types. The RLS 340 MUST include an +sip.instance Contact header field parameter 341 [I-D.ietf-sip-outbound] to uniquely identify the RLS instance. 343 Note that it is possible that two watchers, in a short period of 344 time, both subscribe to their resource lists, both of which include 345 presentity P. This will cause the RLS to generate two back-end 346 subscriptions at around the same time. The RLS is forced to generate 347 the second back-end subscription because it doesn't have an active 348 back-end subscription that has yet generated an ACL. Once both 349 subscriptions become active and generate ACLs, if the watchers are 350 receiving the same view and both ACLs contain both watchers, the RLS 351 SHOULD terminate one of the back-end subscriptions. 353 3.1.3. Active Back-End Subscription 355 In this case, the RLS already has at least one back-end subscription 356 to the target presentity P, and it has received at least one ACL for 357 that presentity. It has received a resource list subscription from 358 watcher W which includes presentity P. Based on the procedures of 359 Section 3.2.1, the RLS will keep, for each presentity, the list of 360 the most recent ACLs received on each back-end subscription currently 361 in place. This is called the current ACL list. 363 For each ACL Ai in the current ACL list, the RLS performs the rule 364 determination algorithm of Section 5.4 to compute the rule ID R for 365 the watcher W. This represents the view that the watcher is supposed 366 to receive. 368 Next, the RLS goes through all subscriptions it currently has for 369 presentity P. For each one, it takes the identity of the watcher for 370 that actual subscription. The identity for the watcher for that 371 actual subscription is equal to the asserted identity included in the 372 back-end subscription. For example, if SIP Identity [RFC4474] is 373 utilized, this would be the URI present in the From header field of 374 the back-end SUBSCRIBE. Call the watcher identity for each 375 subscription Wj. 377 Next, the RLS computes the rule determination algorithm of 378 Section 5.4 to compute the rule ID Rj for the watcher Wj on each 379 subscription j. This represents the rule ID for the view being 380 delivered on that subscription. 382 Then, processing depends on the values of R and Rj: 384 o If R is null, it means that the ACL doesn't specify the view for 385 this watcher. The RLS MUST generate a back-end subscription to 386 presentity P, and MUST use watcher W as the identity in the back- 387 end subscription. 389 o If R is not null, but the associated rule is blocked, it means 390 that the watcher will be rejected. The RLS SHOULD NOT perform 391 another back-end subscription, and must act as if it had created a 392 back-end subscription which was rejected. 394 o If R is not null, and there is at least one subscription j for 395 which Rj = R, it means that subscription j is already generating 396 notifications for the view that watcher W is supposed to receive. 397 In that case, the RLS SHOULD NOT generate a back-end subscription 398 for P on behalf of W. Rather, it should treat the existing back 399 end subscription j as if it were the back-end subscription for W, 400 and follow the guidelines of RFC 4662 [RFC4662] based on that. 401 Subscription j is called the generating subscription for watcher 402 W, and the actual watcher associated with subscription j, Wj, is 403 called the generating watcher Wgen for watcher W. 405 o If R is not null, but there is no subscription j for which Rj=R, 406 it means that the RLS is not yet receiving the view that watcher W 407 requires. The RLS MUST generate a back-end subscription to 408 presentity P, and MUST use watcher W as the identity in the back- 409 end subscription. 411 3.2. Processing NOTIFY Requests 413 If a NOTIFY request arrives with a Require header field that includes 414 the "view-share" option tag, it MUST be processed according to the 415 rules of this specification. 417 3.2.1. Processing ACL-Infos 419 If the contents of the NOTIFY are of type "application/aclinfo+xml", 420 the subscriber processes the body as described here. 422 For each presentity that the RLS has at least one back-end 423 subscription for, the RLS MUST remember the most recent aclinfo 424 received on each back-end subscription. This is called the current 425 ACL list for the presentity. This set of aclinfo is used in the 426 processing of subscription requests, as described in Section 3.1.3. 428 The serving domain can change policies at any time. When it does, it 429 sends an updated ACL on one or more subscriptions. The RLS MUST 430 store this ACL. Furthermore, the ACL might impact the views being 431 received by watchers, and may impact the state of the back-end 432 subscriptions. 434 The RLS computes the set of watchers Wi which have a resource list 435 subscription that includes the presentity P for whom an updated ACL 436 has just been received. For each Wi, it performs the view 437 determination algorithm (see Section 5.4 on the current ACL set. Let 438 Ri be the view associated with watcher Wi. If Ri has not changed 439 from prior to the receipt of the new ACL, no action is taken. 440 However, if it has changed, the RLS takes the set of current back-end 441 subscriptions, and for each subscription j, computes the view 442 determination algorithm for its associated watcher Wj, to produce Rj. 443 The action to take depends on what has changed: 445 o If Ri is now null, it means that the serving domain has changed 446 the views associated with watcher Wi, and this new view is not 447 known to the RLS. The RLS MUST generate a new back-end 448 subscription on behalf of watcher Wi for presentity P to obtain 449 this view. 451 o If Ri is now a blocked rule, it means that the serving domain has 452 now blocked Wi from obtaining the presence of the presentity. The 453 RLS must act as if it had a back-end subscription on behalf of 454 watcher Wi which was terminated. 456 o If Ri is not null and not blocked, and if there is an Rj which 457 matches the new Ri, it means that the serving domain has changed 458 the views associated with watcher Wi, and changed them to another 459 view already being received by the RLS. The RLS MUST treat this 460 back-end subscription j as if it were the back-end subscription to 461 presentity P for watcher Wi. If the most recent presence document 462 received on this back-end subscription is not a semantic match for 463 the presence document most recently delivered to Wi for presentity 464 P, the RLS MUST send this most recent presence document to watcher 465 Wi. 467 o If Ri is not null and not blocked, but there is no Rj which 468 matches the new Ri, it means that the serving domain has changed 469 the views associated with watcher Wi, and this new view is not one 470 currently being delivered to the RLS. The RLS MUST generate a new 471 back-end subscription on behalf of watcher Wi for presentity P to 472 obtain this view. 474 Furthermore, if there are now two back-end subscriptions j1 and j2 475 for which Aj1 = Aj2, the RLS SHOULD terminate one of those two 476 subscriptions. Two ACL documents are considered equal if they 477 enumerate the same set of rules with the same members for each rule. 479 3.2.2. Processing Presence Documents 481 If the contents of the NOTIFY is a presence document, the RLS follows 482 the procedures defined here. 484 Let Wj be the watcher on the subscription j on which the presence 485 document was just received. Let Rj be the results of running the 486 rule determination algorithm on Wj using the current ACL set. Next, 487 the RLS takes the set of watchers Wi which have presentity P on their 488 buddy lists. The RLS then runs the rule determination algorithm on 489 each Wi using the current ACL set, producting Ri for each watcher Wi. 490 For each Ri that is equal to Rj, the RLS MUST utilize the presence 491 document just received as if the back-end subscription j was in fact 492 for watcher Wi. This will typically cause that presence document to 493 be sent in a NOTIFY request to each such watcher, though each watcher 494 may have some kind of filtering policy which causes the RLS to modify 495 the document prior to delivery. 497 3.2.3. Processing Back-End Terminations 499 If the NOTIFY request from the serving domain terminates the back-end 500 subscription, it may be because the watcher Wj associated with that 501 subscription is no longer permitted to view the presence of the 502 presentity. 504 The ACL associated with the subscription MUST be removed from the 505 current ACL set. The procedures of Section 3.2.1 MUST be performed 506 to adjust back-end subscriptions, if needed. 508 4. Presence Agent Behavior 510 When a presence agent receives a SUBSCRIBE request containing a 511 Supported header with the value "view-share", and it wishes to 512 utilize view sharing for this subscription, it follows the procedures 513 defined here. 515 4.1. Authentication and Authorization 517 First, the presence agent MUST have received the SUBSCRIBE request 518 over a mutually authenticated TLS connection. If it had not, view 519 sharing cannot be utilized for this subscription. The presence agent 520 MUST check that the subjectAltName in the certificate of its peer 521 contains a domain name that is a match for the domain of the URI of 522 the watcher. If they are not a match, view sharing cannot be 523 utilized for this subscription. 525 Assuming they are a match, the presence agent MUST check a configured 526 list of peer domains for which this extension is to be applied. 527 Because of the potential privacy disclosures involved in unauthorized 528 use of this facility, it can only be used between pairs of domains 529 which have a pre-arranged agreement to utilize it. If the domain of 530 the watcher W matches one of the configured list of peer domains, the 531 presence agent is permitted to utilize this extension. If not, the 532 extension MUST NOT be used. 534 4.2. Processing Initial SUBSCRIBE Requests 536 First, the subscription is processed as it normally would be, 537 including authorization and policy around the presence document to be 538 delivered to the watcher. Furthermore, if the presence agent wishes 539 to utilize view sharing for this subscription, it MUST include a 540 Require header field in the first NOTIFY request (and indeed any 541 subsequent ones) it sends confirming this subscription, and that 542 NOTIFY MUST contain the "view-share" option tag. 544 Furthermore, the initial state sent by the presence agent MUST 545 include an ACL document. It is formatted according to the rules and 546 considerations in Section 5. 548 The initial state sent by the presence agent might include an actual 549 presence document. In particular, a presence document MUST be sent 550 if one of the following is true: 552 o There is only one subscription from the watching domain to this 553 presentity that has the view associated with the watcher. 555 o There is more than one subscription from the watching domain to 556 this presentity with the same view, but the +sip.instance 557 parameter for the remote target (as conveyed in the Contact header 558 field of the SUBSCRIBE) differs. In other words, these 559 subscriptions are from the same domain, but from different RLS in 560 the watching domain. Each RLS in the watching domain needs to get 561 their own copy of the view for a particular presentity. 563 If one of these conditions is not true, the presence agent SHOULD NOT 564 send an initial presence document on this subscription. 566 If an ACL and a presence document are to be delivered, they MUST be 567 delivered in a separate NOTIFY request (unless the subscriber 568 indicated support for multipart, in which case the content MAY be 569 included in a single NOTIFY with mulitpart content). 571 4.3. SUBSCRIBE Refreshes 573 When the presence agent receives a SUBSCRIBE refresh, it MUST send 574 the most recent ACL document, and if presence documents are being 575 sent for this subscription, the most recent presence document. 577 4.4. Policy Changes 579 There are several different types of policy changes that can occur: 581 o If the definitions for a particular rule change, the presence 582 agent MUST assign a new rule ID for that rule. For each 583 subscription to a presentity which contained that rule, the 584 presence agent MUST send an updated ACL which includes a rule with 585 this new rule ID. 587 o If some watcher W was previously associated with rule X and is now 588 associated with rule Y, the presence agent checks if it has any 589 subscriptions from watcher W. If it does, it MUST send an updated 590 ACL on that subscription. Based on the rules in Section 5, this 591 ACL will contain rule Y and will at least include W amongst the 592 list of members. Furthermore, if there were subscriptions from 593 other watchers, but the presence agent had previously sent an ACL 594 on the subscription which was a match for W, it MUST send an 595 updated ACL on that subscription. This updated ACL MAY omit a 596 statement about rule Y or MAY include it. However, the updated 597 ACL MUST NOT claim that watcher W will receive rule X. 599 o If some watcher W was previously associated with rule X and is now 600 blocked, the presence agent checks if it has any subscriptions 601 from watcher W. If it does, it MUST terminate the back-end 602 subscription. If it doesn't, but it has a subscription from some 603 other watcher which had included a rule that was a match for W, 604 the presence agent MUST send an updated ACL on that subscription. 605 This updated ACL MAY omit any statement about watcher W, or MAY 606 include them as part of a blocked rule in that ACL. 608 o If some watcher W was previously blocked and is now permitted and 609 associated with some rule X, the presence agent checks if it had 610 any subscriptions from some other watcher which included a blocked 611 rule that matched watcher W. If it had, it MUST send an updated 612 ACL on that subscription. That updated ACL MAY omit any statement 613 about watcher W, or MAY indicate that watcher W is now associated 614 with rule X. 616 Of course, a policy change will also potentially alter the presence 617 documents that are associated with a view. If so, the presence agent 618 MUST send an updated document on a subscription if one of the 619 following is true: 621 o There is only one subscription from the watching domain to this 622 presentity that has the view associated with the watcher. 624 o There is more than one subscription from the watching domain to 625 this presentity with the same view, but the User-Agent header 626 field in the request differs between them. 628 If neither is true, the presence agent MUST select one subscription 629 amongst the several which share the same presentity, view, and User- 630 Agent header field, and sent an updated notification on that 631 subscription. The choice of subscriptions is arbitrary and MAY 632 change for each notification. 634 4.5. Presence State Changes 636 If the state of some presentity changes, the presence agent may need 637 to send an updated notification on a subscription. The presence 638 agent MUST send an update on a subscription if one of the following 639 is true: 641 o There is only one subscription from the watching domain to this 642 presentity that has the view associated with the watcher. 644 o There is more than one subscription from the watching domain to 645 this presentity with the same view, but the User-Agent header 646 field in the request differs between them. 648 If neither is true, the presence agent MUST select one subscription 649 amongst the several which share the same presentity, view, and User- 650 Agent header field, and sent an updated notification on that 651 subscription. The choice of subscriptions is arbitrary and MAY 652 change for each notification. 654 5. ACL Format 656 An ACL document is an XML [W3C.REC-xml-20001006] document that MUST 657 be well-formed and MUST be valid according to schemas, including 658 extension schemas, available to the validater and applicable to the 659 XML document. ACL documents MUST be based on XML 1.0 and MUST be 660 encoded using UTF-8. This specification makes use of XML namespaces 661 for identifying ACL documents and document fragments. The namespace 662 URI for elements defined by this specification is a URN [RFC2141], 663 using the namespace identifier 'ietf' defined by RFC 2648 [RFC2648] 664 and extended by RFC 3688 [RFC3688]. This URN is: 666 urn:ietf:params:xml:ns:aclinfo 668 5.1. Document Structure and Semantics 670 An ACL document informs a watching domain of the set of views that 671 can be received by that domain, and associates specific watchers with 672 specific views. It is very important to understand that the ACL 673 document does not convey the actual processing that will be applied 674 by the serving domain. It does not indicate, for example, whether 675 geolocation is present in a presence document, or which rich presence 676 [RFC4480] data elements will be conveyed. It merely provides 677 grouping - indicating which watchers from the watching domain will 678 receive the same view. 680 Each ACL document starts with the enclosing root element . 682 This contains the list of rules defined by the ACL. Each rule is 683 represented by the element. Each rule represents a specific 684 view, which is generated by the presence server based on its 685 authorization, composition and filtering policies. Each rule is 686 associated with a rule ID, which is a mandatory attribute of the 687 element. This ID is scoped within a single presentity. That 688 is, the IDs for two rules for different presentities are unrelated. 690 The element also contains an optional "blocked" boolean 691 attribute. If "true", it means that the rule specifies that the 692 associated set of watchers will be rejected, should they subscribe. 693 This can be used by the watching domain to avoid performing back-end 694 subscriptions to users which will only be blocked anyway. 696 Each contains the set of users that will receive the 697 corresponding view. This can be described by an enumerated set or by 698 a default. If it is an enumerated set, the is followed by a 699 sequence of elements, each of which contains a SIP URI for 700 the watcher that will receive that view. 702 The default view is specified by including a single child element for 703 - . The default view applies to all watchers except 704 those enumerated by other rules. For this reason, an ACL document 705 which contains a default view MUST include the rule IDs and 706 associated members for all other views that are delivered to 707 watchers. For example, consider a presentity that has three views. 708 View 1 is delivered to watchers A and B. View 2 is delivered to 709 watcher C. View 3 is delivered to everyone else. An ACL document 710 that includes the default view must also include views 1 and 2 with 711 watchers A, B, and C. 713 In contrast, an ACL document that does not include a default does not 714 need to include all views, and it does not need to include all 715 members for a particular view. Using the example above, it is valid 716 to include an ACL document which includes only view 1 with watcher 1. 718 If two URI are present within elements within the same 719 , it represents a contract by the presence server that both 720 users MUST get the same view. Formally, if the presence server were 721 to receive a subscription from each watcher, both subscriptions would 722 be accepted or both would be rejected, and if accepted, each 723 subscription would receive semantically identical presence documents 724 at approximately the same time. 726 Even if two users will receive the same view, a presence server MAY 727 assign each to a different view ID. There is no requirement that two 728 unique views actually contain different presence data. The only 729 requirement is that, if two users are listed within the same rule, 730 that they do in fact receive the same view. 732 An ACL document delivered in a subscription from watcher W MUST 733 include the view associated with watcher W and MUST include watcher W 734 explicitly in a element or implicitly by presence of an 735 element. 737 5.2. Trust Considerations when Construcing ACLs 739 The semantics above give very little guidance about what a presence 740 server should include in an ACL. The amount of information to convey 741 depends on the level of trust between the watching and serving 742 domains. 744 Optimal performance is achieved when the ACL document for a 745 presentity includes all views that the server might ever deliver, and 746 includes all members for each view, including any defaults and 747 blocked rules. However, this informs the watching domain of the set 748 of allowed and blocked watchers, and associated groupings amongst 749 watchers. 751 Slightly worse performance is achieved when the ACL document for a 752 presentity sent in a subscription from watcher W includes only a 753 single view - the one for watcher W - along with the full set of 754 watchers which will also receive that view, assuming it is not the 755 default view. If the view is the default view, the document can 756 include just watcher W. This approach will cause back-end 757 subscriptions from every watcher that will receive the default, but 758 it discloses less information to the watching domain. In particular, 759 the full set and number of views is never known by the watching 760 domain. The fact that a view is default is never known by the 761 watching domain. The full set of users that are permitted to view 762 the presence of the presentity is never disclosed to the watching 763 domain. The performance of this approach is still reasonably good 764 when the default rule is blocked. However it is much less effective 765 when the default is not blocked, and many watchers receive the 766 default. 768 Another choice for construction of ACL documents is to include, in a 769 subscription from watcher W, a single rule containing the rule ID for 770 the view that watcher W will receive, along with a single member - W. 771 This approach will still result in a back-end subscription from each 772 watcher. However, a single notification is sent for each view, 773 rather than one per watcher. The benefit of this construction is 774 that it provides the watching domain no additional information about 775 the authorization policies of the presentity than if this extension 776 were not in use at all. 778 5.3. Example Documents 780 The example document in Figure 2 shows the case when there is maximum 781 trust between domains. The full set of watchers, include a blocked 782 default, is included. 784 785 786 787 788 sip:user1@example.com 789 sip:user2@example.com 790 sip:user3@example.com 791 sip:user4@example.com 792 sip:user5@example.com 793 794 795 sip:user6@example.com 796 797 798 sip:user7@example.com 799 sip:user8@example.com 800 sip:user9@example.comm 801 sip:user10@example.com 802 sip:user11@example.com 803 804 805 806 807 809 Figure 2: Example with Maximum Trust 811 The example in Figure 3 shows a moderate level of trust. This ACL 812 only shows the view associated with the watcher user1. 814 815 816 817 818 sip:user1@example.com 819 sip:user2@example.com 820 sip:user3@example.com 821 sip:user4@example.com 822 sip:user5@example.com 823 824 826 Figure 3: Example with Partial Trust 828 The example in Figure 4 shows the minimal level of trust. This ACL 829 would be sent in a subscription to user1. 831 832 833 834 835 sip:user1@example.com 836 837 839 Figure 4: Example with Minimal Trust 841 5.4. Rule Determination Algorithm 843 Several steps in the processing of the ACL require that the RLS in 844 the watching domain execute the rule determination algorithm for 845 watcher W on an ACL set. This algorithm is a simple algorithm which 846 takes, as input, a watcher W with a given SIP URI, and a set of ACL 847 documents Ai, and returns as output, a rule ID R, which is the rule 848 ID for the view that, according to the set of ACLs, watcher W should 849 receive. 851 The algorithm proceeds as follows. First, each Ai is matched to W. 852 ACL Ai is a match for watcher W if: 854 o ACL Ai contains a tag whose URI is a match, based on URI 855 equality, for W, or 857 o none of the tags in Ai contain a URI that is a match, 858 based on URI equality, for W, but there is an element in 859 Ai 861 If no ACL Ai matched, the algorithm returns a null result. 863 For each ACL Ai that matches based on the rules above, take the id of 864 the enclosing element that contained the or 865 element that caused the match. For ACL Ai, this is rule Ri. For 866 example, consider the following ACL: 868 869 870 871 sip:user1@example.com 872 sip:user2@example.com 873 874 875 sip:user3@example.com 876 877 878 879 880 882 If this document is A1, and the watcher is sip:user3@example.com, the 883 associated rule R1 is 2. If the watcher is sip:user1@example.com or 884 sip:user2@example.com, the rule R1 is 1. If the watcher is anyone 885 else from example.com, such as sip:user4@example.com, the rule R1 is 886 3. 888 If all Ri are equal, denote R = Ri. Thus, R is the rule ID 889 associated with this watcher. Normally, all Ri will be equal. 890 However, during transient periods of changes in authorization state, 891 it is possible that inconsistent ACL documents exist. In that case, 892 R is assigned the value Ri from the ACL Ai which is the most recently 893 received amonst all ACL. 895 5.5. XML Schema 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 920 6. Performance Analysis 922 This section considers the performance improvement of the mechanism 923 when it is maximally exercised. In that case, the full ACL, 924 including blocked senders, is returned in the first subscription to a 925 presentity. This analysis assumes there is a single, monolithic 926 presence server serving each domain. 928 The optimizations improve ramp-up, steady state, and termination 929 message loads. In particular, each of those loads, without the 930 optimization described here, is proportional to C04, the total number 931 of federated presentities per watcher. If we assume symmetry, such 932 that the number of federated presentities per watcher is equal to the 933 number of watchers per federated presentity, then each of the load 934 figures is reduced by C04. That is, the system behaves identically 935 to the case where there is a single watcher per federated presentity, 936 and assuming symmetric, the same as if there is a single federated 937 presentity per watcher - e.g., C04 = 1. 939 Consider then the very large network peering model in 941 [I-D.ietf-simple-interdomain-scaling-analysis]. In this model, the 942 assumption is two large peering domains with 20 million users each, 943 with a value of 10 for C04. With this optimization, the number of 944 steady state notifications due to presence state changes drops from 945 18.4 billion per day to 1.84 billion per day. The number of messages 946 per second overall is reduced from 654,167 per second to 65,417 per 947 second. Still a big number, of course, but it can't actually get 948 much smaller. 950 Indeed, it can be readily shown that, assuming the federated domains 951 do not actually share raw presence inputs and the actual policies 952 that govern operation of their servers, no protocol can do better 953 (constants, such as mesage size and the need for protocol responses 954 and acknowledgements aside). Consider a domain with N presentities. 955 Each presentity changes state P times per hour. Every time the state 956 changes, the domain applies its authorization and composition 957 policies. The resulting presence document cannot be known to the 958 watching domain. Thus, there must be at least one message from the 959 serving to watching domain, per view, in order to inform it of that 960 view. This means that the steady state rate of messages can never be 961 better than N*P, and this is exactly the factor governing the rate of 962 messages when this optimization is applied. 964 7. Requirements Analysis 966 This section analyzes the requirements in 967 [I-D.ietf-sipping-presence-scaling-requirements] to show how they are 968 met by the mechanism proposed here. 970 REQ-001: The solution should not hinder the ability of existing 971 SIMPLE clients and/or servers from peering with a domain or client 972 implementing the solution. No changes may be required of existing 973 servers to interoperate. This requirement is met by usage of the 974 Supported and Require mechanisms and SIP which negotiate its 975 usage. 977 REQ-002: It does NOT constrain any existing RFC functional or 978 security requirements for presence. The mechanism does not change 979 anything that is possible without it. It does, however, introduce 980 new privacy considerations, described below in Section 8. 982 REQ-003: Systems that are not using the new additions to the 983 protocol should operate at the same level as they do today. This 984 requirement is met by usage of the Supported and Require 985 mechanisms in SIP. 987 REQ-004: The solution does not limit the ability for presentities to 988 present different views of presence to different watchers. This 989 requirement is met by usage of the ACL document, which allows the 990 serving domain to associate a watcher with any view it likes, and 991 to change it over time. 993 REQ-005: The solution does not restrict the ability of a presentity 994 to obtain its list of watchers. The mechanism does allow a 995 presence server to know the list of watchers, at the expense of 996 non-optimal performance. In particular, it will receive a 997 subscription from each watcher. However, it only generates one 998 notification per view on presence changes. The fully optimized 999 solution will result in a loss of knowledge of the set of 1000 watchers. However, it is a policy decision at the presence agent 1001 about whether it would like to make this tradeoff. 1003 REQ-006: The solution MUST NOT create any new or make worse any 1004 existing privacy holes. This requirement is met, but only when 1005 carefully provisioned. See Section 8. 1007 REQ-007: It is highly desirable for any presence system (intra or 1008 inter-domain) to scale linearly as number of watchers and 1009 presentities increase linearly. When the most optimal technique 1010 is used, there is always one subscription per view per presentity, 1011 independent of the number of watchers in the remote domain or the 1012 number of averages buddies per buddy list. Since the number of 1013 views is not proportional to the number of users, the total 1014 traffic volume in a domain is linear with its number of 1015 presentities, and is independent of the number of users in the 1016 peering domain. 1018 REQ-008: The solution SHOULD NOT require significantly more state in 1019 order to implement the solution. The mechanism requires storage 1020 of the ACL, which has a size exactly equal to the number of 1021 subscriptions that would be required if the extension were not in 1022 place. Thus the memory usage is not worsened compared to the 1023 baseline. 1025 REQ-009: It MUST be able to scale to tens of millions of concurrent 1026 users in each domain and in each peer domain. The analysis in 1027 Section 6 shows that, when fully utilized, this mechanism is the 1028 best that can possibly be achieved in any system that does not 1029 actually share policies and raw presence data. 1031 REQ-010: It MUST support a very high level of watcher/presentity 1032 intersections in various intersection models. The mechanism is 1033 optimized for this case. 1035 REQ-011: Protocol changes MUST NOT prohibit optimizations in 1036 different deployment models esp. where there is a high level of 1037 cross subscriptions between the domains. Since standard SIP 1038 techniques are utilized to negotiate the extension, other 1039 mechansims can be defined in the future. 1041 REQ-012: New functionalities and extensions to the presence protocol 1042 SHOULD take into account scalability with respect to the number of 1043 messages, state size and management and processing load. That is 1044 exactly what this extension targets. 1046 REQ-013: The solution SHOULD allow for arbitrary federation 1047 topologies including direct peering and intermediary routing. The 1048 mechanism is optimized for direct peering. It can work in 1049 intermediary routing cases as well. 1051 8. Security Considerations 1053 The principal question with the specification is whether it alters 1054 the privacy characteristics of a non-optimized federated system. 1056 Consider first the case where the serving domain is using the minimal 1057 trust model. In that case, the ACL provided to the watching 1058 information does not carry any information that the watching domain 1059 doesn't already know. It merely points out when two watchers share 1060 the same view. This is something that the watching domain could have 1061 already ascertained by comparing presence documents delivered to each 1062 watcher. The ACL makes this task easier, but nonetheless the 1063 watching domain could have already ascertained it. Consequently, 1064 there is no change whatsoever in the level of privacy afforded by the 1065 optimization when this mode is used. 1067 However, when an ACL is provided that includes other users besides 1068 the actual watcher, this provides additional information to the 1069 watching domain. This is, however, information that the watching 1070 domain could find out anyway. If it generated a subscription from 1071 each of its users to the presentity it would be able to determine who 1072 from its domain is allowed to subscribe and what view they would 1073 receive. This would be an expensive operation to be sure, but it is 1074 possible. Consequently, the optimization doesn't really provide 1075 anything new to the originating domain, even in this case. 1077 However, there is an attack possible when the information is divulged 1078 to an end user. Consider a watching domain that doesn't actually 1079 implement this extension at all. A user within the domain uses a 1080 client that generates a subscription to a presentity in a remote 1081 domain. This subscription uses an outbound proxy in the watching 1082 domain. The outbound proxy is just a proxy, and therefore doesn't 1083 remove or modify the Supported header field in the request. The 1084 serving domain accepts the subscription and sends an ACL that 1085 contains the full set of watchers that are permitted in the 1086 originating domain. The original watcher now knows the set of other 1087 authorized buddies within their own domain, and what views they will 1088 see. While this is information that the domain overall would have 1089 access to, it is not information an end user would normally have 1090 access to. Consequently, this is a more serious privacy violation. 1092 It is for this reason that this specification requires that both 1093 sides of the federated link be explicitly provisioned to utilize this 1094 optimization. In the attack above, the watching domain would not 1095 have set up a peering relationship with the serving domain. If it 1096 had, it would have an RLS and would not have permitted the user to 1097 directly subscribe in this way. Thus, when the subscription is 1098 received by the serving domain, it will find that it has no agreement 1099 with the originating domain, and would not utilize view sharing. 1100 This thwarts the attack. 1102 This remedy is not optimal because it requires on provisioning to 1103 prevent. There does not appear to be any easy cryptographic means to 1104 prevent it, however. 1106 In all cases, view sharing requires secure authentication and 1107 encryption between the domains that use it. This is provided by TLS. 1109 9. IANA Considerations 1111 There are several IANA considerations associated with this 1112 specification. 1114 9.1. MIME Type Registration 1116 This specification requests the registration of a new MIME type 1117 according to the procedures of RFC 2048 [RFC2048] and guidelines in 1118 RFC 3023 [RFC3023]. 1120 MIME media type name: application 1122 MIME subtype name: aclinfo+xml 1124 Mandatory parameters: none 1125 Optional parameters: Same as charset parameter application/xml as 1126 specified in RFC 3023 [RFC3023]. 1128 Encoding considerations: Same as encoding considerations of 1129 application/xml as specified in RFC 3023 [RFC3023]. 1131 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 1132 Section 8 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace 1133 XXXX with the RFC number of this specification]]. 1135 Interoperability considerations: none. 1137 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: 1138 Please replace XXXX with the RFC number of this specification]] 1140 Applications which use this media type: This document type has 1141 been used to support subscriptions to lists of users [RFC4662] for 1142 SIP-based presence [RFC3856]. 1144 Additional Information: 1146 Magic Number: None 1148 File Extension: .acl 1150 Macintosh file type code: "TEXT" 1152 Personal and email address for further information: Jonathan 1153 Rosenberg, jdrosen@jdrosen.net 1155 Intended usage: COMMON 1157 Author/Change controller: The IETF. 1159 9.2. URN Sub-Namespace Registration 1161 This section registers a new XML namespace, as per the guidelines in 1162 RFC 3688 [RFC3688]. 1164 URI: The URI for this namespace is urn:ietf:params:xml:ns:aclinfo. 1166 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1167 Jonathan Rosenberg (jdrosen@jdrosen.net). 1169 XML: 1171 BEGIN 1172 1173 1175 1176 1177 1179 ACL Info Namespace 1180 1181 1182

Namespace for ACL Info

1183

urn:ietf:params:xml:ns:aclinfo

1184

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

1187 1188 1189 END 1191 9.3. Schema Registration 1193 This section registers an XML schema per the procedures in [RFC3688]. 1195 URI: urn:ietf:params:xml:schema:aclinfo 1197 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1198 Jonathan Rosenberg (jdrosen@jdrosen.net). 1200 The XML for this schema can be found as the sole content of 1201 Section 5.5. 1203 10. Acknowledgements 1205 The authors would like to thank Avshalom Houri and Michael Froman for 1206 their comments on this document. 1208 11. References 1210 11.1. Normative References 1212 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1213 Initiation Protocol (SIP) Event Notification Extension for 1214 Resource Lists", RFC 4662, August 2006. 1216 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1217 Authenticated Identity Management in the Session 1218 Initiation Protocol (SIP)", RFC 4474, August 2006. 1220 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1222 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1223 August 1999. 1225 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1226 January 2004. 1228 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1229 Internet Mail Extensions (MIME) Part Four: Registration 1230 Procedures", BCP 13, RFC 2048, November 1996. 1232 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1233 Types", RFC 3023, January 2001. 1235 [W3C.REC-xml-20001006] 1236 Maler, E., Paoli, J., Bray, T., and C. Sperberg-McQueen, 1237 "Extensible Markup Language (XML) 1.0 (Second Edition)", 1238 World Wide Web Consortium FirstEdition REC-xml-20001006, 1239 October 2000, 1240 . 1242 [I-D.ietf-sip-outbound] 1243 Jennings, C. and R. Mahy, "Managing Client Initiated 1244 Connections in the Session Initiation Protocol (SIP)", 1245 draft-ietf-sip-outbound-15 (work in progress), June 2008. 1247 11.2. Informative References 1249 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for 1250 Presence and Instant Messaging", RFC 2778, February 2000. 1252 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 1253 W., and J. Peterson, "Presence Information Data Format 1254 (PIDF)", RFC 3863, August 2004. 1256 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 1257 July 2006. 1259 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1260 Initiation Protocol (SIP)", RFC 3856, August 2004. 1262 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 1263 Rosenberg, "RPID: Rich Presence Extensions to the Presence 1264 Information Data Format (PIDF)", RFC 4480, July 2006. 1266 [I-D.ietf-simple-interdomain-scaling-analysis] 1267 Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., 1268 and H. Schulzrinne, "Presence Interdomain Scaling Analysis 1269 for SIP/SIMPLE", 1270 draft-ietf-simple-interdomain-scaling-analysis-04 (work in 1271 progress), February 2008. 1273 [I-D.ietf-sip-subnot-etags] 1274 Niemi, A., "An Extension to Session Initiation Protocol 1275 (SIP) Events for Conditional Event Notification", 1276 draft-ietf-sip-subnot-etags-02 (work in progress), 1277 February 2008. 1279 [I-D.ietf-sipping-presence-scaling-requirements] 1280 Houri, A., Parameswar, S., Aoki, E., Singh, V., and H. 1281 Schulzrinne, "Scaling Requirements for Presence in SIP/ 1282 SIMPLE", 1283 draft-ietf-sipping-presence-scaling-requirements-00 (work 1284 in progress), February 2008. 1286 Authors' Addresses 1288 Jonathan Rosenberg 1289 Cisco 1290 Edison, NJ 1291 US 1293 Phone: +1 973 952-5000 1294 Email: jdrosen@cisco.com 1295 URI: http://www.jdrosen.net 1297 Steve Donovan 1298 Cisco 1299 Richardson, TX 1300 US 1302 Email: stdonova@cisco.com 1304 Kathleen McMurry 1305 Cisco 1306 Richardson, TX 1307 US 1309 Email: kmcmurry@cisco.com 1311 Full Copyright Statement 1313 Copyright (C) The IETF Trust (2008). 1315 This document is subject to the rights, licenses and restrictions 1316 contained in BCP 78, and except as set forth therein, the authors 1317 retain all their rights. 1319 This document and the information contained herein are provided on an 1320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1322 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1323 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1324 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1327 Intellectual Property 1329 The IETF takes no position regarding the validity or scope of any 1330 Intellectual Property Rights or other rights that might be claimed to 1331 pertain to the implementation or use of the technology described in 1332 this document or the extent to which any license under such rights 1333 might or might not be available; nor does it represent that it has 1334 made any independent effort to identify any such rights. Information 1335 on the procedures with respect to rights in RFC documents can be 1336 found in BCP 78 and BCP 79. 1338 Copies of IPR disclosures made to the IETF Secretariat and any 1339 assurances of licenses to be made available, or the result of an 1340 attempt made to obtain a general license or permission for the use of 1341 such proprietary rights by implementers or users of this 1342 specification can be obtained from the IETF on-line IPR repository at 1343 http://www.ietf.org/ipr. 1345 The IETF invites any interested party to bring to its attention any 1346 copyrights, patents or patent applications, or other proprietary 1347 rights that may cover technology that may be required to implement 1348 this standard. Please address the information to the IETF at 1349 ietf-ipr@ietf.org. 1351 Acknowledgment 1353 Funding for the RFC Editor function is provided by the IETF 1354 Administrative Support Activity (IASA).