RFC 1274 (rfc1274) - Page 2 of 60


The COSINE and Internet X



Alternative Format: Original Text Document



RFC 1274            COSINE and Internet X.500 Schema       November 1991


   currently underway.  In the U.S., the PSI White Pages Pilot [4] has
   stimulated use of X.500 on the Internet.  In Britain, the U.K.
   Academic Community Directory Pilot [5] is similarly promoting use of
   X.500.

2.  Motivation and aims of this document

   In a number of areas the X.500 standard only provides a basis for
   services.  One such area is the Directory's Schema or Naming
   Architecture.  The standard defines a number of useful object
   classes, in X.521, and attribute types, in X.520.  These are intended
   to be generally useful across a range of directory applications.
   However, while these standard definitions are a useful starting
   point, they are insufficient as a basis for a large scale pilot
   directory.

   While it is possible for directory administrators to define their own
   sets of additional attribute types and object classes, this is
   undesirable for some common attributes and objects.  The same objects
   and attribute types would be privately defined many times over.  This
   would result in the directory's generality being diminished as remote
   systems would be unable to determine the semantics of these privately
   defined data types.

   A number of useful additions to the standard definitions were made in
   this note's forerunner, "The THORN and RARE Naming Architecture" [2].
   These have been heavily used in early X.500 piloting activities.
   Furthermore, both the THORN and Quipu X.500 implementations have made
   use of these definitions.

   Since the afore-mentioned note was issued, a number of further
   requirements have come to light as the volume and variety of piloting
   activity has increased.  Yet further requirements seem likely as the
   scale of X.500 pilot services increases.  Thus, it is argued that it
   is not sufficient to merely reissue an updated version of the
   original note. The schema is a "living document" that needs
   procedures for:

      - Allowing submission of requests for new attributes and
        object classes to be added into the schema;

      - Allowing groups of object classes and attribute types
        defined elsewhere to be integrated into the schema.

      - Checking for the redundancy of any previously defined
        attribute types and object classes.

   This document attempts to establish procedures to allow for the



Barker & Kille