Howard Chu wrote:
On the whole it doesn't seem like new syntaxes pop up in LDAP specs very often. Some may say this is because they're not really needed. I believe they've been sorely needed, and people have just avoided them because they required too much work to properly support in existing implementations. We can fix that.
This topic is somehwat interesting. I've banged my head against the wall several times when implementing schema support in web2ldap. The big question was where to draw the line between handling syntaxes and special attribute types, especially when having to override incorrect schema information retrieved from the server.
I have no strong opinion just some thoughts regarding how to dynamically make use of it at the client side:
Something like (an improved) slapo-constraint will cover most cases for which one might also consider a syntax, e.g. limited set of option values for implementing the typical select lists. Or a certain string format etc. AFAIK slapo-constraint shipped in RE24 only supports regex checking defined in slapd.conf. Dynamic option value/description lists could be easily defined by defining an LDAP URL which searches the option values. IIRC someone is already working in this direction to improve slapo-constraint. (A base class for this is in web2ldap's plugin API now). But currently the client cannot query the constraints and adjust the UI accordingly in a vendor independent way. The client could read cn=config if back-config is deployed though.
A separate syntaxes is only needed if there's a strong need for distinct matching rules or normalization etc. Also a client has to implement the syntax. IMO this is the reason for spec authors to avoid syntaxes.
So I'm thinking about whether it would be worth to extend the subschema declaration of attribute types to define additional constraints. A client could interpret this and act accordingly. Well, a long way to go through standardization off course...
Any thoughts?
Ciao, Michael.