RE: Syntax OIDs, RFC2252

[Howard Chu <hyc@highlandsun.com>]

> Originally in X.500(88-93), attribute and object names names were
> OIDs, and
> syntaxes were strings.  This led to problems when schema writers
> would create
> new attributes through 'cut and paste' and sometimes not realize
> that their
> syntax strings were not valid or a poor model.

Yes, attribute and object names were OIDs, but everything was represented in
ASN.1, which allows macro-style substitution. So a schema writer could
declare
	foo objectidentifier ::= {1 976 123 4}
and then use "foo" from that point on instead of the numeric OID. Any ASN.1
compiler would find simple mistakes of the kind you mention.

I don't see how the LDAPv3 notation changes anything relevant to this
problem.
>
> Note in LDAPv3, unlike object class names, attribute types, and
> matching rule
> names, syntax names are not transferred over protocol except as subschema
> publication elements.  LDAPv3 subschema publication is intended
> for reasonably
> efficient client retrieval and processing.
>
That is a perfectly good goal.

> A client which is talking to a server for the first time and is
> going through
> the schema discovery process needs to determine which of the
> client's schema
> elements are supported by the server. For example, what attribute
> types are
> the same?  Now the client and server may both call an attribute "foo", but
> the client may have a different semantic meaning, so it needs to
> request and
> parse the attributeTypes element to compare the OIDs.
>
> What of the syntaxes?  A client may not know what the attribute
> "bar" (1.2.3.4)
> defined by a server means, but if it knows that it has syntax
> 1.3.6.1.4.1.1466.115.121.1.41 it perhaps could display it to a user, or
> reformat it for another protocol that deals with postal mail addressing.
>
> The use of string names for syntaxes rather than OIDs would raise
> the problem
> of name conflicts.  Since in LDAPv3 as defined in 2251-2256,
> there is no other
> information about a syntax provided to clients in subschema
> publication, there
> didn't seem to be any value to the clients of having another layer of
> indirection and require the client to sort through ldapSyntaxes
> values just to
> determine whether it knew a syntax for the "bar" attribute or not.
>
I'm not suggesting that string names should be used *instead* of OIDs.
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. The problem of name conflicts with syntaxes is no worse
than with attribute types and object classes - the problems are all the
same. 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." As far as
efficient client retrieval goes - the client still only has to retrieve a
single subentry. For efficient processing - it's more efficient to have a
single, consistently defined behavior, than to have a mostly-consistent
behavior with a special case.

Taking efficiency to the extreme, there shouldn't be any string names at
all, only numeric OIDs. But then LDAP would be human-unfriendly and no
better than straight DAP. In the interest of human-friendliness I think it
best to offer the *choice* - the ability to use string names if desired, the
same way the choice is available for the other protocol elements. I always
thought the fact that LDAP was string-oriented was one of its selling
points...

> Mark Wahl, Directory Product Architect
> Innosoft International, Inc.
>
>