rfc1274.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 2,076 行 · 第 1/5 页

Network Working Group                                          P. Barker
Request for Comments: 1274                                      S. Kille
                                               University College London
                                                           November 1991


                  The COSINE and Internet X.500 Schema

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This document suggests an X.500 Directory Schema, or Naming
   Architecture, for use in the COSINE and Internet X.500 pilots.  The
   schema is independent of any specific implementation.  As well as
   indicating support for the standard object classes and attributes, a
   large number of generally useful object classes and attributes are
   also defined.  An appendix to this document includes a machine
   processable version of the schema.

   This document also proposes a mechanism for allowing the schema to
   evolve in line with emerging requirements.  Proformas to support this
   process are included.

   Corrections and additions to the schema should be sent to na-
   [e-mail] list, as described within.

1.  Introduction

   Directory Services are a fundamental requirement of both human and
   computer communications' systems.  Human users need to be able to
   look up various details about other people: for example, telephone
   numbers, facsimile numbers and paper mail addresses.  Computing
   systems also need Directory Services for several purposes: for
   example, to support address look-ups for a variety of services, and
   to support user-friendly naming and distribution lists in electronic
   mail systems.

   Directory Services have recently been standardised and published as
   the 1988 CCITT X.500 / ISO IS9594 recommendations [1].  The standard
   provides a good basis for the provision of real services, and a
   considerable amount of Directory Service piloting activity is



Barker & Kille                                                  [Page 1]

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                                                  [Page 2]

RFC 1274            COSINE and Internet X.500 Schema       November 1991


   continual updating of the schema.  Two proformas are set out for this
   purpose.  In addition, descriptive detail is provided for the
   additional object classes and attribute types defined in the schema.
   These descriptions follow the style used in X.520 and X.521.
   Finally, also following the style adopted in the standards documents,
   appendices will include the entire schema.  Plain text versions of
   the document's appendices are intended to be machine processable to
   allow derivation of a system's schema tables.  Appendix C lists all
   the schema's object classes and attribute types in their respective
   ASN.1 macro formats.

   The scope and intended remit of this coordination activity should be
   clearly understood.

      - Esoteric and local, highly experimental requirements  should
        continue to be met by private definitions.

      - Requirements which have support from more than one site will
        usually be integrated into the schema.  Put in other words,
        the tendency will be for the inclusion, as opposed to the
        exclusion, of useful additions to the schema.

      - An attempt will be made to avoid duplication of object
        classes and attribute types for essentially similar real
        world objects.

3.  What conformance to this schema means

   It is not reasonable to require that a DSA which supports this schema
   has specific code to handle each of the defined syntaxes.  However,
   the following requirements are made of a system which claims
   conformance to this specification:

      1. A DSA shall be able to store all of the attributes and
         object class values specified.  (Note that this implies
         support for all the object classes and attribute types
         required by strong authentication as defined in X.509.)

      2. A DUA shall be able to identify each attribute type and
         object class to the user, with an appropriate representation
         (e.g., a string).

      3. These statement are qualified for large attributes values
         (>1kbyte).  A conforming DSA does not have to store such
         attribute values, and a DUA does not have to display such
         values, although it must indicate their presence.

   The following are desirable, but not required:



Barker & Kille                                                  [Page 3]

RFC 1274            COSINE and Internet X.500 Schema       November 1991


      1. For a DSA to match correctly on the basis of all attribute
         syntaxes defined

      2. For a DSA to enforce the Object Class schema implied by
         these definitions

      3. For a DUA to correctly display the attribute values
         (syntaxes) defined

      4. For DUAs and DSAs to maintain compatibility with a previous
         version of the schema.

4.  Requesting new object classes and attribute types

   This section defines procedures for requesting new object classes and
   attribute types to be added to the schema.  Proformas for object
   classes and attribute types are specified, and examples given of how
   to use them.  A mechanism for making requests for large groups of new
   object classes and attribute types is described in the next section.

   As stated earlier, it is anticipated that the schema will evolve
   considerably over time.  As X.500 is used to support a widening range
   of applications, there will be requirements for extensions to the
   schema.  This document proposes formalising this procedure by
   requiring requests for additions to the schema to be submitted as
   completed proformas.  This stipulation will greatly simplify
   subsequent revisions of the schema.

   There is one qualification to the above with respect to requests for
   modifications to an existing object class.  If a modification to an
   object class merely involves additional, optional attributes, the
   object class will be enhanced as requested.  Systems are expected to
   be resilient to such changes to the schema.  However, requests to
   modify an object class, such that the mandatory attribute types
   require altering, will not be met.  Instead, a new object class will
   be created, and the original object class expired following the
   scheme described in the next main section.

   It is anticipated that most requests for modifications to the schema
   will be met without any need for editorial intervention.  Sometimes,
   however, some discussion between the submitter of a request and the
   schema's editor may be required.  For example, the editor may have to
   judge the relative merits of two very similar requests and, as a
   result, one of the parties may not get quite what they want.  In
   cases such as this where the submitter of a request feels aggrieved
   about an editorial decision, the requestor may appeal to a broader
   community by explaining their views to the mailing list osi-
   [e-mail].  Heed will be paid to any consensus that emerges



Barker & Kille                                                  [Page 4]

RFC 1274            COSINE and Internet X.500 Schema       November 1991


   from discussions on the schema on this list.  If it proves that this
   list is used almost solely for discussions on schema issues, a
   separate discussion list will be created.

   To facilitate the production of the afore-mentioned proformas, tools
   are included in Appendix B which will verify that a proforma has been
   correctly formatted.

   Completed proformas should be mailed to [e-mail]

