idnits 2.17.1 draft-ietf-simple-publish-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 11, 2003) is 7744 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 3265 (ref. '2') (Obsoleted by RFC 6665) == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-pidf-07 -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE B. Campbell 3 Internet-Draft dynamicsoft 4 Expires: August 12, 2003 S. Olson 5 Microsoft 6 J. Peterson 7 NeuStar, Inc. 8 J. Rosenberg 9 dynamicsoft 10 B. Stucker 11 Nortel Networks, Inc. 12 February 11, 2003 14 SIMPLE Presence Publication Requirements 15 draft-ietf-simple-publish-reqs-00 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 12, 2003. 40 Copyright Notice 42 Copyright (C) The Internet Society (2003). All Rights Reserved. 44 Abstract 46 This document describes requirements for an extension to the Session 47 Initiation Protocol (SIP) [1]. The purpose of this extension would 48 be to create a means for publishing event state used within the 49 framework for SIP Event Notification (RFC3265 [2]). The first 50 application of this extension is targeted at the publication of 51 presence information as defined by the SIMPLE [5] working group. 53 1. Introduction 55 1.1 Publication Model 57 The following sections outline a model for publication of event 58 state, in particular presence information. This model further 59 defines the problem that this mechanism is attempting to solve. 61 The method described in this document allows presence information to 62 be published to a presence agent on behalf of a user. This method 63 can be extended to support publication of other event state, but it 64 is not intended to be a general-purpose mechanism for transport of 65 arbitrary data as there are better suited mechanisms for this purpose 66 (ftp, http, etc.) This method is intended to be a simple, light- 67 weight mechanism that employs SIP in order to support SIMPLE 68 services. 70 1.1.1 Presence Composition 72 Most existing presence services involve a single PUA that has 73 complete presence for a given presentity. This allows for a very 74 simple model where that PUA sends full presence state to a PA, which 75 then distributes it to watchers. 77 But this is a limited view of presence. In general, the presence 78 state of a presentity may be derived from many different inputs. A 79 complete view of presence for a presentity is likely to be derived 80 from more than one source, where the the complete view of presence 81 state is composed of the presence state from each source. Therefore, 82 any given PUA is unlikely to be able to provide complete presence 83 information. This document proposes a logical model for publishing 84 presence information from multiple PUAs to a presence compositor, 85 that can act as a presence agent. 87 Presence composition is a logical function in a presence distribution 88 system. This function is fulfilled by a logical element known as a 89 "presence compositor". A presence compositor accepts presence inputs 90 from one or more PUAs, and composes these inputs into a composite 91 presence document. 93 +-----------------+ +----------+ 94 | Presence | | Presence | 95 | Compositor +------+ Agent | 96 | | | | 97 | | | | 98 +--------+--------+ +----------+ 99 | 100 | 101 +----------+---------+ 102 | | | 103 | | | 104 +--+--+ +--+--+ +--+--+ 105 | PUA | | PUA | | PUA | 106 +-----+ +-----+ +-----+ 108 Each PUA publishes its view of presence to the Presence Compositor, 109 which then relays the composed presence information to a presence 110 agent for distribution. It must be possible for each PUA publishes a 111 full view of presence from its perspective--each publication carries 112 full state, and does not depend on previous states for the particular 113 PUA. A PUA does not need to know whether or not other PUAs are also 114 publishing presence information to the compositor. 116 The transformations that a presence compositor uses for this 117 composition are entirely a matter of local policy. The policy could 118 be as simple as the creation of a combined CPIM PIDF [4] document 119 where each input represents a separate tuple. It can also involve 120 more complex transformations, such as modifying the information from 121 one source based on information from another source. 123 1.1.2 Interface between the Compositor and the PA 125 The interface between a compositor and a PA is also a matter of local 126 policy. The compositor might act as a PUA itself, and publish 127 presence to the PA just like any other PUA might. The compositor and 128 the PA may be co-located, and communicate via local procedure calls. 129 Specification of this interface is beyond the scope of this document. 131 1.2 Why use SIP for publication? 133 Two principal protocol candidates have been evaluated for presence 134 state publication from a PUA to a presence compositor: HTTP and SIP. 135 This document recommends the use of SIP for presence publication for 136 the following reasons. 138 1.2.1 HTTP 140 HTTP is well suited for moving data around in the form of MIME body 141 parts. An HTTP client-to-server publication solution would not 142 require much work to specify. A SOAP over HTTP solution would 143 additionally allow complex transaction semantics with little 144 additional work. HTTP, however, does not have a well-defined routing 145 model at the application level. It works fine if the publication 146 point is well known and fairly static, but it will require additional 147 work to deal with situations where the publication point changes 148 dynamically. 150 1.2.2 SIP 152 SIP, on the otherhand, is built around the concept of mobility of 153 endpoints. The SIP proxy, registrar, and location service concepts 154 provide a rich mechanism of finding a dynamically changing endpoint 155 from and address of record. The application-level routing 156 capabilities of SIP can be very useful for presence publication. If 157 all PUAs for a given presentity exist in the same administrative 158 domain, then they can most likely publish directly to a compositor. 159 But if PUAs exist outside the administrative domain, it is likely 160 they will not be able to do so. 162 For example, suppose that Alice uses a presence service that allows 163 multiple PUAs to publish to a compositor inside the service provider 164 network. Further suppose that Alice wishes to incorporate presence 165 information from an external provider, that has no business 166 relationship with her primary provider. For this example, Alice 167 wishes to use a shared browsing service that tracks the "location" 168 she is currently browsing in the web. That service acts as a PUA on 169 Alice's behalf, and publishes the information to her primary presence 170 provider. Other users of the shared browsing service can subscribe 171 to her presence information, and determine when they are browsing the 172 same site. 174 The presence provider is highly unlikely to allow the external PUA to 175 send data directly to the compositor. But if Alice registers a 176 contact with a methods parameter value of "PUBLISH", that PUA can 177 send a publish request to an edge proxy in the presence providers 178 network, and use Alice's address of record as the requestURI. This 179 AoR could be her normal SIP URI, or it could be a special AoR for the 180 purposes of presence publication. The proxy forwards the request to 181 the compositor, without the external PUA having to talk directly to 182 the compositor, or even know its IP address. 184 Now consider that Alice's primary providor is actually an enterprise. 185 That enterprise has different compositors for different departments. 187 The external provider has no way of knowing this internal 188 organization, nor does it know what department Alice works in. 189 Still, Alice register's her publication contact at an enterprise 190 registrar, the external provider sends the publish request to Alice's 191 address of record, and the companies internal SIP network handles 192 things from there, eventually getting the request to the correct 193 compositor. 195 The composition model does not at first appear to require publishing 196 to dynamically changing PAs. But a very powerful, but often 197 forgotten, aspect of SIMPLE is it allows a PA to exist on an end-user 198 device. Indeed, some early implentations of SIMPLE rely on exactly 199 that model. It is reasonable to expect the composition model above 200 to co-exist with end-user device PAs, where the PA location changes 201 dynamically. 203 For example, imagine Alice hosts a PA on her PC, which aquires its IP 204 address via DHCP. This address changes relatively frequently, and 205 registers a publish contact with an enterprise registrar. Now, 206 imagine she also has a mobile phone which contains a PUA. She wants 207 her presence document to show a combined view of her PCs concept of 208 her presence and her mobile phone service's concept of her precence. 209 She cannot simply tell the mobile service her PC address since it 210 changes often. Instead, she tells the service an AoR to publish 211 presence to. The mobile service publishes presence state to that 212 AoR, which resolves to a SIP proxy or redirect server. Normal SIP 213 proxy or redirect behavior is invoked to get the publication to 214 Alice's PC based on her publish contact registration. 216 1.2.3 Conclusions 218 It is our opinion that SIP style routing is very useful for presence 219 publication. Without the application level routing capabilities of 220 SIP, it would be difficult to build these sort of services. It is 221 more appropriate to add a publication mechanism to SIP than to 222 standardize SIP-style routing features for HTTP proxies. 224 2. Terminology 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in RFC 2119 [3]. 230 3. Publication Requirements 232 Any presence publication mechanism for SIP must meet the following 233 requirements. 235 1. The presence publication mechanism must provide a way for a PUA 236 to publish presence to a presence compositor. 238 2. The presence publication mechanism must define a new SIP method 239 for presence publication, or describe how some existing method 240 can perform this function. 242 3. The presence publication mechanism must define a mandatory-to- 243 implement format for expressing presence information. This 244 format must have a registered MIME type. It is recommended that 245 this format be the Presence Information Data Format [4]. Other 246 formats in addition to the single mandatory-to-implement format 247 may be suggested. 249 4. The publication mechanism must support the simultaneous 250 publication from several distinct PUAs of presence information 251 concerning the same presentity. 253 5. The publication mechanism must allow for the fact that any 254 individual PUA may not know the total presence state of the 255 user. Publications from any given PUA may contain only part of 256 the total presence of the presentity. 258 6. It must be possible to order a published sequence of presence 259 information originating from a particular PUA. 261 7. It must be possible for a compositor to reject a publication 262 request. 264 8. The publication mechanism must support a means for a presence 265 compositor to compose presence information received from 266 multiple PUAs at different times into a single presence 267 document. The compositor function must be able to detect and 268 reconcile conflicts or overlaps in publications from different 269 PUAs. 271 9. The publication mechanism must support a means for large content 272 to be sent as a part of presence information. 274 10. It must be possible for a PUA to send full presence information 275 (all of the presence information that the PUA knows about a 276 presentity) in a publication, and there should also be a way for 277 PUAs to send partial or incremental presence information. 279 11. The publication mechanism must support a way to uniquely 280 identify segments of presence information (for example, the 281 tuple elements in PIDF are uniquely identified by a tuple ID). 283 12. There must be a way to uniquely identify segments of presence 284 information for a particular presentity that is independent of 285 the PUA that generated this segment. The tuple identifier from 286 PIDF is an example of such a unique identifier. 288 13. The publication mechanism must allow two PUAs to publish 289 information for the same segment of presence information. 291 14. PUAs must have a capability that allows them to query for the 292 identifiers of all of the segments of presence information that 293 have currently been published for a presentity (provided that 294 the PUA is authorized to receive this information). 296 15. It must be possible for the publication of presence information 297 for a particular segment to overwrite existing information for 298 that segment, even if the existing information had been 299 published by a different PUA. Overwrites could occur, for 300 example, on the basis of a timestamp indicating when the segment 301 was last modified (i.e. more recent segments overwrite older 302 segments). 304 16. There must be a way for a compositor to reject a published 305 segment of presence information from a PUA because the segment 306 has been replaced by one published by another PUA. 308 17. It must be possible for a compositor to authenticate a publisher 309 of presence information. 311 18. The presence publication architecture must support a means for 312 principals to authorize the disclosure of segments of presence 313 information to particular watchers. 315 19. There must be a way for a publisher to tell a presence agent 316 that a piece of published presence should be passed on to 317 watchers without modification. 319 4. IANA Considerations 321 This document introduces no considerations for IANA. 323 5. Security Considerations 325 A presence compositor should authenticate publishing User Agents, and 326 may apply authorization policies. The composition model makes no 327 assumptions that all input sources for a compositor are on the same 328 network, or in the same administrative domain. 330 Authorization of watchers becomes more complicated in a presence 331 publication architecture. Principals should have some way to manage 332 the authorization of watchers who wish to published presence 333 information. Since they may not directly control the presence agent 334 to which watchers subscribe, this introduces some mechanism 335 requirements. 337 The compositor should throttle incoming publications and the 338 corresponding notifications resulting from the changes in event 339 state. As a first step careful selection of default Expires: values 340 for the supported event packages at a compositor can help limit 341 refreshes of event state. Additional throttling and debounce logic 342 at the compositor is advisable to further reduce the notification 343 traffic produced as a result of a PUBLISH method. 345 6. Acknowledgments 347 The authors would like to thank Krisztian Kiss and Aki Niemi for 348 their suggestions. 350 Normative References 352 [1] Rosenberg, J., Schulzrinne, Camarillo, Johnston, Peterson, 353 Sparks, Handley and Schooler, "SIP: Session Initiation 354 Protocol", RFC 3261, June 2002. 356 [2] Roach, A., "Session Initiation Protocol(SIP)-Specific Event 357 Notification", RFC 3265, June 2002. 359 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 360 Levels", RFC 2119, March 1997. 362 [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 363 J. Peterson, "Common Presence and Instant Messaging (CPIM) 364 Presence Information Data Format", draft-ietf-impp-cpim-pidf-07 365 (work in progress), May 2002. 367 [5] 369 Authors' Addresses 371 Ben Campbell 372 dynamicsoft 373 5100 Tennyson Parkway 374 Suite 1200 375 Plano, TX 75025 376 US 378 EMail: bcampbell@dynamicsoft.com 380 Sean Olson 381 Microsoft 382 One Microsoft Way 383 Redmond, WA 98052 384 US 386 Phone: +1-425-707-2846 387 EMail: seanol@microsoft.com 388 URI: http://www.microsoft.com/rtc 390 Jon Peterson 391 NeuStar, Inc. 392 1800 Sutter St 393 Suite 570 394 Concord, CA 94520 395 US 397 Phone: +1-925-363-8720 398 EMail: jon.peterson@neustar.biz 399 URI: http://www.neustar.biz 401 Jonathan Rosenberg 402 dynamicsoft 403 72 Eagle Rock Avenue 404 First Floor 405 East Hanover, NJ 07936 406 US 408 EMail: jdrosen@dynamicsoft.com 409 Brian Stucker 410 Nortel Networks, Inc. 411 2380 Performance Drive 412 Richardson, TX 75082 413 US 415 EMail: bstucker@nortelnetworks.com 417 Full Copyright Statement 419 Copyright (C) The Internet Society (2003). All Rights Reserved. 421 This document and translations of it may be copied and furnished to 422 others, and derivative works that comment on or otherwise explain it 423 or assist in its implementation may be prepared, copied, published 424 and distributed, in whole or in part, without restriction of any 425 kind, provided that the above copyright notice and this paragraph are 426 included on all such copies and derivative works. However, this 427 document itself may not be modified in any way, such as by removing 428 the copyright notice or references to the Internet Society or other 429 Internet organizations, except as needed for the purpose of 430 developing Internet standards in which case the procedures for 431 copyrights defined in the Internet Standards process must be 432 followed, or as required to translate it into languages other than 433 English. 435 The limited permissions granted above are perpetual and will not be 436 revoked by the Internet Society or its successors or assigns. 438 This document and the information contained herein is provided on an 439 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 440 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 441 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 442 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 443 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 445 Acknowledgement 447 Funding for the RFC Editor function is currently provided by the 448 Internet Society.