Lack of multiple error codes

["Jim Sermersheim" <JIMSE@novell.com>]

When we talk about errors that may be returned for a particular operation, we impose a precedence to groups of errors (ala X.511). Name errors have higher precedence than Update errors, which are higher than Attribute errors, etc. Actually, X.511 terms what I'm calling a group of errors an error, and terms the more specific thing a problem. I'll stick with the terms "error groups" and errors.

Within a particular error group, there is no precedence. One of the lightweight aspects of LDAP is that only a single error code accompanies a result message. In X.511, you can return multiple attribute errors.

These facts lead me to believe that the most sane thing to do for LDAP, is to maintain the error precedence at the error group level, but to not impose any precedence below that. I say this for three reasons:

1) X.511 doesn't specify precedence below the "error group" level
2) Specifying a more granular precedence would likely be difficult, as any chosen order may only work well for certain operations
3) We begin to place an intolerable stranglehold on the implementation logic of LDAP servers.

Let's take a practical example: There is a test (BLITS) that tests the compare operation for noSuchAttribute. Unfortunately, the authors are not only comparing an attribute that is not part of the entry, but the asserted value is an invalid syntax. Thus, there are two attribute errors, but both can't be conveyed in LDAP, due to it allowing only a single error.

If we were to mandate error precedence in this case, we would begin to force implementors to all use the same logic as an operation is serviced. 

If we were to not mandate error precedence in this case, we would not be able to ensure a high degree of interoperability.

Which is the correct direction to follow? Again, I prefer to not mandate error precedence below the "error group".

Jim