Re: schema in the directory paper

[Andrew Waugh <[e-mail]>]

> I am not sure I really understand the purpose of this note.
> For me, one of the key reasons for representing schema information in the
> directory, is that a DUA/DSA can find out about attributes or
> objectclasses it does not have knowledege of locally.
> 
> For example, if a DUA reads an entry and gets the attribute type 
> "1.2.826.0.1004.0.2.1" how can it tell what the attribte value
> represents.  

It cannot. I am sure that CCITT were thinking that the schema would be
relatively fixed; so there would be no need for the DUAs to find out
schema information. Now, it appears that the schema will not be quite
so standardised after all...

Apart from the DUA receiving attributes it doesn't know how to process,
there is a real problem with indicating errors to the user. If, when you
are modifying an entry, you end up with an entry that violates the schema,
the DSA will refuse the modification. It won't tell you why it refused the
modification. Indeed, it cannot tell you, as the protocol makes no provision
for this information. An identical problem occurs if you try to add an entry
with an object class which violates the tree structuring rules.

> Section 5 of this paper says that without prior knowledge of which
> organisation assigned the schema, this info can not be found out.
> Why? The OID name space is hierarchical, and the OID tree below
> "1.2.826.0.1004" is assigned to X-Tel, so it would seem below X-Tel in
> the DIT is a good place to look for the schema definition.
> 
> I suggest that there needs to be mechanisim for finding out that
> "1.2.826.0.1004" belongs to "X-Tel", and this need to be the DIT
> itself.  There are a number of ways of doing this.  One of the
> simplest is to have an "OID tree", built from "Relative OID"
> components - roids, so you could look for
> roid=1 @ roid=2 @ roid=826 ...
> in the tree. There are others ways too.

An alternative is to put the schema information under the DMD entries.
The DSA which holds the DMD from which the entry came from must know the
schema of that DMD. (This what we did.) Another alternative is to associate
the schema information with the entry itself. The last seems to be the
approach taken by ISO and CCITT.

> Back to what the paper does cover.  With both the
> "internetAttributeTypes" and "internetObjectClasses" attributes, the
> OID assigned is buried in the syntax.  Using this approach all the
> schema details are held in one node.  IF is then difficult to find
> details of the oid "1.2.826.0.1004..." without reading the entire
> entry, and wading through the result.
> 
> I would like to suggest that the schema is held below a particular
> node, with a different entry for each object.
> One advantage of this is each entry can then have a seperate attribute
> type, containing the OID of the defined attribute.  Then I can do
> something like
> 	  search -filter oid=1.2.826...
> and find a definition of the object I am looking for.
> 
> Finally, a more wild idea, that I am not really suggesting you
> consider at this stage! But it would be really smart to have the ASN.1
> definition of attribute syntaxes in the directory.  Then using the
> "pepsy" ASN.1 compiler, a QUIPU syntax handler could be generated "on
> the fly" by a DUA, and the attribute value presented to the user in a
> user friendly way.  All we need is an ASN.1 definition of ASN.1 !?!

Jason Baragry and I had a go at putting Schema information into the directory
last Christmas. I hacked Dish to work with this schema information and Jason
hacked another DUA.

The hacked dish used the schema information quite extensively. It used it
to construct templates, check for object class violations (must/may contains),
check single valued/multi values, and check the lengths of values. It also
added the oid/syntax definitions to attrOIDTable[] so that (most of)
oidtable.at was redundant.

