ASID Working Group Glenn Mansfield
INTERNET DRAFT AIC Laboratories
draft-ietf-asid-schema-01.txt P.V. Rajeev
Hughes Software Systems
S. V. Raghavan
Indian Institute of Technology, Madras
Tim Howes
University of Michigan
March 1995
Schema Publishing in X.500 Directory
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
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
Expires: September 16,1995 ASID Working Group [Page 1]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
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.
Contents
========
1. Introduction 3
2. Schema Management 3
3. Storage of Schema Information in the Directory 4
4. Retrieval of Schema from the Directory 5
5. The Meta-Schema 6
6. References 11
7. Authors' Addresses 11
Expires: September 16,1995 ASID Working Group [Page 2]
INTERNET DRAFT Schema Publishing in X.500 Directory March 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. But, the DUA procedure for looking up an unknown object by
OID, has not been discussed.
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
Expires: September 16,1995 ASID Working Group [Page 3]
INTERNET DRAFT Schema Publishing in X.500 Directory March 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.
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.
Schema of objects which are commonly used will be stored in first
Expires: September 16,1995 ASID Working Group [Page 4]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
level DSAs and will be replicated to DSAs below. (This results in all
DSAs having a copy of the schema of objects that are commonly used.)
Schema defined in any naming context will be replicated to all
subordinate naming contexts. Thus a DSA at the lowest level will have a
replicated copy of schema stored in all its superior DSAs. Schema is
propagated to lower level DSAs, thus local schema will not be propagated
outside the naming context in which it is defined.
Expires: September 16,1995 ASID Working Group [Page 5]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
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 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.
Expires: September 16,1995 ASID Working Group [Page 6]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
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=<object identifier of the
new object>, 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=<object
identifier of the new object>, 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.
5. The Meta-Schema.
schema OBJECT IDENTIFIER
::= {experimental XX} -- XX will be assigned by IANA
schemaObjectClass OBJECT IDENTIFIER
::= {schema.1}
schemaAttribute OBJECT IDENTIFIER
::= {schema.2}
subschema OBJECT CLASS
Subclass of TOP
MUST CONTAIN {
commonName
- - For naming
}
::= {schemaObjectClass.1}
Expires: September 16,1995 ASID Working Group [Page 7]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
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 {
commonName,
- - used to store the name of the attribute type
constraint,
attributeSyntax,
multivalued,
obsolete,
matchRules,
description
}
::= {schemaObjectClass.3}
attributeSyntax OBJECT CLASS
Subclass of Top
MUST CONTAIN {
objectIdentifier
}
MAY CONTAIN {
commonName, - - Name of the attribute syntax
dataType,
Expires: September 16,1995 ASID Working Group [Page 8]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
description,
obsolete
}
::= {schemaObjectClass.4}
matchingRule OBJECT CLASS
Subclass of Top
MUST CONTAIN {
objectIdentifier
}
MAY CONTAIN {
commonName,
matchtype,
description,
obsolete
}
::= {schemaObjectClass.5}
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}
obsolete ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
BOOLEAN
-- DEFAULT FALSE
::= {schemaAttribute.6}
Expires: September 16,1995 ASID Working Group [Page 9]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
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
OBJECT IDENTIFIER
::= {schemaAttribute.9}
multivalued ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
BOOLEAN -- DEFAULT FALSE
::= {schemaAttribute.10}
matchRules ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
SET OF OBJECT IDENTIFIER
::= {schemaAttribute.11}
dataType ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
ASN1DataType
::= {schemaAttribute.12}
matchtype ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
Expires: September 16,1995 ASID Working Group [Page 10]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
INTEGER {
PRESENT (0),
EQUALITY (1),
ORDERING (2),
CASESENSITIVEMATCH (3),
CASEINSENSITIVEMATCH (4)
}
::= {schemaAttribute.13}
Expires: September 16,1995 ASID Working Group [Page 11]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
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., Kille, S., "The COSINE and Internet X.500 Schema",
RFC 1274, November 1991.
[4] Howes,T., "Schema Information in the X.500 Directory", Internet
Draft, University of Michigan, July 1992.
[5] Howes, T., Rossen, K., Sataluri, S., Wright, R., "Procedures for
Formalization, Evolution, and Maintenance of the Internet X.500
Directory Schema", work in progress, Internet-Draft,
draft-howes-x500-schema-00.txt, April, 1994.
7. 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
glenn@aic.co.jp
P. V. Rajeev
Hughes Software Systems,
2nd Floor, International Trade Tower,
Nehru Place, New Delhi,
India.
rajeev%hss@lando.hns.com
S. V. Raghavan
Department of Computer Science and Engineering,
Indian Institute of Technology, Madras 600 036,
India
svr@iitm.ernet.in
Tim Howes
University of Michigan
ITD Research Systems
535 W William St.
Ann Arbor, MI 48103-4943, USA
(313) 747-4454
tim@umich.edu
Expires: September 16,1995 ASID Working Group [Page 12]
INTERNET DRAFT Schema Publishing in X.500 Directory March 1995
Expires: September 16,1995 ASID Working Group [Page 13]
