Ron,
Ramsay, Ron wrote:
> 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?
Huh? If a value of an attribute with the Directory String syntax
is presented to our server in LDAPv2 as T.61 then we preserve it
in the teletexString alternative of the DirectoryString{} ASN.1 type.
It gets transferred to other DSAs in this same encoding.
If a value of an attribute with the Directory String syntax is
presented to our server in LDAPv3 then we have to choose an
alternative of the DirectoryString CHOICE, but having chosen,
the value always gets transferred to other DSAs as that alternative
and encoding. Thus we are preserving the abstract value in both
cases as far as ASN.1 is concerned. When a DirectoryString{} value
is encoded for an LDAP result we transliterate as required and the
LDAP user sees exactly the octets they put in.
Regards.
Steven
>
> 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
>
>
>
> <<attachment: winmail.dat>>