idnits 2.17.1 draft-rosenberg-impp-differences-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 74 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 18, 2000) is 8651 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) -- Missing reference section? '1' on line 449 looks like a reference -- Missing reference section? '2' on line 453 looks like a reference -- Missing reference section? '3' on line 458 looks like a reference -- Missing reference section? '4' on line 462 looks like a reference -- Missing reference section? '5' on line 466 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IMPP WG 3 Internet Draft Dave Crocker 4 Brandenburg Consulting 5 Athanassios Diacakis 6 Network Projects Inc. 7 Christian Huitema 8 Microsoft Corporation 9 Graham Klyne 10 Content Technologies Limited 11 Florencio Mazzoldi 12 Network Projects Inc. 13 Marshall T. Rose 14 Invisible Worlds, Inc. 15 Jonathan Rosenberg 16 dynamicsoft 17 Robert Sparks 18 dynamicsoft 19 Hiroyasu Sugano 20 Fujitsu Laboratories Ltd. 21 draft-rosenberg-impp-differences-00.txt 22 August 18, 2000 23 Expires: February 2001 25 A Framework for Moving IMPP Forward 27 STATUS OF THIS MEMO 29 This document is an Internet-Draft and is in full conformance with 30 all provisions of Section 10 of RFC2026. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet- Drafts as reference 40 material or to cite them other than as work in progress. 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Abstract 50 This document presents the summary of the findings of the IMPP group 51 of nine that were selected to study the common components and 52 fundamental differences among the three proposals. 54 1 Introduction 56 At the conclusion of the IMPP working group meeting in Pittsburgh in 57 August of 2000, it was agreed that a team of nine individuals, three 58 from each of the three protocol camps, would spend two weeks coming 59 up with a set of commonalities and differences amongst the various 60 protocol proposals. This document represents the output of that work. 61 It presents a high level overview of what we agreed was common, and 62 then describes the different approaches taken by the three proposals 63 and how they fundamentally differ. A companion document describes the 64 details of the common components. 66 2 Commonalities 68 There was agreement that it must be possible to build gateways 69 between IMPP protocol islands such that the services required by RFC 70 2779 [1] can, at a mimimum, be interworked between islands. To 71 accomplish this, an abstract protocol, conformant to rfc2779, was 72 defined. It was agreed that all IMPP protocols would need to define a 73 mapping to this abstract protocol, as proof that interworking between 74 islands would be possible. This abstract protocol is described in 75 [2]. 77 The abstract protocol provides subscription, notification, and 78 instant messaging capabilities. It defines protocol parameters that 79 are needed, at a minimum, for successful interworking. 81 There was also agreement on a common addressing format. An IM URL and 82 presence URL formats were defined. It was agreed that all IMPP 83 protocols would be required to carry these URL formats as the 84 identifications for the various entities in the system (presentities, 85 watcher addresses, etc.). It was also agreed that each protocol could 86 define its own native URL formats (i.e., the SIP proposal would also 87 use sip URLs). When communicating with a foreign domain, the foreign 88 domain would be required to list an SRV or A record for its domain 89 listing a gateway server. This gateway would be required to 90 understand protocol messages from all other islands, convert them to 91 its own protocol, and additionally know how to convert the global URL 92 to a native URL format. Details were defined and are described in 93 [2]. 95 There was agreement that all IMPP protocols would be required to use 96 MIME for transport of instant messages and presence data. 97 Furthermore, it was agreed that a common format for presence data 98 would be defined. This format, based on XML, represents the minimal 99 presence format compliant to RFC 2779, and is based on the data model 100 described in RFC 2778 [3]. This allows gateways to simply copy the 101 content from one protocol to another with zero loss of information. 102 The presence format is defined in [2]. 104 There was agreement that end to end authentication and encryption 105 would be supported through gateways using MIME security techniques, 106 including PGP-MIME [4] and S/MIME [5]. 108 3 Differences 110 Despite these common components, it was clear that the three groups 111 represent fundamentally different approaches to solving the problems 112 of IMPP, and that these approaches are not easily reconciled. The 113 subsections which follow describe the differing approaches in more 114 detail. 116 Each section is written by a representative from the respective view. 117 This draft is not an endorsement from the nine for any one, or all, 118 approaches. 120 3.1 The Session Initiation Protocol 122 The primary advantage that we see with the SIP proposal is the way in 123 which it can integrate voice, video, and other interactive 124 communications services with instant messaging and presence. There 125 are three aspects of this integration - integration of 126 infrastructure, integration of services, and integration of software. 127 The result are benefits to service providers, users, and 128 implementors, respectively. 130 Integration of infrastructure is about reuse. We believe service 131 providers will want to have a single network used to provide the 132 communications services of its customers - voice, video, IM or 133 presence. By basing the IMPP standard on SIP, this becomes 134 achievable. The same proxy servers used in SIP to route calls can 135 route IMs, and they can route presence data. The same data 136 repositories used for storing users' location for calls, can also be 137 used for storing users' locations for IMs, and also their location 138 for presence services. It is not mearly a reuse of the databases, but 139 the data itself. The same SIP phones used to receive calls can 140 instantly become publishers of presence information. 142 This kind of integration of infrastructure results in significant 143 benefits for the service provider. The management and operational 144 costs of running a communications service are vastly reduced, since 145 the addition of presence and IM to an existing SIP network is nowhere 146 close to the costs of building and running a completely separate, 147 parallel network. The equipment costs themselves are reduced, since 148 only one set of proxy and location servers are needed, rather than 149 two. System capacity is improved, since resources can be shared 150 across many services. Infrastructure investments in firewalls, 151 mobility services, etc. that have been put in place for supporting 152 SIP can also be reused. Service providers have also invested a 153 serious amount of intellectual capital in SIP; reusing SIP means 154 these providers have a much shorter learning curve. 156 From the users perspective, the primary benefit is integration of 157 services. Voice, video, IM and presence are all simply different 158 aspects of the general problem of interpersonal interactive 159 communications. Many features and services used in one domain make a 160 lot of sense in the other. Take, for example, call screening, which 161 can prevent incoming calls from specific users. A very desirable 162 service would be to extend this to IM - that person can neither call, 163 send an IM, or subscribe to the user of this feature. Development, 164 provisioning, and deployment of these kinds of integrated features is 165 vastly simplified by a single network that provides them. If IM and 166 presence and voice where each separate protocol clouds, it would 167 require separate code, running on separate networks, maintained 168 separately, and kept synchronized. However, if these services all ran 169 on the same network, providing such integrated services would be 170 simple, if not for free (the above service is for free in a SIP 171 proxy, as these provide such services on a method independent basis). 173 As another example, the IP Telephony working group in IETF (iptel) 174 has nearly completed specification of the Call Processing Language 175 (cpl), and XML based scripting language that allows users to define 176 their own services for SIP. CPL enables screening, forwarding, 177 filtering, and notification types of services. For example, a CPL can 178 be written which specifies that calls from Joe are forwarded to a 179 unified messaging server after 5pm, all other calls are routing to a 180 mobile PDA. The specification of the service is method independent; 181 this means this CPL and all the related CPL infrastructure in the 182 network would allow this service to be extended to instant messaging 183 with no additional work. This would allow users to customize their 184 own IM, presence and multimedia services with the same tools. 186 By using a different protocol, or even by modifying SIP in some way 187 for this application, the above benefits are lost. Service providers 188 will not be able to run IM and presence on their deployed SIP 189 networks. Therefore, for service providers deploying SIP networks, 190 there is but a single realistic choice. Choosing a different 191 protocol, or even a modified SIP, results in such substantially 192 higher costs that it acts as a barrier to entering the market. 194 From the implementors perspective, the primary issue is cost and time 195 to market. By using SIP, implementors can readily obtain one of the 196 many existing software development kits and libraries, and build upon 197 that. Both open source and commercial code is available. For 198 implementors who already have their own SIP code, building ontop of 199 that instead of building from scratch is a clear win. There are 200 nearly one hundred seperate implementations of SIP; many from groups 201 which wish to build IM and presence solutions as well as multimedia 202 communications solutions. There are also numerous testing and load 203 generation tools available for SIP; these too can be reused for 204 building IM and presence systems. 206 For this reason, we believe that choosing a single, non-SIP based 207 solution for presence and IM is a non-starter. There is a significant 208 community of interest, among both service providers and software 209 manufacturers, for a SIP based solution. 211 3.2 The IMXP 213 The basic philosophy of IMXP is: 215 o The core mechanism is kept to a minimum: Anything that can be 216 built using the core mechanism is excluded from the core. 218 o Design is based on familiar Internet mail architecture: 219 Applies a wealth of related experience, making the 220 architecture choices extremely safe. 222 The IMXP relay mesh uses lightweight, near-real-time application 223 datagram transfer nodes, analogous to email MTAs: 225 o Relay processing is kept simple: Essential intelligence is 226 kept at or near the network edge to enhance scalability; 227 relays are not required to maintain state concerning message 228 transfer. 230 o Addressing and routing follow the classic email model: This 231 is safely scalable, providing hierarchical addresses (domain 232 names) that can be understood by the entire relay mesh. 234 o Hop-by-hop security framework: Authentication, privacy, and 235 authorization rely on domains "keeping their own houses in 236 order", in line with current Internet infrastructure. End to 237 end security (OpenPGP or S/MIME) may be added to provide 238 better security, but require (pending) PKI deployment. 240 o Transport independence: A convergence layer (BEEP) carries 241 IMXP identically over variety of transports. 243 o Other applications may use the same service: Asynchronous 244 near-real-time message exchange with accessible, predictable 245 behaviour for loosely-coupled applications. 247 In summary, we require than each part of solution must carry its full 248 weight in the overall scheme. It is not enough that the parts of the 249 solution are individually good: all core elements are needed to 250 fulfill essential IM functions, or to provide hooks for building such 251 functions. The design re-applies the lessons of Internet scaling to 252 application design, aiming for minimum processing performed in the 253 network, unimpeded end-to-end transfer of information, and services 254 added at the network edge. 256 3.3 PRIM: Presence and Instant Messaging 258 The authors of several IMPP proposals, namely PePP, PITP/IMTP, OneIM, 259 and SIMP, have agreed and actually started working to make a joint 260 proposal based on our existing drafts. Our protocols have extended 261 architectural similarities, and we believe that those are attributed 262 to the fact that our design is based on RFC2778-2779 and consensus 263 formed in the IMPP community so far. In summary, our aim is to 264 develop a minimal specification, which satisfies the IMPP 265 requirements. 267 3.3.1 PRIM Design 269 Transfer protocol directly atop of TCP: We assume TCP as basic 270 transport mechanism for instant messages and presence 271 information. TCP provides sufficiently reliable transport 272 infrastructure and we think instant messaging (IM) and 273 presence services require this level of reliability. In 274 addition, we design both IM and presence protocols directly 275 atop of TCP. Although these are tightly related services, 276 their characteristics are different in several points. This 277 decision makes the protocols quite simple and lightweight. 279 Long-lived Client/Server connections: Our protocols use long- 280 lived client/server connections in order for clients to 281 receive instant messages and presence notifications. This 282 brings the following advantages. As we adopt TCP as IM and 283 presence transport, use of existing connections reduce much 284 overhead of re-establishing connections and per-connection 285 authentication. This feature is fairly important in the 286 case of some uses where presence notifications are 287 frequent. Once the connection peer (the home domain server) 288 is authenticated, additional authentication for IMs and 289 notification messages may be omitted in the case the home 290 domain servers and the inter-domain relation is considered 291 fully trustworthy. When clients are behind firewalls and 292 connect to the servers outside, using long-lived TCP 293 connections to receive messages from the servers is a 294 practical solution. This situation is quite common at 295 present to utilize the existing IM service providers. 297 Selective Presence Publication: RFC2779 stipulates various 298 requirements for access control; 2.3.x and some of section 299 5. Among them, we consider the feature of "Polite Blocking" 300 (5.1.15, 5.2.3) very important for presence services. Our 301 proposal contains the mechanism of such selective presence 302 publication and the in-band access control mechanism. 304 3.3.2 Our Perspective 306 We believe that the authors of the various proposals (as grouped by 307 the WG chairs) have different expectations from an IMP protocol. We 308 expect a Presence and IM protocol to have the following 309 characteristics (in no particular order): 311 o It does not carry unnecessary features. The WG was given the 312 task to produce a protocol with a certain feature-set 313 (RFC2779). Extra features can be nice, but should not exist in 314 this protocol, or should be built elsewhere. 316 o It maps well on existing Presence and IM offerings. The 317 migration to the standard should be as painless and seamless 318 as possible. This would remove barriers to adoption. 320 o Existing Presence and IM offerings use architectures that map 321 well on Group 2 proposals. As a result there is a lot of 322 experience on how those architectures perform in solving the 323 Presence and IM requirements. 325 o It is simple and easily understood by developers who will need 326 to implement it. There are a lot of people on the WG that 327 perceive non-Group 2 proposals to be unnecessarily 328 complicated. 330 o It is independent from the work currently being done in other 331 WGs. There is a sense of urgency in producing an IMP protocol, 332 and introducing unnecessary links (that might turn into 333 critical dependencies) to other WG does not help. Work 334 currently being done in other WGs should be used, if 335 applicable, when it is complete. 337 o It does not rely on non-existing technology and 338 implementations. Again, there is a sense of urgency and the 339 IMP protocol should not require an implementation of server X 340 (which currently does not exist) unless that is absolutely 341 necessary. 343 4 Conclusion 345 In conclusion, the group of nine have agreed on a common set of 346 components for IM and presence that will allow interworking with 347 delivery of services compliant to rfc 2779. This is accomplished 348 through the definition of an abstract protocol, a common addressing 349 format, a common presence data format, a common content format, a and 350 a common end to end security format. We have also outlined the 351 differences between the protocols, focusing on what is fundamentally 352 different and not easily reconcilable. 354 Our hope is that this work will serve as a solid foundation for 355 moving IMPP forward. 357 5 Author's Addresses 359 David H. Crocker 360 Brandenburg Consulting 361 675 Spruce Drive 362 Sunnyvale, CA 94086 363 US 364 Phone: 365 +1 408 246 8253 366 EMail: 367 DCROCKER@BRANDENBURG.COM 368 URI: 369 HTTP://WWW.BRANDENBURG.COM/ 371 Athanassios Diacakis 372 Network Projects Inc. 373 4516 Henry Street 374 Suite 113 375 Pittsburgh, PA 15213 376 US 377 Phone: 378 +1 412 681 6950 379 EMail: 380 THANOS@NETWORKPROJECTS.COM 382 Christian Huitema 383 Microsoft Corporation 384 One Microsoft Way 385 Redmond, WA 98052-6399 386 US 387 EMail: 388 HUITEMA@MICROSOFT.COM 390 Graham Klyne 391 Content Technologies Limited 392 1220 Parkview 393 Arlington Business Park 394 Theale, Reading RG7 4SA 395 UK 396 Phone: 397 +44 118 930 1300 398 EMail: 399 GK@ACM.ORG 401 Florencio Mazzoldi 402 Network Projects Inc. 403 4516 Henry Street 404 Suite 113 405 Pittsburgh, PA 15213 406 US 407 Phone: 408 +1 412 681 6950 409 EMail: 410 FLO@NETWORKPROJECTS.COM 412 Marshall T. Rose 413 Invisible Worlds, Inc. 414 1179 North McDowell Boulevard 415 Petaluma, CA 94954-6559 416 US 417 Phone: 418 +1 707 789 3700 419 EMail: 420 MROSE@INVISIBLE.NET 421 URI: 422 HTTP://INVISIBLE.NET/ 424 Jonathan Rosenberg 425 dynamicsoft 426 72 Eagle Rock Avenue 427 First Floor 428 East Hanover, NJ 07936 429 email: jdrosen@dynamicsoft.com 431 Robert Sparks 432 dynamicsoft 433 72 Eagle Rock Avenue 434 First Floor 435 East Hanover, NJ 07936 436 email: rsparks@dynamicsoft.com 438 Hiroyasu Sugano 439 Fujitsu Laboratories Ltd. 440 64 Nishiwaki, Ohkubo-cho 441 Akashi 674-8555 442 JP 443 EMail: 445 SUGA@FLAB.FUJITSU.CO.JP 447 6 Bibliography 449 [1] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging 450 / presence protocol requirements," Request for Comments 2779, 451 Internet Engineering Task Force, Feb. 2000. 453 [2] D. Crocker, M. Rose, G. Klyne, J. Rosenberg, R. Sparks, C. 454 Huitema, F. Mazzoldi, H. Sugano, and A. Diacakis, "A common profile 455 for instant messaging," Internet Draft, Internet Engineering Task 456 Force, Aug. 2000. Work in progress. 458 [3] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and 459 instant messaging," Request for Comments 2778, Internet Engineering 460 Task Force, Feb. 2000. 462 [4] M. Elkins, D. D. Torto, R. Levien, and T. Roessler, "MIME 463 security with OpenPGP," Internet Draft, Internet Engineering Task 464 Force, Apr. 2000. Work in progress. 466 [5] B. Ramsdell and Ed, "S/MIME version 3 message specification," 467 Request for Comments 2633, Internet Engineering Task Force, June 468 1999.