RE: Syntax OIDs, RFC2252

[Hallvard B Furuseth <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?

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


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