RFC 2244: ACAP -- Application Configuration Access Protocol
Hi,
I think people on the list shall find this of interest.
manoj
______________________________________________________________________
Network Working Group C. Newman
Request for Comments: 2244 Innosoft
Category: Standards Track J. G. Myers
Netscape
November 1997
ACAP -- Application Configuration Access Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society 1997. All Rights Reserved.
Abstract
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.
______________________________________________________________________
[...deleted...]
______________________________________________________________________
1.2. ACAP Data Model
An ACAP server exports a hierarchical tree of entries. Each level of
the tree is called a dataset, and each dataset is made up of a list
of entries. Each entry has a unique name and may contain any number
of named attributes. Each attribute within an entry may be single
valued or multi-valued and may have associated metadata to assist
access and interpretation of the value.
The rules with which a client interprets the data within a portion of
ACAP's tree of entries are called a dataset class.
1.3. ACAP Design Goals
ACAP's primary purpose is to allow users access to their
configuration data from multiple network-connected computers. Users
can then sit down in front of any network-connected computer, run any
ACAP-enabled application and have access to their own configuration
data. Because it is hoped that many applications will become ACAP-
enabled, client simplicity was preferred to server or protocol
simplicity whenever reasonable.
ACAP is designed to be easily manageable. For this reason, it
includes "inheritance" which allows one dataset to inherit default
attributes from another dataset. In addition, access control lists
are included to permit delegation of management and quotas are
included to control storage. Finally, an ACAP server which is
conformant to this base specification should be able to support most
dataset classes defined in the future without requiring a server
reconfiguration or upgrade.
ACAP is designed to operate well with a client that only has
intermittent access to an ACAP server. For this reason, each entry
has a server maintained modification time so that the client may
detect changes. In addition, the client may ask the server for a
list of entries which have been removed since it last accessed the
server.
ACAP presumes that a dataset may be potentially large and/or the
client's network connection may be slow, and thus offers server
sorting, selective fetching and change notification for entries
within a dataset.
As required for most Internet protocols, security, scalability and
internationalization were important design goals.
Given these design goals, an attempt was made to keep ACAP as simple
as possible. It is a traditional Internet text based protocol which
massively simplifies protocol debugging. It was designed based on
the successful IMAP [IMAP4] protocol framework, with a few
refinements.
1.4. Validation
By default, any value may be stored in any attribute for which the
user has appropriate permission and quota. This rule is necessary to
allow the addition of new simple dataset classes without
reconfiguring or upgrading the server.
In some cases, such as when the value has special meaning to the
server, it is useful to have the server enforce validation by
returning the INVALID response code to a STORE command. These cases
MUST be explicitly identified in the dataset class specification
which SHOULD include specific fixed rules for validation. Since a
given ACAP server may be unaware of any particular dataset class
specification, clients MUST NOT depend on the presence of enforced
validation on the server.
--
We are all apt to believe what the world believes about us. --
George Eliot
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-admintool-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: