Re: Syntax OIDs, RFC2252

[Mark Wahl <M.Wahl@INNOSOFT.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.

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.

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.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.