The dish worked fine (though I don't claim all the bugs were out :-). The
main problem was speed; it took a significant amount of time to retrieve
all of the information from the DSA.

I put the work aside when I realised that 1992 X.500 stored (some? all?) of
the schema information in entries or with the DMD. I intended to evaluate
the new stuff, but just haven't got back to it.

I've appended the Attributes and Object Classes at the end. Note, we didn't
put all of this information in the directory! We also didn't quite implement
it that way! The schema information is still under
@c=AU@o=CSIRO@ou=Directory Management Domain, if you are curious.

If you want more information, don't hesitate to holler.

andrew waugh




1. Definitions of Object Classes and Attribute Syntaxes

1.1 DIT Structure

The DIT Structure object class is used to represent the DIT structure
rules.

	scDITStructure OBJECT-CLASS
		SUBCLASS OF top
		MUST CONTAIN {
			commonName,
			scOid}
		MAY CONTAIN {
			description,
			seeAlso,
			scSubordinateOf,
			scNamedBy
		}
	::= {csiroObjectClass.2}

1.1 Object Class

The Object Class object class is used to define entries representing
the object class used by a DSA in a particular DMD.

	scObjectClass OBJECT-CLASS
		SUBCLASS OF top
		MUST CONTAIN {
			commonName,
			scOid}
		MAY CONTAIN {
			description,
			scSubclassOf,
			scMustContain,
			scMayContain
		}
	::= {csiroObjectClass.3}

1.2 Attribute Set

The Attribute Set object class is used to define entries representing
the attribute sets used by in object class definitions.

	scAttributeSet OBJECT-CLASS
		SUBCLASS OF top
		MUST CONTAIN {
			commonName,
			scOid}
		MAY CONTAIN {
			description,
			scMayContain,
		}
	::= {csiroObjectClass.4}

1.3 Attribute

The Attribute object class is used to define entries representing
the attributes known by a DSA.

	scAttribute OBJECT-CLASS
		SUBCLASS OF top
		MUST CONTAIN {
			commonName,
			scOid}
		MAY CONTAIN {
			description,
			scAttrSyntax,
			scMinRange,
			scMaxRange,
			scMultiValued,
			scMatches,
			scASN1defn
		}
	::= {csiroObjectClass.5}

1.4 Attribute Syntax

The Attribute Syntax object class is used to define entries representing
the attribute syntaxes known by a DSA.

	scAttribute OBJECT-CLASS
		SUBCLASS OF top
		MUST CONTAIN {
			commonName,
			scOid}
		MAY CONTAIN {
			description,
			scMatches,
			scASN1defn
		}
	::= {csiroObjectClass.6}

2.1 Schema Object Identifier

The Schema Object Identifier attribute gives the object identifier
associated with the schema element defined by the entry.

	scOid ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			objectIdentifierSyntax
	::= {csiroAttribute.10}

2.2 Schema Subclass Of

The Schema Subclass Of attribute contains the list of classes
which the object class is a subclass of.

	scSubclassOf ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			caseIgnoreStringSyntax
				(SIZE(1..ub-sc-subclass-of))
	::= {csiroAttribute.11}

2.3 Schema Must Contain

The Schema Must Contain attribute contains the list of attributes
which the object class must contain.

	scMustContain ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			caseIgnoreStringSyntax
				(SIZE(1..ub-sc-must-contain))
	::= {csiroAttribute.12}

2.4 Schema May Contain

The Schema May Contain attribute contains the list of attributes
which the object class may contain.

	scMayContain ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			caseIgnoreStringSyntax
				(SIZE(1..ub-sc-may-contain))
	::= {csiroAttribute.13}

2.5 Schema Attribute Syntax

The Schema Attribute Syntax attribute contains the oid of the attribute
syntax which this attribute is

	scAttrSyntax ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			objectIdentifierSyntax
	::= {csiroAttribute.14}

2.6 Schema Minimum Length

The Schema Minimum Length attribute contains the minimum length of
the attribute. If not present assumed to be 1.

	scMinLength ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			integerSyntax
	::= {csiroAttribute.15}

2.7 Schema Maximum Length

The Schema Maximum Length attribute contains the maximum length of
the attribute.

	scMaxLength ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			integerSyntax
	::= {csiroAttribute.16}

2.8 Schema Multivalued

The Schema Multivalued attribute indicates whether the attribute may
have multiple values. If not present, assumed to be TRUE.

	scMultiValued ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			booleanSyntax
	::= {csiroAttribute.17}

2.9 Schema Matches

The Schema Matches attribute contains the list of matching algorithms
which can be used to match against the attribute.

	scMatches ATTRIBUTE
		WITH ATTRIBUTE SYNTAX Matches
	::= {csiroAttribute.18}

	Matches ::= SET {
		Equality	[0]	BOOLEAN,
		Substrings	[1]	BOOLEAN,
		Ordering	[2]	BOOLEAN}

2.10 Schema ASN.1 Definition

The Schema ASN.1 Definition attribute contains the ASN.1 specification
of the attribute syntax.

	scASN1Defn ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			caseIgnoreStringSyntax
				(SIZE(1..ub-sc-asn1-defn))
	::= {csiroAttribute.19}

2.10 Schema Subordinate Of

The Schema Subordinate Of attribute names the types of entry which
the entry can be a subordinate of.

	scSubordinateOf ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			caseIgnoreStringSyntax
				(SIZE(1..ub-sc-sub-of-))
	::= {csiroAttribute.20}

2.10 Schema Named By

The Schema Named By attribute contains the list of attributes which
name this entry

	scNamedBy ATTRIBUTE
		WITH ATTRIBUTE SYNTAX
			caseIgnoreListSyntax
				(SIZE(1..ub-sc-asn1-defn))
	::= {csiroAttribute.21}