rfc2636.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

    As a standard ACAP server, the provisioning server includes
    configurable datasets and dataset inheritance for the management of
    the data stores.

    The administrative client can use the same simple ACAP protocol to
    load and modify the ACAP server as the mobile stations uses for
    provisioning.  While any implementation-specific mechanisms
    available from the server vendor could instead be used for this
    purpose, the ability to use ACAP can greatly simplify the
    administrative client, as well as make it independent of the server.

    ACAP includes an authentication framework (Simple Authentication and
    Security Layer, SASL, RFC 2222)[SASL].  SASL allows any standard or
    custom authentication and encryption mechanism to be used.  One of
    the most important features of SASL is that it is designed for a
    world in which what is "good enough" security today isn't good
    enough tomorrow.  As the threat model changes, SASL allows higher-
    strength mechanisms to be easily added while supporting already



Gellens                      Informational                     [Page 12]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


    deployed clients and servers.  SASL is achieving widespread
    deployment in a number of Internet protocols.

    Strongpoints:  Since the ACAP protocol was designed for precisely
    this type of provisioning activity, its adoption can greatly reduce
    the cost, time to market, and support required for the provisioning
    server.  Additionally, the ACAP protocol provides an open standard
    method for mobile stations and other systems to access the
    provisioning server.  Commercial ACAP servers are being developed by
    numerous companies.  The ACAP client code is very small and simple,
    and thus can be incorporated into virtually any mobile device at
    minimal cost.  As an open standard, the ACAP protocol has benefited
    from years of review and experience.

5.1.4.  Overview of ACAP Structure

    ACAP organizes data by datasets.  The structure of a dataset is
    defined by the dataset class.  Generally, ACAP servers do not have
    knowledge of dataset classes.  This allows the dataset to be
    expanded without modifying the server in any way.  A dataset is an
    instantiation of the dataset class, which is a logical definition of
    what is in a dataset, and how it is used.

    Datasets contain entries.  Entries contain attributes and values.
    Attributes and values are actually metadata, such as name, length,
    and value.  Any entry can also be a dataset (datasets are
    hierarchical).

    For example, consider the ACAP addressbook dataset class, designed
    to hold names, email addresses, phone numbers, and related
    information for a person's contacts.  A given user may have one or
    more addressbook datasets.  Each entry holds information about one
    person or entity.  Attributes in the entry hold specific items of
    information, such as the given name, surname, various email
    addresses, phone numbers, and so forth.  If an entry is a list of
    people (such as a mailing list or specific group of people), it is a
    subdataset, containing its own entries.  Some clients may look at
    only a subset of the attributes.  For example, a mobile handset ACAP
    client may download only the alias (nickname), name, primary phone
    number and email address of each entry, while a desktop client may
    access all attributes.

5.1.5.  Data Organization and Capabilities

    ACAP provides custom hierarchical datasets.  Server data can be
    organized to fit the needs of the applications using the dataset.





Gellens                      Informational                     [Page 13]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


    In OTASP/OTAPA over ACAP, data on the server is organized to both
    take advantage of ACAP capabilities and to use items that are
    identical to IS-683A, allowing for reuse of IS-683A handset engines.

    ACAP servers also support data inheritance.  All data items which
    are physically in the inherited dataset and not in the inheriting
    dataset logically also exist in the inheriting dataset.  This is
    recursive, as the inherited dataset can itself inherit from another
    dataset.  This powerful concept allows potentially large groups of
    mobile stations to inherit items from a single common entity.  For
    example, preferred roaming lists can be stored in datasets based on
    geographic areas, and automatically inherited by an individual
    mobile station in that area.  The roaming lists could be further
    subdivided, for example based on tiers of free NVRAM in the mobile.
    The mobile client need not be aware of this; it happens entirely on
    the server.

    ACAP uses trees to provide the data hierarchy.  These data trees can
    be viewed as similar to the directory/file structure used with all
    common operating systems.  The built-in inheritance mechanism,
    together with the hierarchical structure, makes it extremely easy to
    update general data without disturbing specific data.

    Datasets exist within the user, group, and host hierarchies.  The
    user hierarchy holds datasets which belong to individual users.  The
    group hierarchy holds datasets which belong to groups (for example,
    the "Region." groups in section 5.1.6.3  Server Roaming Lists).  The
    host hierarchy holds datasets which are for specific machines or
    systems.

    In addition to providing customizable data trees, ACAP also provides
    several standard datasets for all clients.  There is a capabilities
    dataset that contains information on custom functionality and
    enhanced features available to a specific client or at the site
    generally.  This allows a server to advertise any protocol
    extensions, specialized attribute handling, or other enhanced
    functionality it supports.  A client that needs to use these
    features can thus easily determine what is available before trying
    to use them.

5.1.5.1.  Structure

    We divide the data accessed by the client into provisioning items,
    group items, and client state items.  Provisioning data contains NAM
    items and requested-data items.  Group items (such as preferred
    roaming lists), are not specific to any mobile device.  Group items
    physically exist in their own datasets, but through inheritance
    logically appear in client datasets.



Gellens                      Informational                     [Page 14]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


    The mobile stations always read data from provisioning entries and
    write data to client state entries.  This structure makes both
    mobile clients and server configuration easy and simple, while
    allowing for extensive custom and diagnostic capabilities.

5.1.5.2.  Conventions

    "" This signifies the empty string (used here for ACAP entries).

    ~ This is shorthand for "user/<userid>".  It is part of the ACAP
    protocol.

