idnits 2.17.1 draft-newman-acap-imsp-lessons-02.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-04-26) 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 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 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. 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 (July 1997) is 9782 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: 9 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-02.txt July 1997 5 Expires in six months 7 Lessons Learned from IMSP 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 Introduction 30 IMSP (Internet Message Support Protocol) [IMSP] was designed and 31 implemented to supply the support functions necessary for a large 32 scale IMAP4 based infrastructure with highly mobile users. 33 Although the protocol was successful in its mission, it was 34 realized that a slightly different approach could achieve more for 35 the Internet Standards community. Thus was born the idea for ACAP 36 (Application Configuration Access Protocol) [ACAP]. 38 This document will discuss the successes and failures of the IMSP 39 protocol and how the IMSP experiment is influencing the design of 40 ACAP. 42 1. The origin of IMSP 44 CMU (Carnegie Mellon University) has been running an experimental 45 messaging system called AMS (Andrew Message System) for many years. 47 AMS has been extremely successful and has lead to a situation where 48 mail, shared bboards, and newsgroups are used daily by people from 49 all over the University, including non-technical departments. 50 Unfortunately, AMS has two fatal flaws. It is dependant on AFS 51 (Andrew File System) which inhibits scaling and cross-platform use, 52 and is not standards based so that all clients have to be developed 53 in-house. 55 In 1992, CMU begin working through the Internet standards process 56 to bring the functionality of AMS to the standards community. CMU 57 strongly supported IMAP4 [IMAP] as the core functionality, and 58 created IMSP to supply the support functions which are needed in a 59 message system but are not part of basic message access. 61 There are three major components of IMSP: 63 1) Storage for client configuration information. 65 2) Storage for user address books. 67 3) Mailbox distribution/replication support. 69 The first two components are successfully used today at a number of 70 large sites. Experiments with the third component are ongoing. 72 2. Nomadic Users 74 Universities, Hospitals and other large sites need a message system 75 where any PC or workstation can be used to access messages 76 transparently. As tele-commuting and laptops become more popular, 77 more individuals are faced with the problem of accessing their 78 messages from more than one computer and often more than one 79 platform. While IMAP4 [IMAP] allows users to access their message 80 stores, it does not provide storage for address books and 81 configuration information needed by these mobile users. IMSP fills 82 this niche. 84 This need is so great that a significant number of sites have 85 deployed IMAP4 and IMSP despite the immaturity of IMAP clients in 86 1995 and the experimental nature of IMSP. The IMAP4/IMSP 87 combination allows users to move from machine to machine and get 88 the same configuration and interface. 90 3. Client Configuration 92 The CMU IMSP server implementation provides server storage of 93 client configuration and also provides administrative defaults or 94 mandatory settings for client configuration. Our experiments show 95 this is a great success. 97 For example, many sites wish to control what appears in the "From:" 98 header of outgoing mail, while other sites let the user do as they 99 choose. The CMU IMSP server allows sites to configure either a 100 default "From:" address, or a mandatory "From:" address based on 101 the IMSP login name. This prevents users from accidentally sending 102 mail with the wrong "From:" address. Administrators of large sites 103 are quite fond of this feature. 105 The Simeon client from ESYS corporation stores a great deal of 106 private configuration information on the IMSP server, in addition 107 to common configuration options. The decision to create an IMSP 108 options registry for common options as well as reserving parts of 109 the name space with vendor specific prefixes appears to be sound. 111 Options appear to work well as they are implemented in IMSP, and 112 are certainly not limited to messaging. ACAP should include an 113 option registry with vendor specific prefixes, as well as 114 administrative defaults and mandatory settings. 116 4. Address Books and Access Control 118 Almost every messaging system provides an interface for personal 119 address books which is distinct from a public directory service. 120 CMU's IMSP server provides an interface to multiple personal 121 address books. It also provides rich access control on address 122 books so they can be shared with other users. As soon as a client 123 interface was created for these functions they both became very 124 popular. They were so popular, in fact, that users started asking 125 for the ability to "subscribe" to address books so they didn't have 126 to wade though a large list. 128 The basic structure for IMSP address books was that each address 129 book was made up of a list of entries, and each entry was made up 130 of a set of (attribute, value) pairs. A set of basic attributes 131 was defined, and others were permitted. This structure 132 successfully provided the necessary flexibility. 134 Despite these successes, there are a number of problems with IMSP 135 address books. Access becomes slow when they get large, and 136 searching requires two round trips to the server. The original 137 server implementation didn't allow spaces in address book entry 138 names, but users soon demanded this flexibility. There were also 139 requests for access control groups to improve sharing of address 140 books. 142 Finally, it became clear that there are two different models for 143 address books in common use. The Unix/text-based model has a short 144 alias for each entry which expands to the email address. The 145 PC/GUI model uses common names which can be chosen from a list to 146 use as the email address. IMSP used the common name as the primary 147 key for address books, which makes implementation of the 148 Unix/text-based model inefficient due to the two-round trips needed 149 for searching. 151 The ACAP protocol should include address books with rich access 152 control and a "subscription" capability. It needs to address the 153 problems we've identified in IMSP. 155 5. Generalization of the Application Configuration problem 157 While IMSP was designed specifically for messaging applications, 158 the options and address book functions could be quite useful in 159 other applications. In addition, the mobility problem is not 160 limited to messaging. Web browser bookmarks are a prime example of 161 application configuration information which should be mobile. 163 Another observation was that the mailbox list features of IMSP 164 didn't seem to fit with the address book and configuration 165 portions, and each had different target markets. This recognition 166 was the primary motivation to invent ACAP. ACAP specifies a basic 167 model which can then be applied to support different applications. 169 6. Large Lists 171 The IMSP protocol model for address book entries and mailbox lists 172 is a serious problem for large lists. It requires fetching the 173 entire list, even when a client only has display space for the 174 first 50. This can be very slow on low memory machines and over 175 slow network connections. 177 ACAP should provide a way for clients to implement "virtual scroll 178 bars" where they only have to fetch what needs to be displayed to 179 the user. This means that ACAP needs rich server side searching 180 and sorting with the ability to fetch deterministic parts of the 181 resulting ordered list. 183 7. The ACAP "dataset" model 185 The CMU IMSP implementation ended up using the same database 186 backend for all the lists (options, address book entries, address 187 books, mailboxes). The server translated the function based 188 commands for each of these lists into a common set of backend 189 database operations. 191 ACAP can be a smaller and simpler protocol than IMSP if it provides 192 data based commands rather than function based commands. The idea 193 is to take the IMSP address book model and turn it in to a generic 194 container which can hold options, mailboxes, access control groups 195 or even web browser bookmarks. 197 Therefore the ACAP "dataset" model has the same structure as an 198 IMSP address book: a dataset is a set of entries and each entry is 199 a set of (attribute, value) pairs. 201 8. Conclusion 203 IMSP was a successful experiment which demonstrates the need for a 204 configuration server. ACAP is the logical refinement of the ideas 205 behind IMSP and is likely to become an important part of the 206 Internet protocol suite. 208 9. References 210 [IMSP] Myers, J., "Internet Message Support Protocol", 211 Experiment in progress, 212 http://andrew2.andrew.cmu.edu/cyrus/rfc/imsp.html, June 213 1995 215 [IMAP] Crispin, M., "Internet Message Access Protocol - 216 Version 4rev1", RFC 2060, University of Washington, 217 December 1996. 219 [ACAP] Newman, Myers, "Application Configuration Access 220 Protocol", Work in progress, June 1997. 222 10. Security Considerations 224 There are no known security issues in this memo. 226 11. Acknowledgments 228 Many thanks to Steve Hole and the ESYS corporation for their early 229 client support of IMSP which was invaluable to this effort. Thanks 230 also to Terry Gray for his insistence that IMSP was too application 231 specific and that something more general was needed. And thanks to 232 John Myers for his authorship of the IMSP specification and 233 observation that everything could fit into the address book model. 235 12. Author's Address 237 Chris Newman 238 Innosoft International, Inc. 239 1050 Lakes Drive 240 West Covina, CA 91790 242 Email: chris.newman@innosoft.com