ACAP Standards

Information about the ACAP standards.

Introduction

Some of the content of this page was taken from Archive.org.

ACAP Related RFCs

ACAP RFC

RFC 2244, ACAP -- Application Configuration Access Protocol

The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted.

Anonymous SASL RFC

RFC 2245, Anonymous SASL Mechanism

It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using "anonymous" as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework.

SASL RFC

RFC 2222, SASL -- Simple Authentication and Security Layer

This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection.

Using TLS with IMAP, POP3, and ACAP

RFC 2595, Using TLS with IMAP, POP3 and ACAP

This specification defines extensions to IMAP, POP and ACAP which activate TLS. This also defines a simple PLAIN SASL mechanism for use underneath strong TLS encryption with ACAP or other protocols lacking a clear-text login command.

Wireless Device Configuration (OTASP/OTAPA) via ACAP

RFC 2636, Wireless Device Configuration (OTASP/OTAPA) via ACAP

A comprehensive and extensible means for over-the-air (OTA) provisioning and handset parameter updating is required.

A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol.

Proposed Datasets

Email-related datasets

ACAP Email Personality Dataset Class

Text or HTML

R. Gellens, February 2003

It has become common for Internet mail users to receive and compose mail in the capacity of different roles or identities (for example, personal and work), to receive and compose mail at different machines, and to use multiple programs which require mail composition configuration information. These different roles or identities have become known as email personalities. The Application Configuration Access Protocol (ACAP) provides an ideal mechanism for storage of email personality data. This specification defines a standard ACAP dataset class for email personalities, and a common option for indicating a default.

ACAP Email Account Dataset Class

Text or HTML

R. Gellens, August 2003 (17957 bytes)

It has become common for Internet mail users to have more than one account where mail is received, to access multiple accounts from the same machine, to access the same accounts from different machines, and to use multiple programs which require account configuration information. The Application Configuration Access Protocol (ACAP) provides an ideal mechanism for storage of email account data. This specification defines a standard ACAP dataset class for email accounts, and a common option for indicating a default email.

ACAP Mailbox Dataset Class

Text or HTML

L. Greenfield, 1998/11/18 (12894 bytes)

IMAP allows users to access the mail store in an efficient way, but has insufficient support to export detailed meta-level information about mailboxes, subscriptions, and multiple servers. The mailbox dataset provides a fast, flexible way of exporting this data.

ACAP Personal Addressbook Dataset Class

Text or HTML

C. Newman, 2002/11/25 (22937 bytes)

IMAP allows nomadic users to access their mail store from any client, but it does not support storage of personal addressbooks. Application Configuration Access Protocol (ACAP) provides an ideal mechanism for storage of personal addressbooks. While ACAP permits the definition of vendor specific solutions to this problem, having a standard addressbook dataset class permits clients from different vendors to interoperably share the same personal addressbooks. This specification defines a standard dataset class for personal addressbooks.

Miscellaneous datasets

ACAP Message of the Day Dataset Class

Text or HTML

R. Troll, 1999/2/26 (41317 bytes)

The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of common application option, configuration and preference information. Once such piece of information is the "Message of the Day" greeting, used by system administrators to communicate important information to all users when they begin to use a system. This document describes a common format for storing MOTD information in ACAP, how site administrators may configure their ACAP MOTD service to allow multiple groups within the site to provide custom MOTD information, and how a client should access and use this information.

ACAP Media Type Dataset Class

Text or HTML

C. Newman, A. Melnikov, 1998/12/23 (38784 bytes)

With the definition of standardized media types in MIME [MIME-IMT] it has become necessary to keep mapping tables which translate between the standard media type names, commonly used file name extensions, any platform specific typing mechanism, and helper applications to view, compose, edit or print media types. Supplying a set of site defaults is useful so that users won't have to configure well-known types. The mailcap mechanism [MAILCAP] provides some of this functionality in a homogeneous environment with a shared file system, and both the Macintosh program 'Internet Config' and the Windows Registry have had some success in consolidating these tables for multiple applications on a single machine. But neither of these addresses the problems of multi- platform users or a heterogeneous environment. ACAP provides precisely the right facilities for this need. ACAP's dataset structure is extensible and ACAP's inheritance feature is ideal for enterprise default settings with per-user customization.

ACAP Bookmarks Dataset Class

Text or HTML

R. Gellens, February 2003 (14130 bytes)

Storing URLs [URL] for later access has become common in Internet applications (for example, web browsers, FTP clients); these saved URLs have become known as bookmarks. It would be desirable to access one's bookmarks from multiple clients and multiple machines. The Application Configuration Access Protocol (ACAP) provides an ideal mechanism for storage of bookmarks, providing for ease of coordination and synchronization of bookmarks between diverse applications and systems, as well as for hierarchy, inheritance, and sharing. This specification defines a standard ACAP dataset class for bookmarks.

ACAP Personal Dictionary Dataset Class

Text or HTML

C. Daboo, 1998/03/12 (9575 bytes)

The Application Configuration Access Protocol [ACAP] is designed to support remote storage and access of common application option, configuration and preference information. Its main benefits are in providing a way for users to gain access to personal information from any computer at a location supporting an internet connection, by keeping this information stored centrally on a server. Additionally, it allows 'kiosk' style use of computers so that users do not need to store data locally on a shared or public workstation or network computer. This specification defines a standard dataset class for personal dictionaries that would allow users to keep one or more 'user dictionaries' stored on an ACAP server for access by any ACAP-aware application that requires such information, for example any application that uses a spell checker.