4.1.  Object Class proforma

   This section gives an example, completed proforma for a new object
   class, alcoholic drink.  A proforma for object class specified in BNF
   is included in Appendix A.

     Object Class: Alcoholic Drink

     Description: The Alcoholic Drink object class is used to define
     entries representing intoxicating beverages.

     ASN1OCMacro: alcoholicDrink OBJECT-CLASS
         SUBCLASS OF drink
         MUST CONTAIN {
             percentAlcohol}
         MAY CONTAIN {
             normalServing,
             hue}

   An object class description consists of three fields, separated by
   blank lines.  The keywords Object Class, Description and ASN1OCMacro,
   and their suffixed colons, must be included exactly as above.

   The Object Class field should be used for a textual description of
   the object class.  This will be at most three or four words.

   The Description field should contain some explanatory text about the
   intended use of the object class.  This can run to a number of lines.

   The ASN1OCMacro field should follow the definition of the object
   class macro as specified in X.501.  The above example shows the main
   features.  There are many more examples which can studied in the
   section defining the Pilot Object Classes.

4.2.  Attribute type proforma

   This section gives an example completed proforma for a new attribute
   type, hue (one of the attribute types in the alcoholic drink object



Barker & Kille                                                  [Page 5]

RFC 1274            COSINE and Internet X.500 Schema       November 1991


   class).

     Attribute Type: Hue

     Description: The Hue attribute type specifies the hue of
     an object.  (Note that a description may run to several
     lines.)

     OCMust:

     OCMay: alcoholicDrink

     ASN1ATMacro:hue ATTRIBUTE
         WITH ATTRIBUTE SYNTAX
             caseIgnoreStringSyntax
             (SIZE (1 .. ub-hue))

     ub-hue INTEGER ::= 256

   An attribute type description consists of five fields, separated by
   blank lines.  The keywords Attribute Type, Description, OCMust, OCMay
   and ASN1ATMacro, and their suffixed colons, must be included exactly
   as above.

   The Attribute Type field should be used for a textual description of
   the attribute type.  This will be at most three or four words.

   The Description field should contain some explanatory text about the
   intended use of the attribute type.  This can run to a number of
   lines.

   The OCMust field should contain a comma-separated list of object
   classes for which this attribute is mandatory.

   The OCMay field should contain a comma-separated list of object
   classes for which this attribute is optional.

   The ASN1ATMacro field should follow the definition of the attribute
   macro as specified in X.501. The above example shows some of the
   features.  In particular, please note the format for specifying size
   constraints.

5.  Integrating groups of object classes and attribute types.

   This section describes two mechanisms that may be employed to allow
   the integration of a substantial number of new object classes and
   attribute types into the schema.




Barker & Kille                                                  [Page 6]

RFC 1274            COSINE and Internet X.500 Schema       November 1991


   The first mechanism allows for the transition of groups of related,
   privately defined object classes and attribute types into the schema.
   An example of when such a transition might be appropriate is when
   some experimental use of the Directory is widely adopted within the
   pilot.  Such a transition will be made if the following conditions
   hold:

      - The definitions are well structured: i.e., they are not
        scattered over a multiplicity of object identifier subtrees.

      - The definitions are in use at a number of sites, and having
        to adopt new object identifiers would be unnecessarily
        disruptive.

   A second mechanism allows for the allocation of an object subtree for
   a group of new definitions.  A pilotGroups object identifier has been
   defined for this purpose.  This method will be suitable for an
   experiment requiring a considerable number of new object identifiers
   to be defined.  This approach allows for flexibility during
   experimentation and should simplify both the management and the
   coherence of the pilot's object identifiers.

   In both cases, the object classes, attribute types and syntaxes
   should be defined and described in an RFC.  It is suggested that such
   documents should follow the style used in this document for object
   class and attribute type definitions.  A reference will be given in
   this schema to the document containing the definitions.

6.  Removing "old" object classes and attribute types.

   It is also important that object classes and attribute types which
   are no longer used or useful are removed from the schema.  Some
   object classes and attribute types initially defined as pilot
   extensions may be included as standard definitions in future versions
   of the standard.  In such a case, it is important that there should
   be a fairly rapid transition to the standard definitions.  Another
   possibility is that newer, more specific definitions obviate the
   original definitions.

   Two things are essential.  First, it is crucial that "old"
   definitions are retired as gracefully as possible.  The intention to
   retire a definition will be sent to the [e-mail] mail
   list.  In the absence of objections, the definition will be marked
   for expiry with a given expiry date.  The definition will remain in
   the schema until the expiry date.  Users of the schema should ensure
   that they make the transition to new, alternative definitions in the
   interim.




Barker & Kille                                                  [Page 7]

RFC 1274            COSINE and Internet X.500 Schema       November 1991


   Second, users of the schema must have the right to argue for the
   retention of definitions which they regard as necessary, there being
   no other definitions which closely meet their requirements.  It is
   clearly impossible to lay down hard and fast rules on this point, as
   no two instances will ever be quite the same.  It is intended that
   the refereeing on these matters will be sympathetic!  As for requests
   for additions, an aggrieved user can "go to arbitration" by
   initiating a discussion on the [e-mail] mail list.

7.  Object Identifiers

   Some additional object identifiers are defined for this schema.
   These are also reproduced in Appendix C.

     data OBJECT IDENTIFIER ::= {ccitt 9}
     pss OBJECT IDENTIFIER ::= {data 2342}
     ucl OBJECT IDENTIFIER ::= {pss 19200300}
     pilot OBJECT IDENTIFIER ::= {ucl 100}