idnits 2.17.1 draft-newman-acap-imsp-lessons-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an Abstract section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 11. Security Considerations' ) ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (December 1996) is 9966 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IMSP' ** Obsolete normative reference: RFC 2060 (ref. 'IMAP') (Obsoleted by RFC 3501) -- Possible downref: Non-RFC (?) normative reference: ref. 'ACAP' Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: Lessons Learned from IMSP Innosoft 4 Document: draft-newman-acap-imsp-lessons-01.txt December 1996 6 Lessons Learned from IMSP 8 Status of this memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 andrewDrafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress``. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the 27 RFC editor as a Proposed Standard for the Internet Community. 28 Discussion and suggestions for improvement are requested. This 29 document will expire six months after publication. Distribution of 30 this draft is unlimited. 32 1. Introduction 34 IMSP (Internet Message Support Protocol) [IMSP] was designed and 35 implemented to supply the support functions necessary for a large 36 scale IMAP4 based infrastructure with highly mobile users. 37 Although the protocol was successful in its mission, it was 38 realized that a slightly different approach could achieve more for 39 the Internet Standards community. Thus was born the idea for ACAP 40 (Application Configuration Access Protocol) [ACAP]. 42 This document will discuss the successes and failures of the IMSP 43 protocol and how the IMSP experiment is influencing the design of 44 ACAP. 46 2. The origin of IMSP 48 CMU (Carnegie Mellon University) has been running an experimental 49 messaging system called AMS (Andrew Message System) for many years. 50 AMS has been extremely successful and has lead to a situation where 51 mail, shared bboards, and newsgroups are used daily by people from 52 all over the University, including non-technical departments. 53 Unfortunately, AMS has two fatal flaws. It is dependant on AFS 54 (Andrew File System) which inhibits scaling and cross-platform use, 55 and is not standards based so that all clients have to be developed 56 in-house. 58 In 1992, CMU begin working through the Internet standards process 59 to bring the functionality of AMS to the standards community. CMU 60 strongly supported IMAP4 [IMAP] as the core functionality, and 61 created IMSP to supply the support functions which are needed in a 62 message system but are not part of basic message access. 64 There are three major components of IMSP: 66 1) Storage for client configuration information. 68 2) Storage for user address books. 70 3) Mailbox distribution/replication support. 72 The first two components are successfully used today at a number of 73 large sites. Experiments with the third component are ongoing. 75 3. Mobile Users 77 Universities, Hospitals and other large sites need a message system 78 where any PC or workstation can be used to access messages 79 transparently. As tele-commuting and laptops become more popular, 80 more individuals are faced with the problem of accessing their 81 messages from more than one computer and often more than one 82 platform. While IMAP4 [IMAP] allows users to access their message 83 stores, it does not provide storage for address books and 84 configuration information needed by these mobile users. IMSP fills 85 this niche. 87 This need is so great that a significant number of sites have 88 deployed IMAP4 and IMSP despite the immaturity of IMAP clients in 89 1995 and the experimental nature of IMSP. The IMAP4/IMSP 90 combination allows users to move from machine to machine and get 91 the same configuration and interface. 93 4. Client Configuration 95 The CMU IMSP server implementation provides server storage of 96 client configuration and also provides administrative defaults or 97 mandatory settings for client configuration. Our experiments show 98 this is a great success. 100 For example, many sites wish to control what appears in the "From:" 101 header of outgoing mail, while other sites let the user do as they 102 choose. The CMU IMSP server allows sites to configure either a 103 default "From:" address, or a mandatory "From:" address based on 104 the IMSP login name. This prevents users from accidentally sending 105 mail with the wrong "From:" address. Administrators of large sites 106 are quite fond of this feature. 108 The Simeon client from ESYS corporation stores a great deal of 109 private configuration information on the IMSP server, in addition 110 to common configuration options. The decision to create an IMSP 111 options registry for common options as well as reserving parts of 112 the name space with vendor specific prefixes appears to be sound. 114 Options appear to work well as they are implemented in IMSP, and 115 are certainly not limited to messaging. ACAP should include an 116 option registry with vendor specific prefixes, as well as 117 administrative defaults and mandatory settings. 119 5. Address Books and Access Control 121 Almost every messaging system provides an interface for personal 122 address books which is distinct from a public directory service. 123 CMU's IMSP server provides an interface to multiple personal 124 address books. It also provides rich access control on address 125 books so they can be shared with other users. As soon as a client 126 interface was created for these functions they both became very 127 popular. They were so popular, in fact, that users started asking 128 for the ability to "subscribe" to address books so they didn't have 129 to wade though a large list. 131 The basic structure for IMSP address books was that each address 132 book was made up of a list of entries, and each entry was made up 133 of a set of (attribute, value) pairs. A set of basic attributes 134 was defined, and others were permitted. This structure 135 successfully provided the necessary flexibility. 137 Despite these successes, there are a number of problems with IMSP 138 address books. Access becomes slow when they get large, and 139 searching requires two round trips to the server. The original 140 server implementation didn't allow spaces in address book entry 141 names, but users soon demanded this flexibility. There were also 142 requests for access control groups to improve sharing of address 143 books. 145 Finally, it became clear that there are two different models for 146 address books in common use. The Unix/text-based model has a short 147 alias for each entry which expands to the email address. The 148 PC/GUI model uses common names which can be chosen from a list to 149 use as the email address. IMSP used the common name as the primary 150 key for address books, which makes implementation of the 151 Unix/text-based model inefficient due to the two-round trips needed 152 for searching. 154 The ACAP protocol should include address books with rich access 155 control and a "subscription" capability. It needs to address the 156 problems we've identified in IMSP. 158 6. Generalization of the Application Configuration problem 160 While IMSP was designed specifically for messaging applications, 161 the options and address book functions could be quite useful in 162 other applications. In addition, the mobility problem is not 163 limited to messaging. Web browser bookmarks are a prime example of 164 application configuration information which should be mobile. 166 Another observation was that the mailbox list features of IMSP 167 didn't seem to fit with the address book and configuration 168 portions, and each had different target markets. This recognition 169 was the primary motivation to invent ACAP. ACAP specifies a basic 170 model which can then be applied to support different applications. 172 7. Large Lists 174 The IMSP protocol model for address book entries and mailbox lists 175 is a serious problem for large lists. It requires fetching the 176 entire list, even when a client only has display space for the 177 first 50. This can be very slow on low memory machines and over 178 slow network connections. 180 ACAP should provide a way for clients to implement "virtual scroll 181 bars" where they only have to fetch what needs to be displayed to 182 the user. This means that ACAP needs rich server side searching 183 and sorting with the ability to fetch deterministic parts of the 184 resulting ordered list. 186 8. The ACAP "dataset" model 188 The CMU IMSP implementation ended up using the same database 189 backend for all the lists (options, address book entries, address 190 books, mailboxes). The server translated the function based 191 commands for each of these lists into a common set of backend 192 database operations. 194 ACAP can be a smaller and simpler protocol than IMSP if it provides 195 data based commands rather than function based commands. The idea 196 is to take the IMSP address book model and turn it in to a generic 197 container which can hold options, mailboxes, access control groups 198 or even web browser bookmarks. 200 Therefore the ACAP "dataset" model has the same structure as an 201 IMSP address book: a dataset is a set of entries and each entry is 202 a set of (attribute, value) pairs. 204 9. Conclusion 206 IMSP was a successful experiment which demonstrates the need for a 207 configuration server. ACAP is the logical refinement of the ideas 208 behind IMSP and is likely to become an important part of the 209 Internet protocol suite. 211 10. References 213 [IMSP] Myers, J., "Internet Message Support Protocol", 214 Experiment in progress, 215 http://andrew2.andrew.cmu.edu/cyrus/rfc/imsp.html, 216 June 1995 218 [IMAP] Crispin, M., "Internet Message Access Protocol - 219 Version 4rev1", RFC 2060, University of 220 Washington, December 1996. 222 [ACAP] Myers, J., "Application Configuration Access 223 Protocol", Work in progress, November 1996. 225 11. Security Considerations 227 There are no known security issues in this memo. 229 12. Acknowledgments 231 Many thanks to Steve Hole and the ESYS corporation for their 232 early client support of IMSP which was invaluable to this 233 effort. Thanks also to Terry Gray for his insistence that 234 IMSP was too application specific and that something more 235 general was needed. And thanks to John Myers for his 236 authorship of the IMSP specification and observation that 237 everything could fit into the address book model. 239 13. Author's Address 241 Chris Newman 242 Innosoft International, Inc. 243 1050 E Garvey Ave S. 244 West Covina, CA 91790 246 Email: chris.newman@innosoft.com