5.1.5.3. Dataset

    Provisioning information is located in the "OTAP" dataset class.
    (The full specification of this dataset will be published in a
    subsequent document.) The prefix "Provision." is used for items that
    are to be downloaded to the mobile, and the prefix "Client." is used
    for items which the client stores on the server.

    Provisioning data within the OTAP dataset is organized as a series
    of items, each of which is stored in its own entry.  The entry name
    is the item name, and the "OTAP.VALUE" attribute contains the item
    value.  This structure permits change notification on a per-item
    basis.

    We chose the "Provision" and "Client" names to simplify various
    operations.  For example, the mobile client can easily download all
    changed provisioning items by performing a search which returns the
    "OTAP.VALUE" attribute of all entries whose name begins with
    "Provision" and whose modtime is greater than the last time the
    client retrieved data.  An administrative client can easily generate
    a report of all clients which have not received the most recent
    update by searching for all entries named "Client" whose
    "OTAP.modtime" attribute is less than the desired value.

    A partial list of items follows.

5.1.5.4.  Entries and Attributes

    dataset.inherit

    This is a standard ACAP attribute that identifies the location of
    inherited data.  It exists in the "" entry (the entry with the empty
    name) within each dataset.






Gellens                      Informational                     [Page 15]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


5.1.5.5.  NAM Records

    The OTAP dataset class contains an entry for each provisioned
    mobile.  The standard location for provisioning records is:

        /OTAP/USER/<esn>/<nam>/

    This tree format allows multiple NAMs per ESN.  The specific entries
    contain data in IS-683A parameter block types.

    For example, the CDMA NAM would be stored in an entry called:

        /OTAP/USER/<esn>/<nam>/Provision.CDMA-NAM/

    The entries below show how NAM records would be organized on the
    ACAP server:

    CDMA/Analog NAM

        Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.CDMA-AMPS-NAM/

        OTAP.Value: {17} xx xx xx ... xx

        The CDMA/Analog NAM entry from IS-683A (section 4.5.2.1)
        consists of at least 129 information bits, depending on the
        number of SID NID list entries.  This is stored as 17 (or more)
        octets of binary data (padding is used to ensure an integral
        number of octets).

    Mobile Directory Number

        Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.MOBILE-DN/

        OTAP.Value: {10} nnnnnnnnnn

        The Mobile Directory Number from IS-683A contains BCD-encoded
        digits representing the phone number.  This is stored as a
        string of 10 or more ASCII digits, e.g., "6195551212".

    CDMA NAM

        Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.CDMA-NAM/

        OTAP.Value: {13} xx xx xx ... xx







Gellens                      Informational                     [Page 16]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


        The CDMA-NAM entry from IS-683A (section 4.5.2.3) consists of at
        least 100 information bits, depending on the number of SID-NID
        list entries.  This is stored as 13 (or more) octets of binary
        data (padding is used to ensure an integral number of octets).

    IMSI_T

        Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.IMSI_T/

        OTAP.Value: {7} xx xx xx xx xx xx xx

        The IMSI_T entry from IS-683A (section 4.5.2.4) consists of 55
        bits of information in five fields.  This is stored left-
        justified in 7 octets of binary data.

5.1.5.6.  Server Roaming Lists

    The ACAP Server will have an entry for each different roaming list
    configuration for a carrier.  The example below assumes that the
    desired differentiation for the roaming list is geographic, with
    subdivisions for tiers of mobile free NVRAM It shows that for each
    region there exists a set of roaming lists per free NVRAM range.
    Note that a carrier can easily implement different or further
    differentiation (e.g., by phone vendor or product type) by simply
    changing the dataset tree and assigned the appropriate value to the
    "dataset.inherit" attribute in the provisioning records.

        /OTAP/GROUP/region.NorthEast/free-nv.128-512/
                    preferred.roaming.list/OTAP.Value
        /OTAP/GROUP/region.NorthEast/free-nv.512-1024/
                    preferred.roaming.list/OTAP.Value
        /OTAP/GROUP/region.SouthEast/free-nv.128-512/
                    preferred.roaming.list/OTAP.Value
        /OTAP/GROUP/region.SouthEast/free-nv.512-1024/
                    preferred.roaming.list/OTAP.Value
        /OTAP/GROUP/region.NorthWest/free-nv.128-512/
                    preferred.roaming.list/OTAP.Value
        /OTAP/GROUP/region.NorthWest/free-nv.512-1024/
                    preferred.roaming.list/OTAP.Value
        /OTAP/GROUP/region.SouthWest/free-nv.128-512/
                    preferred.roaming.list/OTAP.Value
        /OTAP/GROUP/region.SouthWest/free-nv.512-1024/
                    preferred.roaming.list/OTAP.Value








Gellens                      Informational                     [Page 17]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


5.1.5.7.  Requested-Data Record

    Inside the OTAP dataset is an entry with the name
    "Provision.Requested-Data", which contains one attribute called
    "OTAP.Requested-Data".  This attribute is multi-valued.  It is
    either NIL or contains a list of strings.  Each string is the name
    of one element of data that the server requests the client to
    supply.

    After authenticating, the ACAP client issues a SEARCH command to
    retrieve the values of the "OTAP.Requested-Data" attribute of the
    "Provision.Requested-Data" entry.  The client processes the returned
    values (if any) by issuing a STORE command to set one or more
    attributes in the "Client" entry.  The value of each attribute is
    either the corresponding mobile value (which may be an empty string
    if the item has no value), or the special value "[N/A]" if the item
    does not exist or is unknown on the mobile.

    This mechanism is quite general, and can be used in the normal OTASP
    case to modify the mobile's dataset as appropriate for the condition