From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1804.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc1804.txt (limited to 'doc/rfc/rfc1804.txt') diff --git a/doc/rfc/rfc1804.txt b/doc/rfc/rfc1804.txt new file mode 100644 index 0000000..f4a72f3 --- /dev/null +++ b/doc/rfc/rfc1804.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group G. Mansfield +Request for Comments: 1804 AIC Laboratories +Category: Experimental P. Rajeev + Hughes Software Systems + S. Raghavan + Indian Institute of Technology, Madras + T. Howes + University of Michigan + June 1995 + + + Schema Publishing in X.500 Directory + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Abstract + + The X.500 directory provides a powerful mechanism for storing and + retrieving information about objects of interest. To interpret the + information stored in the directory, the schema must be known to all + the components of the directory. Presently, there are no means other + than ftp to distribute schema information across the Internet. This + is proving to be a severe constraint as the Directory is growing. + This document presents a solution to the schema distribution problem + using the existing mechanisms of the directory. A naming scheme for + naming schema objects and a meta-schema for storing schema objects is + presented. The procedures for fetching unknown schema from the + directory at runtime are described. + +Table of Contents + + 1. Introduction 2 + 2. Schema Management 2 + 3. Storage of Schema Information in the Directory 3 + 4. Retrieval of Schema from the Directory 5 + 5. The Meta-Schema 6 + 6. References 9 + 7. Security Considerations 9 + 8. Authors' Addresses 10 + + + + + + + +Mansfield, et al Experimental [Page 1] + +RFC 1804 Schema Publishing in X.500 Directory June 1995 + + +1. Introduction + + The X.500 Directory [1] is now used for a wide range of applications + from name/address lookup to network management, from restaurant + information to bibliographic information services. This information + is distributed and managed across a network of many autonomous sites. + In order to interpret the information stored in the directory, the + components of the directory must have knowledge about the structure + and representation (schema) of the information held within the + directory. + + The distributed nature of the network and the relatively slow process + of standardization have given rise to the challenging task of making + accessible the information about the schema rules themselves. A + mechanism for making the schema accessible to the functional + components of the directory is urgently required. + + The 1993 X.500 Directory Standard [2] has attempted to address the + problem of schema management and distribution. The 1993 framework + does provide the means for storing and retrieving schema information + in the directory. However, the resolution of unknown OIDs will + require both the DUA and the DSA to be compliant with [2]. + + In this document we propose a solution using the existing mechanisms + of the directory [1] itself. We present a naming scheme for naming + schema objects and a meta-schema for storing schema objects in the + directory. The proposal allows the algorithmic resolution of unknown + objects in the directory and in the absence of 1993 X.500 Directory + Standard implementations provides an interim solution to the schema + publishing problem. + +2. Schema Management + + The storage and retrieval mechanism provided by the directory is + powerful and flexible. However, the key to the directory is the + knowledge of the schema rules defined for the objects represented in + the directory. To facilitate the diffusion of this knowledge + appropriate schema management mechanisms need to be designed. Schema + management involves: + + o Storage of schema information in the directory + o Algorithmic access to and retrieval of schema information + in the directory + o Definition of rules for schema modification + o Propagation of schema information from one component of the + directory to other components of directory + + + + + +Mansfield, et al Experimental [Page 2] + +RFC 1804 Schema Publishing in X.500 Directory June 1995 + + + In this document we concentrate on the aspect of schema + access/retrieval from the directory. Since schema objects are defined + and employed, the modification , addition and deletion of schema + objects can be carried out using existing directory mechanisms. But + the operational issue of synchronizing the schema with the DIB will + require further attention. Similarly the issue of schema propagation + requires further work and is outside the scope of this document. The + strategy proposed in this document has a very simple and workable + approach. No added DAP/DSP functionality is envisaged. At the same + time by using the directory's distributed framework scalability + problems are avoided. In essence, it allows the distributed storage + of schema objects and proposes a naming scheme which allows + algorithmic schema retrieval. Of course, on the down side, more than + one directory read operation may be required to retrieve the + information about an object and its attributes, as objects and + attributes are stored as separate entries in the directory. + + As schema information of all objects in a naming context are stored + below the root entry of that naming context, the same DSA will be + able to supply the schema information stored in that DSA. Thus there + is no need to contact another DSA for resolving the schema of an + object stored in the local DSA. + +3. Storage of Schema Information in the Directory + + The schema information may be stored and distributed using mechanisms + external to the X.500 directory standard [5]. This document proposes + storing schema information in the directory. It has the following + advantages: + + o The components of the directory can access the schema + information using the standard directory protocols. + + o The nature of the directory naturally allows the schema + to be distributed. Schema used locally can be kept in the + local DSA itself whereas schema for general objects like + person, organization etc can be made available to all + components of the directory by publishing it. + + In the operational model, the schema information in the directory is + expected to complement the schema information held in central + repositories. + + + + + + + + + +Mansfield, et al Experimental [Page 3] + +RFC 1804 Schema Publishing in X.500 Directory June 1995 + + +3.1 Naming Scheme for the Schema + + The schema information is stored in a distributed manner. We propose + a model in which each naming context stores the schema relevant to + it. + + + Root + \ + \ + +-------------\----------------------+ + | C=IN DSA-1 | + | / \ | + | / \ | + | / \ | + | / \ | + | / cn=subschema | + | / / / | \ \ \ | + | / / / | \ \ \ | + | / oid= oid= | + +--/---------------------------------+ + / + +----------------------/----------------------+ + | o=IIT, Madras DSA-2 | + | / \ | + | / \ | + | / \ | + | / \ | + | ou=CSE cn=subschema | + | / \ / /| \ \ \ | + | / \ / / | \ \ \ | + |ipni=spark cn=Rajeev oid=ipni oid= | + +---------------------------------------------+ + + Figure 1: DIT with schema objects + + + To store the schema information, an object called subschema object is + defined. This object can come anywhere in the Directory Information + Tree (DIT). The subschema is defined as a subclass of Top. The + subschema entry is stored below the root entry of a naming context. + The root entry of a naming context must contain a subschema subentry, + named {CN= Subschema}. This standard naming methodology is necessary + so that the components of the directory can easily and + algorithmically locate the schema entries. All schema information + relevant to that naming context is stored below the subschema entry. + Children of the subschema entry store information about objects, + attribute types, attribute syntaxes or matching rules. The DIT + + + +Mansfield, et al Experimental [Page 4] + +RFC 1804 Schema Publishing in X.500 Directory June 1995 + + + structure for storing schema information is shown in Figure 1. + Schema for these objects are given in section 5. + +4. Retrieval of Schema from the Directory + + When an unknown object is encountered by any component of directory + during a directory operation, it proceeds the following way to + resolve the schema. + + The RDN component at the leaf-end of the name of the object whose + schema is to be resolved is replaced by the RDNs "oid=, CN=subschema" and a read request is + initiated for the newly formed name. If the entry is not found, two + RDN components from the leaf-end of the name of the object are + replaced by the RDNs "oid=, + CN=subschema" and another read is attempted. The process continues + until the read succeeds. For example, while resolving the schema of + the object "IPNI=spark, OU=Department of Computer Science, O=Indian + Institute of Technology, Madras , C=IN", if the schema of the object + IPNI (IP Node Image) is not known to a component of the directory, + the following procedure will be adopted. + + Let the object id for the object IPNI be ipni. The RDN "IPNI=spark" + is removed from the distinguished name of the entry and the RDNs + "oid=ipni, CN= Subschema" is appended. The name thus formed is + "oid=ipni, CN=subschema, OU=Department of Computer Science, O=Indian + Institute of Technology, Madras, C=IN" A read request is initiated on + this name. If the distinguished name "OU= Department of Computer + Science, O=Indian Institute of Technology, Madras, C=IN" is the + context prefix of a naming context, this read request will result in + the directory returning the schema for the object IPNI. If it is not, + the read operation will fail. In that case, a read operation is + initiated with distinguished name "oid=ipni, CN= subschema, O=Indian + Institute of Technology, Madras, C=IN". For the DIT structure shown + in Figure-1, this query will succeed and the schema information will + be returned. The schema for the requested object will always be + located below the starting entry of the naming context in which the + entry is located. + + + + + + + + + + + + + +Mansfield, et al Experimental [Page 5] + +RFC 1804 Schema Publishing in X.500 Directory June 1995 + + +5. The Meta-Schema + +experimental = 1.3.6.1.3 + +schema OBJECT IDENTIFIER + ::= {experimental 65} + +schemaObjectClass OBJECT IDENTIFIER + ::= {schema.1} + +schemaAttribute OBJECT IDENTIFIER + ::= {schema.2} + +subschema OBJECT CLASS + Subclass of TOP + MUST CONTAIN { + commonName + - - For naming + } + ::= {schemaObjectClass.1} + +objectClass OBJECT CLASS + Subclass of TOP + MUST CONTAIN { + objectIdentifier + - - This field stores the object identifier of object + - - represented by an object class entry. This attribute + - - is used for naming an object class entry. + } + MAY CONTAIN { + commonName, + - - This field is used to store the name of the object + mandatoryNamingAttributes, + mandatoryAttributes, + optionalNamingAttibutes, + optionalAttributes, + obsolete, + description, + subClassOf + } + ::= {schemaObjectClass.2} + +attributeType OBJECT CLASS + Subclass of Top + MUST CONTAIN { + objectIdentifier + } + MAY CONTAIN { + + + +Mansfield, et al Experimental [Page 6] + +RFC 1804 Schema Publishing in X.500 Directory June 1995 + + + commonName, + - - used to store the name of the attribute type + constraint, + attributeSyntax, + multivalued, + obsolete, + matchRules, + description + } + ::= {schemaObjectClass.3} + +matchingRule OBJECT CLASS + Subclass of Top + MUST CONTAIN { + objectIdentifier + } + MAY CONTAIN { + commonName, + matchtype, + description, + obsolete + } + ::= {schemaObjectClass.4} + +objectIdentifier ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + objectIdentifierSyntax + ::= {schemaAttribute.1} + +mandatoryNamingAttributes ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + SET OF OBJECT IDENTIFIER + ::= {schemaAttribute.2} + +mandatoryAttributes ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + SET OF OBJECT IDENTIFIER + ::= {schemaAttribute.3} + +optionalNamingAttibutes ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + SET OF OBJECT IDENTIFIER + ::= {schemaAttribute.4} + +optionalAttibutes ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + SET OF OBJECT IDENTIFIER + ::= {schemaAttribute.5} + + + +Mansfield, et al Experimental [Page 7] + +RFC 1804 Schema Publishing in X.500 Directory June 1995 + + +obsolete ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + BOOLEAN + -- DEFAULT FALSE + ::= {schemaAttribute.6} + +subClassOf ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + SET OF OBJECT IDENTIFIER + ::= {schemaAttribute.7} + +constraint ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + Constraint + ::= {schemaAttribute.8} + +Constraint ::=Choice { + StringConstraint, + IntegerConstraint + } + +StringConstraint ::= SEQUENCE { + shortest INTEGER, + longest INTEGER + } + +IntegerConstraint ::= SEQUENCE { + lowerbound INTEGER, + upperbound INTEGER OPTIONAL + } + +attributeSyntax ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + ASN1DataType + ::= {schemaAttribute.9} + +multivalued ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + BOOLEAN -- DEFAULT FALSE + ::= {schemaAttribute.10} + +matchRules ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + SET OF OBJECT IDENTIFIER + ::= {schemaAttribute.11} + +matchtype ATTRIBUTE + WITH ATTRIBUTE-SYNTAX + + + +Mansfield, et al Experimental [Page 8] + +RFC 1804 Schema Publishing in X.500 Directory June 1995 + + + INTEGER { + PRESENT (0), + EQUALITY (1), + ORDERING (2), + CASESENSITIVEMATCH (3), + CASEINSENSITIVEMATCH (4) + } + ::= {schemaAttribute.12} + + +6. References + + [1] CCITT. "Data Communication Networks: Directory", Recommendations + X.500 - X.521 1988. + + [2] CCITT. "Data Communication Networks: Directory", Recommendations + X.500 - X.525 1993. + + [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema", + RFC 1274, University College London, November 1991. + + [4] Howes, T., "Schema Information in the X.500 Directory", Work in + Progress, University of Michigan, July 1992. + + [5] Howes, T., Rossen, K., Sataluri, S., and R. Wright, "Procedures + for Formalization, Evolution, and Maintenance of the Internet + X.500 Directory Schema", Work in Progress, June 1995. + +7. Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + + + + + +Mansfield, et al Experimental [Page 9] + +RFC 1804 Schema Publishing in X.500 Directory June 1995 + + +8. Authors' Addresses + + Glenn Mansfield + AIC Systems Laboratories, + 6-6-3, Minami Yoshinari, Aoba-Ku, Sendai, + Japan + + Phone: +81 (22) 279-3310 + Fax: +81 (22) 279-3640 + EMail: glenn@aic.co.jp + + + P. V. Rajeev + Hughes Software Systems, + 2nd Floor, International Trade Tower, + Nehru Place, New Delhi, + India + + EMail: rajeev%hss@lando.hns.com + + + S. V. Raghavan + Department of Computer Science and Engineering, + Indian Institute of Technology, Madras 600 036, + India + + EMail: svr@iitm.ernet.in + + + Tim Howes + University of Michigan + ITD Research Systems + 535 W William St. + Ann Arbor, MI 48103-4943, USA + + Phone: +1 (313) 747-4454 + EMail: tim@umich.edu + + + + + + + + + + + + + + +Mansfield, et al Experimental [Page 10] + -- cgit v1.2.3