RE: Syntax OIDs, RFC2252

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Howard Chu writes:

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

Thanks.  Will read.

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

No, I'm saying that it's wrong to say "client already needs to be able
to resolve strings down to their OIDs", and to enable namespace
collisions on this level gives us an unnecessary problem.

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

I quite agree:-)

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

Well, since LDAP was supposed to _simplify_ the ideas from X.500, it
does seem to be unnecessary complication to allow matching rule names to
be sent instead of OIDs over the protocol...

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

Yes, that would have been nice.  Still, 'human-readable' doesn't mean
'interesting for human users', which would be a lot more interesting -
but on attribute types, not on syntaxes.  Note that OIDs are 'human-
readable' in the table, for example.

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

Depends on who is the target audience of that piece of information.
It makes sense the way it is if it's mostly provided for implementors:
Whoever defines a syntax should of course describe it.  When someone
implements some other syntax, they'll put that information elsewhere.

-- 
Hallvard