idnits 2.17.1 draft-roach-simple-blconf-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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2003) is 7615 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 (-10) exists of draft-ietf-simple-presence-07 == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-04 == Outdated reference: A later version (-01) exists of draft-ietf-simple-publish-00 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-00 == Outdated reference: A later version (-04) exists of draft-ietf-sipping-mwi-02 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft dynamicsoft 4 Expires: December 19, 2003 June 20, 2003 6 SIMPLE Buddylist Configuration Problem Statement 7 draft-roach-simple-blconf-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on December 19, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document contains a brief discussion of a particular challenge 39 that exists in making users' buddy list information available when a 40 SIMPLE client first starts up. It also provides a very brief 41 analysis of various solutions to the problem. 43 1. Introduction 45 One of the formal deliverables of the SIMPLE working group is to 46 provide an architecture that allows multiple interoperable 47 implementations to provide a traditional buddylist-based instant 48 messaging presence application using SIP. An informal design goal of 49 the working group that stems from this deliverable is that such 50 solutions should enable at least the same set of features as the 51 currently available proprietary offerings. One of the keystones in 52 realizing this goal is allowing developers to provide a user 53 experience that is as good as or better than such offerings. 55 One stumbling block in allowing developers to create such a user 56 experience is the fact that there is currently no defined way, given 57 a user's address of record, to retrieve a list of contacts for the 58 purposes of displaying presence data and conveniently sending 59 messages. Without such an ability, creating a user experience that 60 is as straightforward as those currently available is frustrated. 62 2. Problem Description 64 Imagine a typical internet user, known for the purposes of this 65 description as Bob, who wants to walk into a random Internet cafe and 66 log into an IM client so that he can see who of his friends are 67 online, and begin to send and receive messages. With currently 68 deployed proprietary systems, Bob would be able to fire up the 69 client, type in his user name and his password, and be finished. 70 With no further interaction, Bob's presence information is changed, 71 servers know how to route incoming messages to Bob, Bob's buddylist 72 is displayed to him, and client starts receiving updates which 73 indicate which of his buddies are online. The underlying proprietary 74 protocol knows, given a user name of, e.g., "bob1963", how to perform 75 all of these actions. 77 SIMPLE currently has a hole in this area. Client creators can 78 acheive almost all of the effects described above using mechanisms 79 already defined or under development within the IETF. Assuming that 80 Bob remembers his user ID (sip:bob@example.com, which is nicely 81 mnemonic and probably matches one of his e-mail addresses) and 82 password (used for responses to digest challenges), the client can 83 send a REGISTER [1] to sip:example.com (to route messages to him), 84 send a PUBLISH [5] to sip:bob@example.com (to update his presence), 85 and send an event-list [4] aware presence [3] SUBSCRIBE [2] to get 86 his buddy list and the status of each buddy. The complication arises 87 from the fact that the client doesn't have a URI to which this 88 SUBSCRIBE can be sent. So, without prompting Bob for an additional 89 URI -- that of his buddy list -- the client is unable to provide the 90 service. 92 A failure on part the of the IETF to define an adequate mechanism to 93 address this problem has a very high probability of causing 94 individual implementors to develop their own solution on an 95 implementation-by-implementation basis. Even if a sufficently large 96 critical mass of implementations begin using the same convention, 97 there will almost certainly be a substantial period of time before a 98 widespread pattern is established. Until such a de-facto standard is 99 established, interoperability between independant implementations 100 will suffer. Further, even if the convention for such a mechanism is 101 eventually established, older, non-interoperable conventions will 102 continue to exist side-by-side with it indefinitely for reasons of 103 backwards compatibility. 105 3. Possible Solutions 107 3.1 Status Quo 109 Currently, the accepted solution to this problem is that such 110 information is manally entered into the client by the user. While 111 this invokes only a mild startup cost whenever Bob goes to set up his 112 home PC (not entirely unlike configuring the POP and SMTP servers for 113 an e-mail client), it adds an extra step to Bob's login process when 114 he's in an internet cafe, at a friends house, or at any other device 115 that he doesn't use on a regular basis. 117 Chances are very good that Bob isn't going to want to remember the 118 additional URI for his buddy list -- or, even if he can, probably 119 doesn't want to go through the trouble of typing it in (in addition 120 to his user ID) every time he logs in from a different location. 121 Requiring him to do so provides an experience that is clearly 122 inferior to those available from proprietary solutions today. 124 In short, while the approach of requiring the user to enter an 125 additional URI to access his buddy list is a solution to the problem 126 of where the information comes from, it does not do so in a way that 127 is, from a user perspective, as good as currently available products. 128 Because of this added inconvenience, implementors will likely attempt 129 to solve the problem in a variety of non-interoperable ways, as 130 discussed above. 132 3.2 Implicit URL Binding 134 One approach to solving this problem is to establish a convention 135 that indicates how to manipulate the URI in such a way that it 136 indicates the resource to which the SUBSCRIBE should be sent; for 137 example, appending "-buddies" to the user portion ("sip:bob- 138 buddies@example.com") would be one such transformation, as would 139 using the hostname portion (e.g. "sip:bob@buddies.example.com"). 141 While acceptable from a technical perspective, this approach runs 142 afoul of several philosophical objections and has some suboptimal 143 characteristics. The prime philosophical objection is the supposed 144 property that URIs are (with certain well-defined exceptions) treated 145 as opaque by clients who use them. Establishing a convention that 146 describes specific transformations of the URI violates this property. 147 Suboptimal characteristics of any implicit approach include relics 148 such as requiring the user's registrar to handle buddy list services 149 and limiting users to having a single, centrally managed buddy list. 151 3.3 User Configuration Retrieval 153 Another approach to solving the problem under discussion is to allow 154 the URI for the buddy list itself to be retrieved from the user's 155 home domain server (e.g. example.com). Doing so provides an 156 explicit way of indicating from where to retrieve the list. This 157 approach is, in spirit, similar to that defined for device 158 configuration [6]; specifically, a subscription would be sent to the 159 user's address-of-record for an event package that contains user 160 configuration data. One component of the user's configuration 161 information would be a URI (or possibly even URIs) that indicate from 162 where the user's buddy list could be retrieved. 164 In addition to providing a clear mechanism for unambiguously 165 identifying a user's buddy list, this mechanism has the additional 166 properties that it allows buddy lists to be hosted by a domain other 167 than that of the user's registrar, and that it allows users to have 168 multiple buddy lists configured. Finally, this approach can be 169 specified in such a way that it allows inclusion of additional user- 170 profile information if needed, such as a URI for message waiting 171 indication [7]. 173 4. Acknowledgements 175 Thanks to Paul Tidwell for first raising the issue discussed in this 176 document. Steve Donovan, Robert Sparks, and Dean Willis contributed 177 to early conversations on the topic. 179 References 181 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 182 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 183 Session Initiation Protocol", RFC 3261, June 2002. 185 [2] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event 186 Notification", RFC 3265, June 2002. 188 [3] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions for 189 Presence", draft-ietf-simple-presence-07 (work in progress), May 190 2002. 192 [4] Roach, A.B., Rosenberg, J. and B. Campbell, "A Session Initiation 193 Protocol (SIP) Event Notification Extension for Resource Lists", 194 draft-ietf-simple-event-list-04 (work in progress), June 2003. 196 [5] Campbell, B., Olson, S., Peterson, J., Rosenberg, J. and B. 197 Stucker, "SIMPLE Presence Publication Mechanism", draft-ietf- 198 simple-publish-00 (work in progress), February 2003. 200 [6] Petrie, D., "A Framework for SIP User Agent Configuration", 201 draft-ietf-sipping-config-framework-00 (work in progress), Feb 202 2003. 204 [7] Mahy, R., "A Message Summary and Message Waiting Indication 205 Event Package for the Session Initiation Protocol (SIP)", draft- 206 ietf-sipping-mwi-02 (work in progress), March 2003. 208 Author's Address 210 Adam Roach 211 dynamicsoft 212 5100 Tennyson Pkwy 213 Suite 1200 214 Plano, TX 75024 215 US 217 EMail: adam@dynamicsoft.com 219 Full Copyright Statement 221 Copyright (C) The Internet Society (2003). All Rights Reserved. 223 This document and translations of it may be copied and furnished to 224 others, and derivative works that comment on or otherwise explain it 225 or assist in its implementation may be prepared, copied, published 226 and distributed, in whole or in part, without restriction of any 227 kind, provided that the above copyright notice and this paragraph are 228 included on all such copies and derivative works. However, this 229 document itself may not be modified in any way, such as by removing 230 the copyright notice or references to the Internet Society or other 231 Internet organizations, except as needed for the purpose of 232 developing Internet standards in which case the procedures for 233 copyrights defined in the Internet Standards process must be 234 followed, or as required to translate it into languages other than 235 English. 237 The limited permissions granted above are perpetual and will not be 238 revoked by the Internet Society or its successors or assigns. 240 This document and the information contained herein is provided on an 241 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 242 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 243 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 244 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 245 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 247 Acknowledgement 249 Funding for the RFC Editor function is currently provided by the 250 Internet Society.