Re: schema in the directory paper

[Tim Howes <[e-mail]>]

> From:    Colin Robbins <[e-mail]>
> To:      Tim Howes <[e-mail]>

> 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.

Your comments were brought up at the osi-ds meeting on Monday, and
there was general agreement that a second paper is needed to address
the "oid hierarchy in the dit" issue.  I agreed to make a first pass
at this.

> 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.

I think that if you come across one unknown oid defined by an
organization, then it's likely you will come across others.  Putting
them all together means you can get them all with a single read, which
will be more efficient if you need more than a few.  Of course, it
depends in part on how large the entire schema information is.  If it's
really huge I can see how this might be a problem.

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

An earlier version of the paper actually described a method of doing this.
I dropped it just to make things simpler.  The hard part is not
representing the ASN.1, but rather representing the matching rules
that go along with it.  We could just do the ASN.1 and forget about
the matching rules for now, or we could go for the whole thing.  Anybody
else have any thoughts on this?                               -- Tim