schema in the directory paper

[Tim Howes <[e-mail]>]

Sorry for the lateness...

At the last ietf I volunteered ("or maybe the others just stepped
back..." - Al Bundy) to write a paper on representing schema
information in the directory.  Here's a first draft.  Comments
appreciated.

Steve, can you find a few minutes on the agenda to discuss this on Monday?
    -- Tim


Network Working Group                                          Tim Howes
Request for Comments: DRAFT                       University of Michigan
                                                               July 1992


               Schema Information in the X.500 Directory


Status of this Memo

   The successful deployment of X.500 directory service on the  Internet
   depends  in  part  on the existence of a common information framework
   and common information schema within  that  framework.   The  current
   Internet  directory  pilot depends on file transfer to distribute the
   schema information needed  to  provide  this  information  framework.
   This  method is suboptimal, and will certainly break as the number of
   locally defined  schema  and  participating  sites  increases.   This
   Internet  Draft describes a method by which schema information can be
   stored in the directory, where it can be retrieved via X.500 by  DSAs
   and  DUAs  alike.  The method addresses both the meta-schema, used to
   store the information in the directory, and conventions  for  placing
   and naming the information in the directory.

1.    Introduction

   OSI Directory Service defines a powerful mechanism  for  storing  and
   retrieving information about objects, and for arranging those objects
   in a hierarchical structure.  Many types of objects  and  information
   can  be  stored  in The Directory, including white pages information,
   application information,  service  information,  etc.   In  order  to
   interpret  this  information  most effectively, Directory User Agents
   (DUA) and Directory System Agents (DSA) must have  knowledge  of  the
   attribute  types, attribute syntaxes, and object classes of which the
   information is comprised.  The current method  of  distributing  this
   knowledge  in  the Internet pilot is file transfer of a set of files,
   reflecting the contents of RFC 1274, "The COSINE and  Internet  X.500
   Schema"  [3].  This method is inefficient, not timely, does not scale
   well, and does not address  the  problem  of  locally-defined  schema
   distribution.

   This Internet Draft proposes a method of  storing  object  class  and
   attribute  type  information  in the X.500 directory, where it can be
   retrieved in a timely and efficient fashion by DUAs and  DSAs  alike.
   It  should  be  noted  that the 1992 version of the X.500 standard is
   expected to address this problem only in a  local  sense  (within  an
   administrative  area).   It  does  not  address the problem of global
   schema administration.  The method proposed here is believed to be  a
   subset  of  that  proposed by the 1992 standard, with the addition of



Howes                                                           [Page 1]

RFC DRAFT                                                      June 1992


   naming and organization conventions.

2.    Overview

   Schema information includes the definition  of  attribute  types  and
   attribute  syntaxes,  which  define  the type and acceptable values a
   particular piece of information may have; and object  classes,  which
   specify which attributes an entry must and may contain.  The proposal
   described here allows for representing object classes and  attributes
   in  The  Directory.   The representation of attribute syntaxes is not
   discussed here and is for further study.

   To make these definitions useful, we also  propose  some  conventions
   for where this information should be stored in The Directory, and how
   it should be named and accessed.  By standardizing these conventions,
   user agents will be able to take advantage of the information without
   human intervention.

3.    Subschema Information Object Model

   One new object class and two new attribute types are defined to  hold
   schema information.  The definitions for the internetSubschema object
   class and its associated attribute types are as follows.

           internetSubschema OBJECT CLASS
               SUBCLASS OF top
               MUST CONTAIN {
                   commonName    -- for naming
               }
               MAY CONTAIN {
                   internetObjectClasses,
                   internetAttributeTypes
               }
           ::= { }

           internetAttributeTypes ATTRIBUTE
               WITH ATTRIBUTE-SYNTAX
                   SEQUENCE {
                       identifier  [0] OBJECT IDENTIFIER,
                       name        [1] CaseIgnoreString,
                       description [2] CaseIgnoreIA5String OPTIONAL,
                       information [3] InternetAttributeTypeDescription
                   }
           ::= { }

           InternetAttributeTypeDescription :: = SEQUENCE {
               attributeSyntax [2] OBJECT IDENTIFIER,
               constraint      [3] Constraint OPTIONAL,



Howes                                                           [Page 2]

RFC DRAFT                                                      June 1992


               multi-valued    [3] BOOLEAN DEFAULT TRUE
           }

           Constraint ::= CHOICE {
               stringConstraint  [0] SizeConstraint,
               integerConstraint [1] Range
           }

           SizeConstraint ::= SEQUENCE {
               shortest INTEGER,
               longest  INTEGER OPTIONAL
           }

           Range ::= SEQUENCE {
               lowerBound INTEGER,
               upperBound INTEGER
           }

           internetObjectClasses ATTRIBUTE
               WITH ATTRIBUTE-SYNTAX
                   SEQUENCE {
                       identifier  [0] OBJECT IDENTIFIER,
                       name        [1] CaseIgnoreString,
                       description [2] CaseIgnoreIA5String OPTIONAL,
                       information [3] InternetObjectClassDescription
                   }
           ::= { }

           InternetObjectClassDescription :: = SEQUENCE {
               subclassOf              SET OF OBJECT IDENTIFIER,
               kind                    ENUMERATED {
                                           abstract   (1),
                                           alias      (2),
                                           structural (3),
                                           auxiliary  (4)
                                      },
               mandatoryAttributes [1] SET OF OBJECT IDENTIFIER OPTIONAL,
               optionalAttributes  [2] SET OF OBJECT IDENTIFIER OPTIONAL
           }

   It is  assumed  that  when  attribute  syntaxes  are  added  to  this
   information,  a  new  attribute type will be created and added to the
   internetSubschema objectclass.  The form of  this  attribute  is  for
   further study.







Howes                                                           [Page 3]

RFC DRAFT                                                      June 1992


4.    Naming and DIT Organization

   In order for  this  information  to  be  useful,  it  must  be  named
   consistently  throughout  the DIT so DUAs can access it without human
   intervention.  We propose that subschema entries be placed in the DIT
   as  children  of  the  organization, country, or other administrative
   boundary entry responsible for the schema,  and  that  the  subschema
   entry  be  named  as "cn=Subschema".  So, for example, the schema for
   the US pilot would be found in the DIT  entry  <cn=Subschema,  c=US>.
   Similarly,  subschema  defined by the University of Michigan would be
   held in the entry <cn=Subschema, o=University of Michigan, c=US>.  In
   this  scheme, every country participating in the Internet pilot would
   maintain subschema entry directly below the entry  for  its  country.
   Consistency  among these entries could be maintained using aliases or
   replication.

5.     Subschema Access

   Unfortunately, without any a priori knowledge of which  organizations
   or  countries  have  defined a subschema, a DUA has no way of knowing
   under which entries to look for  a  cn=Subschema  entry.   And  since
   subschema  may nest in the DIT (for example, the US and University of
   Michigan case cited above), there is no way for a DUA to  know  which
   subschema  entry  holds  the  information it needs.  However, given a
   particular entry in the DIT containing an attribute  type  or  object
   class  unknown to a DUA, the DUA can always "crawl" back up the tree,
   testing each level for subschema entries as it  goes.   This  method,
   though  not the most efficient, is algorithmic and should not have to
   be performed very often, especially if the DUA caches the results.

6.    References

   [1] Information Processing - Open Systems Interconnection - The
       Directory, International Organization for Standardization.
       International Standard 9594, (1988).

   [2] Information Processing - Open Systems Interconnection - The
       Directory, International Organization for Standardization.
       International Standard Draft PDAM 2.2 9594-2, (1991).

   [3] Barker, P., Kille, S., "The COSINE and Internet X.500 Schema",
       RFC 1274, November 1991.

7.    Security Considerations

   Security considerations are not discussed in this memo.





Howes                                                           [Page 4]

RFC DRAFT                                                      June 1992


8.    Author's Address

   Tim Howes
   University of Michigan
   Information Technology Division
   535 West William St.
   Ann Arbor, MI 48103-4943

   Phone: [phone]
   EMail: [e-mail]









































Howes                                                           [Page 5]