Network Working Group S. Hole Internet Draft: ACAP The Esys Corporation Document: draft-ietf-acap-options-01.txt July 1997 Expires: December, 1997 ACAP personal options dataset class Status of this memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute 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 Drafts 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 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Discussion and suggestions for improvement are requested. This document will expire six months after publication. Distribution of this draft is unlimited. 0. Administrivia 0.1. Changes from Last Internet Draft 1) Replaced "list" options with "scalar" options. This is possible because of the new multivalued attributes. 2) Defined "structured" option to contain "field" attributes. 3) Defined relationship between structured attributes and content specific dataset class definitions. 4) Tossed the discussion on modelling structured configuration. It should be discussed in a BCP after we have more experience. 5) Simplified the discussion on hierarchical option storage. Hole [Page 1] Internet Draft ACAP Options April 1997 6) Tossed the section on recommended attribute names. It really doesn't apply here. 7) Incorporated Chris's description of the standard second level of dataset hierarchy. 0.2. Open Issues 1) Do we need a registration procedure for common scalar options? This would be a lighter weight registration than that required for dataset class specifications -- basically a naming convention. 2) Do we need recommendations on option naming conventions (4.7)? 1. Introduction 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 consist of any type of structured or unstructured data that an application requires to operate in a user specific manner. Storage of application options in an ACAP server substantially solves the "kiosk user" problem for applications -- serial use of a single machine by multiple users. It also solves the "nomadic user" problem -- use of more than one machine on a regular basis by a single user. The specification defines the "option" dataset class for use with ACAP. 2. Conventions used in this document The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC xxxx. The attribute syntax specifications use the Augmented Backus-Naur Form (ABNF) notation as specified in [IMAIL]. 3. ACAP personal options 3.1. ACAP option representation Individual options are represented as ACAP entries in option Hole [Page 2] Internet Draft ACAP Options April 1997 datasets. The name of the entry, as defined by the "entry" attribute for the entry, is the name of option. 3.2. Scalar options Scalar options are ACAP entries that contain simple (unstructured) data. The "option.value" attribute of the entry contains the data for the option. The value can be single or multivalued. Following is an example of a single and multivalued scalar option: color.preferred entry = "color.preferred" option.value = "blue" color.list entry = "color.list" option.value = ("red" "green" "blue" "cyan" "black") Scalar options that are intended to be used by multiple applications should be registered as defined in . 3.3. Structured options Structured options are ACAP entries that contain multiple related items of data in a single option. Data for the option is contained in multiple named attributes collectively called "field attributes". Each field attribute can be single or multivalued. Following is an example of a structured option: color.definition entry = "color.definition" option.color.definition.name = "blue" option.color.definition.rgb = ("blue=255" "red=0" "green=0") option.color.definition.index = "66" By definition, structured options are application specific. While the content of the field attributes can be obtained by any application, it's intended use is open to interpretation by the application. Option datasets that that are intended to be used by multiple applications and consist entirely of structured options with the same field attributes, MUST be defined and registered in their own dataset class as per the rules in [ACAP]. Under this definition, content specific datasets are multi-application, structured option Hole [Page 3] Internet Draft ACAP Options April 1997 sets. 3.4. ACAP option hierarchy Option sets MAY be represented using ACAP hierarchy. Any entry in an option dataset can also be a hierarchy node by setting the "subdataset" attribute. Applications can model arbitrarily structured configuration using hierarchical datasets containing scalar or structured options. An option subdataset of scalar options models an associative list. An option subdataset of structured options models an array of structures. 4. ACAP option namespace The general ACAP namespace is organized to promote inheritance between site, host, group, and user specific configuration information, as defined in [ACAP]. It defines a "site", "group", "host", and "user" second level hierarchy. The option dataset defines a third level of hierarchy that promotes inheritance from second level datasets, and isolates user and application specific instances of configuration information. 4.1. ACAP "/option" dataset class The dataset class whose name is "/option" is assumed to contain option datasets as defined in this specification. 4.2. Third level option datasets Third level option datasets break the option namespace into generic and application specific option sets. This serves two purposes: to promote the creation and inheritance of common options between applications, and isolation of application specific configuration from other applications. 4.2.1. The "common" option namespace The "common" option namespace is a dataset named "common", that contains option entries that are generally applicable to the containing namespace. For example, a "common" option dataset below a "user/user_X" dataset are options that are generally applicable to the user "user_X" for many applications. Hole [Page 4] Internet Draft ACAP Options April 1997 4.2.2. The "vendor" option namespace The "vendor" option namespace is a set of datasets, each named in the form "vendor.", where " 6. Security Considerations It is important to make sure that access controls are set correctly on personal options. Sensitive configuration information, including application security information, should not be exposed to other users without the explicit request of the user. This specification does not address storing private certificates and other security information in the option namespace. This may be added to a future version of this specification when more experimentation has been done. 7. Authors' Addresses Steve Hole The Esys Corporation 900 10040 - 104 St. Edmonton, Alberta, T5J 0Z2, CANADA Email: Steve.Hole@esys.ca Hole [Page 6]