RE: Models: preservation of user information

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Surely no server which supports both LDAPv2 and LDAPv3 can come close to this?? The ASN.1 form you are talking about would presumably be the UTF-8 variant of directoryString which would have to be invented from the original LDAPv2 T.61?

Ron.

-----Original Message-----
From: Steven Legg [mailto:steven.legg@adacel.com.au]
Sent: Friday, 31 January 2003 15:22
To: 'Christopher Oliva'; ietf-ldapbis@OpenLDAP.org
Subject: RE: Models: preservation of user information



Chris,

Christopher Oliva wrote:
> Section 6.1 includes this paragraph:
>
>   Where such requirements have not be explicitly stated, servers SHOULD
>   preserve the value of user information but MAY return the value in a
>   different form.  And where a server is unable (or unwilling) to
>   preserve the value of user information, the server SHALL ensure that
>   an equivalent value (per Section 2.3) is returned.
>
> This would allow the server to return values that are not identical to
> the original values added by an application. Partly because sometimes,
> equality rules only determine equivalency instead of exact equality.
>
> I think this could lead to problems. For instance, name information for
> attributes with a caseIgnoreMatch equality matching rule might be returned
> in the wrong case which would actually be a loss of information for the
> application.
>
> I would prefer mandating servers to return the exact value that was
> originally added (when there are no explicit constraints in the schema
> definition for that item). Essentially this would be changing the above
> paragraph to:
>
>   Where such requirements have not been explicitly stated, servers MUST
>   preserve the value of user information (return the same values that
>   were originally added).

LDAP + X.500 servers cannot, in general, preserve the exact octet encoding
of attribute values presented in the LDAP-specific encoding. This is because
attribute values have to be re-encoded in BER for transfer between directory
servers. In theory, they aren't supposed to rely on preserving the exact BER
encoding of an attribute value either, but in practice they have to. The
strongest requirement that can be placed on X.500 directory servers is that
they preserve the abstract value (in the ASN.1 sense) of an attribute value,
regardless of the encoding in which it was originally presented. I consider
it desirable for directory servers to always preserve the abstract value,
though X.500 provides no guidance on this issue.

That fact that matching rules other than the equality matching rule for
an attribute can be applied to the attribute's values through an extensible
match is indicative of an expectation that attribute values should be
distinguishable at a deeper level than just equivalence according to the
attribute's equality matching rule. ASN.1 abstract value equivalence is
as deep as I'm able to go.

In ASN.1, two values of a string syntax that differ only in letter case
are regarded as different values. Likewise for two string values that
have different amounts of leading, trailing or separating white space.
Thus I consider it prudent for directory servers to preserve the exact
letter case and amount of white space in values of string syntaxes,
regardless of the equality matching rule for the attribute. However,
I can't point to a paragraph of any directory standard that requires this.

Regards,
Steven