Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_a_c/draft-ietf-acap-options-01.txt

Text File | 1997-07-30 | 11KB | 363 lines

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 <some registration procedure>.

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.<product/company>", where "<product/company" is
     the name of a specific application or application vendor.  The
     entries in the vendor namespace enumerate the applications that
     make use of ACAP option storage at that level.  Each vendor dataset
     contains option entries for a specific vendor application.


4.3. Example option namespace

     The following example demonstrates how the "common" and "vendor"
     namespace isolates application specific and general configuration.

               /option/
                    site/
                        common/
                        vendor.{application_1}/
                        vendor.{application_2}/
                        ...
                        ...
                    host/
                        {host_1}/
                            common/
                            vendor.{application_1}/
                            vendor.{application_2}/
                            ...
                            ...
                        {host_2}/
                        ...
                        ...
                    group/
                        {group_1}/
                            common/
                            vendor.{application_1}/
                            vendor.{application_2}/
                            ...
                            ...
                        {group_2}/
                        ...
                        ...
                    user/
                        {user_1}/
                            common/
                            vendor.{application_1}/
                            vendor.{application_2}/
                            ...
                            ...


Hole                                                            [Page 5]






Internet Draft                ACAP Options                    April 1997


                        {user_2}/
                        ...
                        ...

     4.4.  Option naming conventions

     What conventions?   Should there be any?


5. References

     [ACAP] Newman, C., Myers, J. G., "Application Configuration Access
     Protocol", Work in progress, July 1997.

         <ftp://ietf.org/internet-drafts/draft-ietf-acap-spec-04.txt>


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: [e-mail]













Hole                                                            [Page 6]