Re: schema in the directory paper

[Colin Robbins <[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.  

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.

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 !?!



Colin

PS If anybody reads mail just before the meeting today, please take a
copy of this along.  I can't be there, but hope the paper is going to
be discussed.   Have a good meeting!