ACAP Application Options Dataset Class

Text or HTML

S. Hole, 1998/03/05 (21201 bytes)

The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of application option, configuration and preference information. The generalized form of this runtime configuration is called options. Options consist of any type of structured or unstructured data that an application requires to operate in a user specific manner.

ACAP Authorization Identifier Dataset Classes

Text or HTML

S. Hole, June 2002 (22937 bytes)

Most distributed (client/server) applications require an authentication process between the client and the server before the server will grant access to its managed resources. Many applications provide varying levels of access to server resources based on a combination of authentication credentials and access control rules. The collection of information used to control access to resources is called authorization information.

Proposed Extensions and Clarifications

An Introduction to the ACAP Dataset Model

Text or HTML

R. Troll, 1999/03/29 (21794 bytes)

The ACAP Dataset Model is very extensible, and allows applications to easily share options and information. With this extensibility comes a complexity that an application designer must fully understand in order to interoperate while using ACAP.

This document will help the reader understand and visualize the ACAP hierarchy, come to a better understanding of how to design and access ACAP datasets, and understand the relationship between attributes, entries, datasets, and dataset classes.

ACAP Type Extension

Text or HTML

R. Earhart, 1998/03/13 (11490 bytes)

The Application Configuration Access Protocol [ACAP] defines rough typing information in the form of an attribute naming convention. This extension to ACAP allows a MIME content-type/subtype with parameters to be associated with a given piece of data, providing knowledgeable clients with useful information in a way which maintains compatability with innocent clients and servers.

ACAP Datatyping and Datatyping Discovery

Text or HTML

J. De Winter, 1997/04/25 (15224 bytes)

The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. In certain circumstances, it is desirable or necessary to deal with information that has a limit imposed on it. While the general ACAP specification does provide for a (SYNTAX) alert to inform the submittor that the stored information was not in a valid syntax for that field, there is no generic method to discover that syntax. There is strong feeling in the ACAP working group that variable length strings should be used for data where possible, but there is also the knowledge that ACAP will be used to configure and access existing systems where the use of such variable length strings may be difficult or impossible.

Multi-Lingual String Format (MLSF)

Text or HTML

C. Newman, 1997/06/09. (23970 bytes)

The IAB charset workshop [IAB-CHARSET] concluded that for human-readable text there should always be a way to specify the natural language. Many protocols are designed with an attribute-value model (including RFC 822, HTTP, LDAP, SNMP, DHCP, and ACAP) which stores many small human readable text strings. The primary function of an attribute-value model is to simplify both extensibility and searchability. A solution is needed to provide language tags in these small human readable text strings, which does not interfere with these primary functions. This specification defines MLSF (Multi-Lingual String Format) which applies another layer of encoding on top of UTF-8 [UTF-8] to permit the addition of language tags anywhere within a text string. In addition, it defines an alternate form which can be used to include alternative representations of the same text in different character sets. MLSF has the property that UTF-8 is a proper subset of MLSF. This preserves the searchability requirement of the attribute-value model. Appendix F of this document includes a brief discussion of the background behind MLSF and why some other potential solutions were rejected for this purpose.

Two Alternative Proposals for Language Tagging in ACAP

Text or HTML

M. Duerst, 1997/06/23. (23739 bytes)

For various computing applications, it is helpful to know the language of the text being processed. This can be the case even if otherwise only pure character sequences (so-called plain text) are handled. From several sides, the need for such a scheme for ACAP has been claimed. One specific scheme, called MLSF, has also been proposed, see draft-ietf-acap-mlsf-01.txt for details. This document proposes two alternatives to MLSF. One alternative is using text/enriched-like markup. The second alternative is using a special tag-introduction character. Advantages and disadvantages of the various proposals are discussed. Some general comments about the topic of language tagging are given in the introduction.

Lessons Learned from IMSP

Text

C. Newman, July 1997. (12077 bytes)

IMSP (Internet Message Support Protocol) was designed and implemented to supply the support functions necessary for a large scale IMAP4 based infrastructure with highly mobile users. Although the protocol was successful in its mission, it was realized that a slightly different approach could achieve more for the Internet Standards community. Thus was born the idea for ACAP (Application Configuration Access Protocol).

This document will discuss the successes and failures of the IMSP protocol and how the IMSP experiment is influencing the design of ACAP.

The IETF site

Link: http://www.ietf.org/html.charters/OLD/acap-charter.html

Contents:

• The ACAP RFC
• ACAP Dataset classes

This site contains documentation on the work that the ACAP standards specification people are doing on the specification. Of particular interest will be the links at the bottom of the page, including the link to the ACAP RFC itself, and the links to the Draft of the RFC for Addressbooks, e-mail, and whatever.

The current incarnation of ACAP is the result of four years of standards-track work, done largely through standard IETF procedures. ACAP is an official working group in the applications area of the IETF. BOFS and formal working group meetings for ACAP and IMSP before it have been held at IETFs at Dallas, Montreal, San Jose, Memphis, Munich, and Washington DC, and at the International IMAP meetings in Seattle.

For more information on the IETF and standards procedures, visit the IETF home page.