< draft-newman-acap-imsp-lessons-01.txt		draft-newman-acap-imsp-lessons-02.txt >
	Network Working Group C. Newman		Network Working Group C. Newman
	Internet Draft: Lessons Learned from IMSP Innosoft		Internet Draft: Lessons Learned from IMSP Innosoft
	Document: draft-newman-acap-imsp-lessons-01.txt December 1996		Document: draft-newman-acap-imsp-lessons-02.txt July 1997
			Expires in six months
	Lessons Learned from IMSP		Lessons Learned from IMSP
	Status of this memo		Status of this memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its Working Groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet Drafts.		working documents as Internet-Drafts.
	Internet Drafts are draft documents valid for a maximum of six
	months. Internet Drafts may be updated, replaced, or obsoleted by
	other documents at any time. It is not appropriate to use Internet
	andrewDrafts as reference material or to cite them other than as a
	``working draft'' or ``work in progress``.
	To learn the current status of any Internet-Draft, please check the		Internet-Drafts are draft documents valid for a maximum of six
	1id-abstracts.txt listing contained in the Internet-Drafts Shadow		months and may be updated, replaced, or obsoleted by other
	Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or		documents at any time. It is inappropriate to use Internet-Drafts
	munnari.oz.au.		as reference material or to cite them other than as "work in
			progress."
	A revised version of this draft document will be submitted to the		To view the entire list of current Internet-Drafts, please check
	RFC editor as a Proposed Standard for the Internet Community.		the "1id-abstracts.txt" listing contained in the Internet-Drafts
	Discussion and suggestions for improvement are requested. This		Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
	document will expire six months after publication. Distribution of		(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
	this draft is unlimited.		Coast), or ftp.isi.edu (US West Coast).
	1. Introduction		Introduction
	IMSP (Internet Message Support Protocol) [IMSP] was designed and		IMSP (Internet Message Support Protocol) [IMSP] was designed and
	implemented to supply the support functions necessary for a large		implemented to supply the support functions necessary for a large
	scale IMAP4 based infrastructure with highly mobile users.		scale IMAP4 based infrastructure with highly mobile users.
	Although the protocol was successful in its mission, it was		Although the protocol was successful in its mission, it was
	realized that a slightly different approach could achieve more for		realized that a slightly different approach could achieve more for
	the Internet Standards community. Thus was born the idea for ACAP		the Internet Standards community. Thus was born the idea for ACAP
	(Application Configuration Access Protocol) [ACAP].		(Application Configuration Access Protocol) [ACAP].
	This document will discuss the successes and failures of the IMSP		This document will discuss the successes and failures of the IMSP
	protocol and how the IMSP experiment is influencing the design of		protocol and how the IMSP experiment is influencing the design of
	ACAP.		ACAP.
	2. The origin of IMSP		1. The origin of IMSP
	CMU (Carnegie Mellon University) has been running an experimental		CMU (Carnegie Mellon University) has been running an experimental
	messaging system called AMS (Andrew Message System) for many years.		messaging system called AMS (Andrew Message System) for many years.
	AMS has been extremely successful and has lead to a situation where		AMS has been extremely successful and has lead to a situation where
	mail, shared bboards, and newsgroups are used daily by people from		mail, shared bboards, and newsgroups are used daily by people from
	all over the University, including non-technical departments.		all over the University, including non-technical departments.
	Unfortunately, AMS has two fatal flaws. It is dependant on AFS		Unfortunately, AMS has two fatal flaws. It is dependant on AFS
	(Andrew File System) which inhibits scaling and cross-platform use,		(Andrew File System) which inhibits scaling and cross-platform use,
	and is not standards based so that all clients have to be developed		and is not standards based so that all clients have to be developed
	in-house.		in-house.
	In 1992, CMU begin working through the Internet standards process		In 1992, CMU begin working through the Internet standards process
	to bring the functionality of AMS to the standards community. CMU		to bring the functionality of AMS to the standards community. CMU
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 30 ¶
	1) Storage for client configuration information.		1) Storage for client configuration information.
	2) Storage for user address books.		2) Storage for user address books.
	3) Mailbox distribution/replication support.		3) Mailbox distribution/replication support.
	The first two components are successfully used today at a number of		The first two components are successfully used today at a number of
	large sites. Experiments with the third component are ongoing.		large sites. Experiments with the third component are ongoing.
	3. Mobile Users		2. Nomadic Users
	Universities, Hospitals and other large sites need a message system		Universities, Hospitals and other large sites need a message system
	where any PC or workstation can be used to access messages		where any PC or workstation can be used to access messages
	transparently. As tele-commuting and laptops become more popular,		transparently. As tele-commuting and laptops become more popular,
	more individuals are faced with the problem of accessing their		more individuals are faced with the problem of accessing their
	messages from more than one computer and often more than one		messages from more than one computer and often more than one
	platform. While IMAP4 [IMAP] allows users to access their message		platform. While IMAP4 [IMAP] allows users to access their message
	stores, it does not provide storage for address books and		stores, it does not provide storage for address books and
	configuration information needed by these mobile users. IMSP fills		configuration information needed by these mobile users. IMSP fills
	this niche.		this niche.
	This need is so great that a significant number of sites have		This need is so great that a significant number of sites have
	deployed IMAP4 and IMSP despite the immaturity of IMAP clients in		deployed IMAP4 and IMSP despite the immaturity of IMAP clients in
	1995 and the experimental nature of IMSP. The IMAP4/IMSP		1995 and the experimental nature of IMSP. The IMAP4/IMSP
	combination allows users to move from machine to machine and get		combination allows users to move from machine to machine and get
	the same configuration and interface.		the same configuration and interface.
	4. Client Configuration		3. Client Configuration
	The CMU IMSP server implementation provides server storage of		The CMU IMSP server implementation provides server storage of
	client configuration and also provides administrative defaults or		client configuration and also provides administrative defaults or
	mandatory settings for client configuration. Our experiments show		mandatory settings for client configuration. Our experiments show
	this is a great success.		this is a great success.
	For example, many sites wish to control what appears in the "From:"		For example, many sites wish to control what appears in the "From:"
	header of outgoing mail, while other sites let the user do as they		header of outgoing mail, while other sites let the user do as they
	choose. The CMU IMSP server allows sites to configure either a		choose. The CMU IMSP server allows sites to configure either a
	default "From:" address, or a mandatory "From:" address based on		default "From:" address, or a mandatory "From:" address based on
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 27 ¶
	private configuration information on the IMSP server, in addition		private configuration information on the IMSP server, in addition
	to common configuration options. The decision to create an IMSP		to common configuration options. The decision to create an IMSP
	options registry for common options as well as reserving parts of		options registry for common options as well as reserving parts of
	the name space with vendor specific prefixes appears to be sound.		the name space with vendor specific prefixes appears to be sound.
	Options appear to work well as they are implemented in IMSP, and		Options appear to work well as they are implemented in IMSP, and
	are certainly not limited to messaging. ACAP should include an		are certainly not limited to messaging. ACAP should include an
	option registry with vendor specific prefixes, as well as		option registry with vendor specific prefixes, as well as
	administrative defaults and mandatory settings.		administrative defaults and mandatory settings.
	5. Address Books and Access Control		4. Address Books and Access Control
	Almost every messaging system provides an interface for personal		Almost every messaging system provides an interface for personal
	address books which is distinct from a public directory service.		address books which is distinct from a public directory service.
	CMU's IMSP server provides an interface to multiple personal		CMU's IMSP server provides an interface to multiple personal
	address books. It also provides rich access control on address		address books. It also provides rich access control on address
	books so they can be shared with other users. As soon as a client		books so they can be shared with other users. As soon as a client
	interface was created for these functions they both became very		interface was created for these functions they both became very
	popular. They were so popular, in fact, that users started asking		popular. They were so popular, in fact, that users started asking
	for the ability to "subscribe" to address books so they didn't have		for the ability to "subscribe" to address books so they didn't have
	to wade though a large list.		to wade though a large list.
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 19 ¶
	PC/GUI model uses common names which can be chosen from a list to		PC/GUI model uses common names which can be chosen from a list to
	use as the email address. IMSP used the common name as the primary		use as the email address. IMSP used the common name as the primary
	key for address books, which makes implementation of the		key for address books, which makes implementation of the
	Unix/text-based model inefficient due to the two-round trips needed		Unix/text-based model inefficient due to the two-round trips needed
	for searching.		for searching.
	The ACAP protocol should include address books with rich access		The ACAP protocol should include address books with rich access
	control and a "subscription" capability. It needs to address the		control and a "subscription" capability. It needs to address the
	problems we've identified in IMSP.		problems we've identified in IMSP.
	6. Generalization of the Application Configuration problem		5. Generalization of the Application Configuration problem
	While IMSP was designed specifically for messaging applications,		While IMSP was designed specifically for messaging applications,
	the options and address book functions could be quite useful in		the options and address book functions could be quite useful in
	other applications. In addition, the mobility problem is not		other applications. In addition, the mobility problem is not
	limited to messaging. Web browser bookmarks are a prime example of		limited to messaging. Web browser bookmarks are a prime example of
	application configuration information which should be mobile.		application configuration information which should be mobile.
	Another observation was that the mailbox list features of IMSP		Another observation was that the mailbox list features of IMSP
	didn't seem to fit with the address book and configuration		didn't seem to fit with the address book and configuration
	portions, and each had different target markets. This recognition		portions, and each had different target markets. This recognition
	was the primary motivation to invent ACAP. ACAP specifies a basic		was the primary motivation to invent ACAP. ACAP specifies a basic
	model which can then be applied to support different applications.		model which can then be applied to support different applications.
	7. Large Lists		6. Large Lists
	The IMSP protocol model for address book entries and mailbox lists		The IMSP protocol model for address book entries and mailbox lists
	is a serious problem for large lists. It requires fetching the		is a serious problem for large lists. It requires fetching the
	entire list, even when a client only has display space for the		entire list, even when a client only has display space for the
	first 50. This can be very slow on low memory machines and over		first 50. This can be very slow on low memory machines and over
	slow network connections.		slow network connections.
	ACAP should provide a way for clients to implement "virtual scroll		ACAP should provide a way for clients to implement "virtual scroll
	bars" where they only have to fetch what needs to be displayed to		bars" where they only have to fetch what needs to be displayed to
	the user. This means that ACAP needs rich server side searching		the user. This means that ACAP needs rich server side searching
	and sorting with the ability to fetch deterministic parts of the		and sorting with the ability to fetch deterministic parts of the
	resulting ordered list.		resulting ordered list.
	8. The ACAP "dataset" model		7. The ACAP "dataset" model
	The CMU IMSP implementation ended up using the same database		The CMU IMSP implementation ended up using the same database
	backend for all the lists (options, address book entries, address		backend for all the lists (options, address book entries, address
	books, mailboxes). The server translated the function based		books, mailboxes). The server translated the function based
	commands for each of these lists into a common set of backend		commands for each of these lists into a common set of backend
	database operations.		database operations.
	ACAP can be a smaller and simpler protocol than IMSP if it provides		ACAP can be a smaller and simpler protocol than IMSP if it provides
	data based commands rather than function based commands. The idea		data based commands rather than function based commands. The idea
	is to take the IMSP address book model and turn it in to a generic		is to take the IMSP address book model and turn it in to a generic
	container which can hold options, mailboxes, access control groups		container which can hold options, mailboxes, access control groups
	or even web browser bookmarks.		or even web browser bookmarks.
	Therefore the ACAP "dataset" model has the same structure as an		Therefore the ACAP "dataset" model has the same structure as an
	IMSP address book: a dataset is a set of entries and each entry is		IMSP address book: a dataset is a set of entries and each entry is
	a set of (attribute, value) pairs.		a set of (attribute, value) pairs.
	9. Conclusion		8. Conclusion
	IMSP was a successful experiment which demonstrates the need for a		IMSP was a successful experiment which demonstrates the need for a
	configuration server. ACAP is the logical refinement of the ideas		configuration server. ACAP is the logical refinement of the ideas
	behind IMSP and is likely to become an important part of the		behind IMSP and is likely to become an important part of the
	Internet protocol suite.		Internet protocol suite.
	10. References		9. References
	[IMSP] Myers, J., "Internet Message Support Protocol",		[IMSP] Myers, J., "Internet Message Support Protocol",
	Experiment in progress,		Experiment in progress,
	http://andrew2.andrew.cmu.edu/cyrus/rfc/imsp.html,		http://andrew2.andrew.cmu.edu/cyrus/rfc/imsp.html, June
	June 1995		1995
	[IMAP] Crispin, M., "Internet Message Access Protocol -		[IMAP] Crispin, M., "Internet Message Access Protocol -
	Version 4rev1", RFC 2060, University of		Version 4rev1", RFC 2060, University of Washington,
	Washington, December 1996.		December 1996.
	[ACAP] Myers, J., "Application Configuration Access		[ACAP] Newman, Myers, "Application Configuration Access
	Protocol", Work in progress, November 1996.		Protocol", Work in progress, June 1997.
	11. Security Considerations		10. Security Considerations
	There are no known security issues in this memo.		There are no known security issues in this memo.
	12. Acknowledgments		11. Acknowledgments
	Many thanks to Steve Hole and the ESYS corporation for their		Many thanks to Steve Hole and the ESYS corporation for their early
	early client support of IMSP which was invaluable to this		client support of IMSP which was invaluable to this effort. Thanks
	effort. Thanks also to Terry Gray for his insistence that		also to Terry Gray for his insistence that IMSP was too application
	IMSP was too application specific and that something more		specific and that something more general was needed. And thanks to
	general was needed. And thanks to John Myers for his		John Myers for his authorship of the IMSP specification and
	authorship of the IMSP specification and observation that		observation that everything could fit into the address book model.
	everything could fit into the address book model.
	13. Author's Address		12. Author's Address
	Chris Newman		Chris Newman
	Innosoft International, Inc.		Innosoft International, Inc.
	1050 E Garvey Ave S.		1050 Lakes Drive
	West Covina, CA 91790		West Covina, CA 91790
	Email: chris.newman@innosoft.com		Email: chris.newman@innosoft.com
End of changes. 24 change blocks.
	51 lines changed or deleted		47 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/