Re: ASN1 - syncInfoValue

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:16 AM 3/16/2005, Lee Jensen wrote:
>It also raises another one however. Essentially I am trying to make a
>client that will track changes and do synchronization operations to
>other systems when LDAP is updated. In order to do this it's becomming
>apparent that I will need to store at least UUIDs and some other data.
>Does it matter how I store the UUIDs, whether as 16-octet syncUUIDs or
>as entryUUIDs? If the RFC I mentioned in my last e-mail is not correct
>as to how to translate the 16 octet syncUUID into an entryUUID would you
>mind pointing me somewhere? Perhaps even to a function in the LDAP
>source. 

It matters not how you store UUIDs, what matters how you
compare UUIDs.  Don't directly compare UUID strings as
there are multiple possible strings representing each
UUID.  Either make the matching routine sensitive to
this, or convert to 16-octet values (or other canonical
form) for direct comparison.

Note that this applies not just to UUIDs, but to many things
in LDAP.  For instance, you shouldn't compare directly
the generalized time strings [RFC2252] "199412161032Z" and
"199412161032+0000".  One either convert both to time value
represented, or make the string matching function sensitive
to variations allowed in the string representation.  That is,
semantically, the implementation is to match abstract
values not representations of abstract values.

In OpenLDAP, we convert all values (regardless of syntax)
to some normalized formed to allow direct comparison, and
store these (so we don't have to repeatedly do this conversion).
But as we generally want to preserve the representation
provided by the user, we also store solely so that we can
return it to the user when subsequently requested.

Kurt