> 7) preservation of user information
> http://www.openldap.org/lists/ietf-ldapbis/200301/msg00078.html
> A request was made to change the value preservation requirement
> to bit perfect. The current requirement is believed to be
> technically sound and is supported by consensus. No action.
I'd like to clarify that I did not intend to advocate bit perfect storage of values (unless this is required by the syntax definition).
I understand the server may need to transliterate value encodings for one reason or another. The current text in models allows a server to use the equality matching rule to validate that the new encoded value is equivalent to the original encoded value after transliteration.
My main concern is that the equality matching rule may not always be adequately strong enough for this purpose. An example of this problem is the caseIgnoreMatch matching rule. This would allow the server to change the case of string values. This changes more than just the encoding of the value - the abstract value is changed as well.
In this example, my belief is that the intent of choosing that equality matching rule was limited to comparison of value assertions (to identify duplicate values or searching for values) - but was not intended to allow the server to substitute "equivalent" values.
My original proposal was intended to modify the text to say that although value encodings may be modified, the abstract value itself cannot be changed. However, if there is a need to have text that tells a server how to validate values after transliterations, I suggest adding a table that identifies a suitable matching rule for each syntax (or role that into the syntax definition in which case the DirectoryString syntax text should be updated).
Chris.