Team, Before I enter put a bug report in the issue tracker I wanted to verify that my interpretation of the LDAP API client is correct. We've got several systems which manage the entries stored into our LDAP servers. When entries are created, users should generally have at least one mail attribute that is not a @psu.edu address and may also have exactly one @psu.edu address depending on what type of account it is.
For those seeking employment here and for the very large population of those applying to attend university here, we might have several external email addresses by the time the LDAP account creation happens. For the most part, the system works exactly as planned but in some cases we're creating entries using the client that are failing to be created on the server. Mail in this case is the most common type of error but is an example of other attributes that might exhibit the same behavior. If an identity (entry) contains mail addresses such as [email protected] and [email protected], the client still accepts that I've added to different mail attributes. When the entry is submitted to the server it fails because the server does not allow duplicates and the matching rules are: Equality match: caseIgnoreIA5Match Substring match: caseIgnoreIA5SubstringsMatch Clearly it would be possible to iterate over the attributes in the code using the client API and eliminate duplicates but it feels like this is a common problem and that the better place to enforce the server's syntax is in the Apache LDAP API. I'm posting this to the mailing list first because it's entirely possible we're missing something in how we're using the API. If not, is there interest in enhancing the LDAP API to enforce the (presumably attached) server's syntax rules or should we just patch the code where we encounter problems and move on. Thanks, Steve
