home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1800s / rfc1804.txt < prev    next >
Text File  |  1995-06-07  |  18KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       G. Mansfield
  8. Request for Comments: 1804                              AIC Laboratories
  9. Category: Experimental                                         P. Rajeev
  10.                                                  Hughes Software Systems
  11.                                                              S. Raghavan
  12.                                   Indian Institute of Technology, Madras
  13.                                                                 T. Howes
  14.                                                   University of Michigan
  15.                                                                June 1995
  16.  
  17.  
  18.                   Schema Publishing in X.500 Directory
  19.  
  20. Status of this Memo
  21.  
  22.    This memo defines an Experimental Protocol for the Internet
  23.    community.  This memo does not specify an Internet standard of any
  24.    kind.  Discussion and suggestions for improvement are requested.
  25.    Distribution of this memo is unlimited.
  26.  
  27. Abstract
  28.  
  29.    The X.500 directory provides a powerful mechanism for storing and
  30.    retrieving information about objects of interest.  To interpret the
  31.    information stored in the directory, the schema must be known to all
  32.    the components of the directory. Presently, there are no means other
  33.    than ftp to distribute schema information across the Internet.  This
  34.    is proving to be a severe constraint as the Directory is growing.
  35.    This document presents a solution to the schema distribution problem
  36.    using the existing mechanisms of the directory. A naming scheme for
  37.    naming schema objects and a meta-schema for storing schema objects is
  38.    presented. The procedures for fetching unknown schema from the
  39.    directory at runtime are described.
  40.  
  41. Table of Contents
  42.  
  43.    1. Introduction                                         2
  44.    2. Schema Management                                    2
  45.    3. Storage of Schema Information in the Directory       3
  46.    4. Retrieval of Schema from the Directory               5
  47.    5. The Meta-Schema                                      6
  48.    6. References                                           9
  49.    7. Security Considerations                              9
  50.    8. Authors' Addresses                                  10
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Mansfield, et al              Experimental                      [Page 1]
  59.  
  60. RFC 1804          Schema Publishing in X.500 Directory         June 1995
  61.  
  62.  
  63. 1. Introduction
  64.  
  65.    The X.500 Directory [1] is now used for a wide range of applications
  66.    from name/address lookup to network management, from restaurant
  67.    information to bibliographic information services. This information
  68.    is distributed and managed across a network of many autonomous sites.
  69.    In order to interpret the information stored in the directory, the
  70.    components of the directory must have knowledge about the structure
  71.    and representation (schema) of the information held within the
  72.    directory.
  73.  
  74.    The distributed nature of the network and the relatively slow process
  75.    of standardization have given rise to the challenging task of making
  76.    accessible the information about the schema rules themselves.  A
  77.    mechanism for making the schema accessible to the functional
  78.    components of the directory is urgently required.
  79.  
  80.    The 1993 X.500 Directory Standard [2] has attempted to address the
  81.    problem of schema management and distribution. The 1993 framework
  82.    does provide the means for storing and retrieving schema information
  83.    in the directory. However, the resolution of unknown OIDs will
  84.    require both the DUA and the DSA to be compliant with [2].
  85.  
  86.    In this document we propose a solution using the existing mechanisms
  87.    of the directory [1] itself. We present a naming scheme for naming
  88.    schema objects and a meta-schema for storing schema objects in the
  89.    directory.  The proposal allows the algorithmic resolution of unknown
  90.    objects in the directory and in the absence of 1993 X.500 Directory
  91.    Standard implementations provides an interim solution to the schema
  92.    publishing problem.
  93.  
  94. 2. Schema Management
  95.  
  96.    The storage and retrieval mechanism provided by the directory is
  97.    powerful and flexible.  However, the key to the directory is the
  98.    knowledge of the schema rules defined for the objects represented in
  99.    the directory.  To facilitate the diffusion of this knowledge
  100.    appropriate schema management mechanisms need to be designed.  Schema
  101.    management involves:
  102.  
  103.         o Storage of schema information in the directory
  104.         o Algorithmic access to and retrieval of schema information
  105.           in the directory
  106.         o Definition of rules for schema modification
  107.         o Propagation of schema information from one component of the
  108.           directory to other components of directory
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Mansfield, et al              Experimental                      [Page 2]
  115.  
  116. RFC 1804          Schema Publishing in X.500 Directory         June 1995
  117.  
  118.  
  119.    In this document we concentrate on the aspect of schema
  120.    access/retrieval from the directory. Since schema objects are defined
  121.    and employed, the modification , addition and deletion of schema
  122.    objects can be carried out using existing directory mechanisms. But
  123.    the operational issue of synchronizing the schema with the DIB will
  124.    require further attention.  Similarly the issue of schema propagation
  125.    requires further work and is outside the scope of this document.  The
  126.    strategy proposed in this document has a very simple and workable
  127.    approach.  No added DAP/DSP functionality is envisaged. At the same
  128.    time by using the directory's distributed framework scalability
  129.    problems are avoided.  In essence, it allows the distributed storage
  130.    of schema objects and proposes a naming scheme which allows
  131.    algorithmic schema retrieval. Of course, on the down side, more than
  132.    one directory read operation may be required to retrieve the
  133.    information about an object and its attributes, as objects and
  134.    attributes are stored as separate entries in the directory.
  135.  
  136.    As schema information of all objects in a naming context are stored
  137.    below the root entry of that naming context, the same DSA will be
  138.    able to supply the schema information stored in that DSA. Thus there
  139.    is no need to contact another DSA for resolving the schema of an
  140.    object stored in the local DSA.
  141.  
  142. 3. Storage of Schema Information in the Directory
  143.  
  144.    The schema information may be stored and distributed using mechanisms
  145.    external to the X.500 directory standard [5]. This document proposes
  146.    storing schema information in the directory.  It has the following
  147.    advantages:
  148.  
  149.         o The components of the directory can access the schema
  150.           information using the standard directory protocols.
  151.  
  152.         o The nature of the directory naturally allows the schema
  153.           to be distributed. Schema used locally can be kept in the
  154.           local DSA itself whereas schema for general objects like
  155.           person, organization etc can be made available to all
  156.           components of the directory by publishing it.
  157.  
  158.    In the operational model, the schema information in the directory is
  159.    expected to complement the schema information held in central
  160.    repositories.
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Mansfield, et al              Experimental                      [Page 3]
  171.  
  172. RFC 1804          Schema Publishing in X.500 Directory         June 1995
  173.  
  174.  
  175. 3.1  Naming Scheme for the Schema
  176.  
  177.    The schema information is stored in a distributed manner.  We propose
  178.    a model in which each naming context stores the schema relevant to
  179.    it.
  180.  
  181.  
  182.                                 Root
  183.                                     \
  184.                                      \
  185.                         +-------------\----------------------+
  186.                         |            C=IN            DSA-1   |
  187.                         |          /      \                  |
  188.                         |         /        \                 |
  189.                         |        /          \                |
  190.                         |       /            \               |
  191.                         |      /          cn=subschema       |
  192.                         |     /           /  / | \ \ \       |
  193.                         |    /           /  /  |  \ \ \      |
  194.                         |   /          oid= oid=             |
  195.                         +--/---------------------------------+
  196.                           /
  197.   +----------------------/----------------------+
  198.   |                o=IIT, Madras      DSA-2     |
  199.   |                 /           \               |
  200.   |                /             \              |
  201.   |               /               \             |
  202.   |              /                 \            |
  203.   |         ou=CSE             cn=subschema     |
  204.   |         /    \             /   /| \ \ \     |
  205.   |        /      \           /   / |  \ \ \    |
  206.   |ipni=spark  cn=Rajeev oid=ipni  oid=         |
  207.   +---------------------------------------------+
  208.  
  209.          Figure 1: DIT with schema objects
  210.  
  211.  
  212.    To store the schema information, an object called subschema object is
  213.    defined. This object can come anywhere in the Directory Information
  214.    Tree (DIT). The subschema is defined as a subclass of Top.  The
  215.    subschema entry is stored below the root entry of a naming context.
  216.    The root entry of a naming context must contain a subschema subentry,
  217.    named {CN= Subschema}.  This standard naming methodology is necessary
  218.    so that the components of the directory can easily and
  219.    algorithmically locate the schema entries.  All schema information
  220.    relevant to that naming context is stored below the subschema entry.
  221.    Children of the subschema entry store information about objects,
  222.    attribute types, attribute syntaxes or matching rules. The DIT
  223.  
  224.  
  225.  
  226. Mansfield, et al              Experimental                      [Page 4]
  227.  
  228. RFC 1804          Schema Publishing in X.500 Directory         June 1995
  229.  
  230.  
  231.    structure for storing schema information is shown in Figure 1.
  232.    Schema for these objects are given in section 5.
  233.  
  234. 4. Retrieval of Schema from the Directory
  235.  
  236.    When an unknown object is encountered by any component of directory
  237.    during a directory operation, it proceeds the following way to
  238.    resolve the schema.
  239.  
  240.    The RDN component at the leaf-end of the name of the object whose
  241.    schema is to be resolved is replaced by the RDNs "oid=<object
  242.    identifier of the new object>, CN=subschema" and a read request is
  243.    initiated for the newly formed name.  If the entry is not found, two
  244.    RDN components from the leaf-end of the name of the object are
  245.    replaced by the RDNs "oid=<object identifier of the new object>,
  246.    CN=subschema" and another read is attempted. The process continues
  247.    until the read succeeds.  For example, while resolving the schema of
  248.    the object "IPNI=spark, OU=Department of Computer Science, O=Indian
  249.    Institute of Technology, Madras , C=IN", if the schema of the object
  250.    IPNI (IP Node Image) is not known to a component of the directory,
  251.    the following procedure will be adopted.
  252.  
  253.    Let the object id for the object IPNI be ipni.  The RDN "IPNI=spark"
  254.    is removed from the distinguished name of the entry and the RDNs
  255.    "oid=ipni, CN= Subschema" is appended.  The name thus formed is
  256.    "oid=ipni, CN=subschema, OU=Department of Computer Science, O=Indian
  257.    Institute of Technology, Madras, C=IN" A read request is initiated on
  258.    this name.  If the distinguished name "OU= Department of Computer
  259.    Science, O=Indian Institute of Technology, Madras, C=IN" is the
  260.    context prefix of a naming context, this read request will result in
  261.    the directory returning the schema for the object IPNI. If it is not,
  262.    the read operation will fail. In that case, a read operation is
  263.    initiated with distinguished name "oid=ipni, CN= subschema, O=Indian
  264.    Institute of Technology, Madras, C=IN". For the DIT structure shown
  265.    in Figure-1, this query will succeed and the schema information will
  266.    be returned.  The schema for the requested object will always be
  267.    located below the starting entry of the naming context in which the
  268.    entry is located.
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Mansfield, et al              Experimental                      [Page 5]
  283.  
  284. RFC 1804          Schema Publishing in X.500 Directory         June 1995
  285.  
  286.  
  287. 5. The Meta-Schema
  288.  
  289. experimental = 1.3.6.1.3
  290.  
  291. schema OBJECT IDENTIFIER
  292.         ::= {experimental 65}
  293.  
  294. schemaObjectClass OBJECT IDENTIFIER
  295.         ::= {schema.1}
  296.  
  297. schemaAttribute OBJECT IDENTIFIER
  298.         ::= {schema.2}
  299.  
  300. subschema OBJECT CLASS
  301.     Subclass of TOP
  302.         MUST CONTAIN {
  303.             commonName
  304.             - -  For naming
  305.         }
  306.         ::= {schemaObjectClass.1}
  307.  
  308. objectClass OBJECT CLASS
  309.     Subclass of TOP
  310.         MUST CONTAIN {
  311.             objectIdentifier
  312.                 - - This field stores the object identifier of object
  313.                 - - represented by an object class entry. This attribute
  314.                 - - is used for naming an object class entry.
  315.         }
  316.         MAY CONTAIN {
  317.             commonName,
  318.                  - - This field is used to store the name of the object
  319.             mandatoryNamingAttributes,
  320.             mandatoryAttributes,
  321.             optionalNamingAttibutes,
  322.             optionalAttributes,
  323.             obsolete,
  324.             description,
  325.             subClassOf
  326.         }
  327.         ::= {schemaObjectClass.2}
  328.  
  329. attributeType OBJECT CLASS
  330.     Subclass of Top
  331.         MUST CONTAIN {
  332.             objectIdentifier
  333.         }
  334.         MAY CONTAIN {
  335.  
  336.  
  337.  
  338. Mansfield, et al              Experimental                      [Page 6]
  339.  
  340. RFC 1804          Schema Publishing in X.500 Directory         June 1995
  341.  
  342.  
  343.              commonName,
  344.                 - - used to store the name of the attribute type
  345.              constraint,
  346.              attributeSyntax,
  347.              multivalued,
  348.              obsolete,
  349.              matchRules,
  350.              description
  351.         }
  352.         ::= {schemaObjectClass.3}
  353.  
  354. matchingRule OBJECT CLASS
  355.      Subclass of Top
  356.         MUST CONTAIN {
  357.              objectIdentifier
  358.         }
  359.          MAY CONTAIN {
  360.              commonName,
  361.              matchtype,
  362.              description,
  363.              obsolete
  364.         }
  365.         ::= {schemaObjectClass.4}
  366.  
  367. objectIdentifier ATTRIBUTE
  368.        WITH ATTRIBUTE-SYNTAX
  369.             objectIdentifierSyntax
  370.        ::= {schemaAttribute.1}
  371.  
  372. mandatoryNamingAttributes ATTRIBUTE
  373.        WITH ATTRIBUTE-SYNTAX
  374.             SET OF OBJECT IDENTIFIER
  375.        ::= {schemaAttribute.2}
  376.  
  377. mandatoryAttributes ATTRIBUTE
  378.        WITH ATTRIBUTE-SYNTAX
  379.             SET OF OBJECT IDENTIFIER
  380.        ::= {schemaAttribute.3}
  381.  
  382. optionalNamingAttibutes ATTRIBUTE
  383.        WITH ATTRIBUTE-SYNTAX
  384.             SET OF OBJECT IDENTIFIER
  385.        ::= {schemaAttribute.4}
  386.  
  387. optionalAttibutes ATTRIBUTE
  388.        WITH ATTRIBUTE-SYNTAX
  389.             SET OF OBJECT IDENTIFIER
  390.        ::= {schemaAttribute.5}
  391.  
  392.  
  393.  
  394. Mansfield, et al              Experimental                      [Page 7]
  395.  
  396. RFC 1804          Schema Publishing in X.500 Directory         June 1995
  397.  
  398.  
  399. obsolete ATTRIBUTE
  400.        WITH ATTRIBUTE-SYNTAX
  401.             BOOLEAN
  402.                            -- DEFAULT FALSE
  403.        ::= {schemaAttribute.6}
  404.  
  405. subClassOf      ATTRIBUTE
  406.         WITH ATTRIBUTE-SYNTAX
  407.                 SET OF OBJECT IDENTIFIER
  408.        ::= {schemaAttribute.7}
  409.  
  410. constraint ATTRIBUTE
  411.        WITH ATTRIBUTE-SYNTAX
  412.             Constraint
  413.        ::= {schemaAttribute.8}
  414.  
  415. Constraint ::=Choice {
  416.              StringConstraint,
  417.              IntegerConstraint
  418.         }
  419.  
  420. StringConstraint ::= SEQUENCE {
  421.              shortest INTEGER,
  422.              longest  INTEGER
  423.         }
  424.  
  425. IntegerConstraint ::= SEQUENCE {
  426.              lowerbound INTEGER,
  427.              upperbound INTEGER OPTIONAL
  428.         }
  429.  
  430. attributeSyntax ATTRIBUTE
  431.        WITH ATTRIBUTE-SYNTAX
  432.               ASN1DataType
  433.        ::= {schemaAttribute.9}
  434.  
  435. multivalued ATTRIBUTE
  436.        WITH ATTRIBUTE-SYNTAX
  437.             BOOLEAN             -- DEFAULT FALSE
  438.        ::= {schemaAttribute.10}
  439.  
  440. matchRules ATTRIBUTE
  441.        WITH ATTRIBUTE-SYNTAX
  442.             SET OF OBJECT IDENTIFIER
  443.        ::= {schemaAttribute.11}
  444.  
  445. matchtype ATTRIBUTE
  446.        WITH ATTRIBUTE-SYNTAX
  447.  
  448.  
  449.  
  450. Mansfield, et al              Experimental                      [Page 8]
  451.  
  452. RFC 1804          Schema Publishing in X.500 Directory         June 1995
  453.  
  454.  
  455.             INTEGER {
  456.              PRESENT                    (0),
  457.              EQUALITY                   (1),
  458.              ORDERING                   (2),
  459.              CASESENSITIVEMATCH         (3),
  460.              CASEINSENSITIVEMATCH       (4)
  461.             }
  462.        ::= {schemaAttribute.12}
  463.  
  464.  
  465. 6. References
  466.  
  467.    [1] CCITT. "Data Communication Networks: Directory", Recommendations
  468.        X.500 - X.521 1988.
  469.  
  470.    [2] CCITT. "Data Communication Networks: Directory", Recommendations
  471.        X.500 - X.525 1993.
  472.  
  473.    [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
  474.        RFC 1274, University College London, November 1991.
  475.  
  476.    [4] Howes, T., "Schema Information in the X.500 Directory", Work in
  477.        Progress, University of Michigan, July 1992.
  478.  
  479.    [5] Howes, T., Rossen, K., Sataluri, S., and R. Wright, "Procedures
  480.        for Formalization, Evolution, and Maintenance of the Internet
  481.        X.500 Directory Schema", Work in Progress, June 1995.
  482.  
  483. 7. Security Considerations
  484.  
  485.    Security issues are not discussed in this memo.
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Mansfield, et al              Experimental                      [Page 9]
  507.  
  508. RFC 1804          Schema Publishing in X.500 Directory         June 1995
  509.  
  510.  
  511. 8. Authors' Addresses
  512.  
  513.    Glenn Mansfield
  514.    AIC Systems Laboratories,
  515.    6-6-3, Minami Yoshinari, Aoba-Ku, Sendai,
  516.    Japan
  517.  
  518.    Phone: +81 (22) 279-3310
  519.    Fax: +81 (22) 279-3640
  520.    EMail: glenn@aic.co.jp
  521.  
  522.  
  523.    P. V. Rajeev
  524.    Hughes Software Systems,
  525.    2nd Floor, International Trade Tower,
  526.    Nehru Place, New Delhi,
  527.    India
  528.  
  529.    EMail: rajeev%hss@lando.hns.com
  530.  
  531.  
  532.    S. V. Raghavan
  533.    Department of Computer Science and Engineering,
  534.    Indian Institute of Technology, Madras 600 036,
  535.    India
  536.  
  537.    EMail: svr@iitm.ernet.in
  538.  
  539.  
  540.    Tim Howes
  541.    University of Michigan
  542.    ITD Research Systems
  543.    535 W William St.
  544.    Ann Arbor, MI 48103-4943, USA
  545.  
  546.    Phone: +1 (313) 747-4454
  547.    EMail: tim@umich.edu
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Mansfield, et al              Experimental                     [Page 10]
  563.  
  564.