RE: Syntax OIDs, RFC2252

[Howard Chu <hyc@highlandsun.com>]

> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
>
> Howard Chu writes:
> > But the fact is that a client already needs to be able to resolve
> > strings down to their OIDs, when looking up attribute types and
> > objectclasses in a published schema. The mechanism to handle such a
> > lookup is already going to be in the client.
>
> Lots of clients don't.  I doubt they will, until the C API provides a
> convenient way to handle all this.  Then clients must be updated to take
> advantage of it.  That's work.  If you want them to handle syntax names
> as well, that's more work.
>
> Incidentally, has someone made a convenient API to handle all this, for
> X.500 or for LDAP?
>
I thought the LDAP service provider for JNDI already did some of this work.
But if you're saying most clients don't do this *today* it sounds like
you're saying "the published schema is useless because no existing clients
process published schema." ????

If it's work, big deal, it's work no matter what. But at least make it
worthwhile to do the work.

> > It makes no sense to make this a special case. Basically you've said
> > "everything has an OID. In every case, you can refer to a thing by its
> > string name instead of its numeric OID. Except this one case."
>
> It makes sense to me.  Syntaxes are different from object classes and
> attribibute types because a program can't apply a syntax unless it has
> built-in knowledge about it.  When the program *has* that knowledge of a
> syntax, it can translate to/from the syntax name internally.  In
> practice, that also makes most syntax handling independent of naming
> context.  So named syntaxes doen't add as much value as named object
> classes and attribute types.
>
A program can't apply matching rules without built-in knowledge either, and
yet they exist with both string names and numeric OIDs. In fact, matching
rules only have implementation relevance on a server, and yet they are
presented to the client as either numeric OIDs or as human-friendly string
names. I think this is an unjustified inconsistency in the specification.

And while we're on this point - true, completely unknown syntaxes don't add
much value. At the very least, the syntaxes attribute ought to have included
an (optional) "human-readable" flag. Essentially, if the information was
interesting enough to have been documented on paper (the table on page 8 of
RFC 2252), it ought to have been worth putting out on the wire. Either the
information is useful, and should be provided, or it's totally unimportant,
and should be completely deleted. I'm not asking for the latter!
  -- Howard
>

> BTW, this reminded me about a few other points in rfc2251; I'm not sure
> what is intended here:
>
> - paragraph 4.1.4: "If the server has a textual name for an attribute
>   type, it MUST use a textual name for attributes returned in search
>   results."
>   There is no similar requirement for object classes?
>
> - There doesn't seem to be any requirement that servers handle
>   searches for "2.5.4.0=2.5.20.1"      and "2.5.4.0=*" the same way as
>   searches for "objectClass=subschema" and "objectClass=*".
>   Nor "OBJECTCLASS=*", for that matter...
>   Actually a strict reading of paragraphs 3.2.2 and 3.4 doesn't even
>   seem to _allow_ them to be handled the same way:-)
>
> --
> Hallvard
>
>