On Aug 14, 2009, at 9:18 AM, Emmanuel Lecharny wrote:
Hi guys,
a short question about the way OpenLDAP (last version) exposes the entryUUID during replication. UUID is supposed to be binary :
RFC 4530 :
*2.1 UUID Syntax*
A Universally Unique Identifier (UUID) [RFC4122 http://www.apps.ietf.org/rfc/rfc4122.html] is a 16-octet (128- bit) value that identifies an object. The ASN.1 [X.680] type UUID is defined to represent UUIDs as follows:
UUID ::= OCTET STRING (SIZE(16)) -- constrained to an UUID [RFC4122 <http://www.apps.ietf.org/rfc/rfc4122.html]
RFC 4530 then says:
In LDAP, UUID values are encoded using the [ASCII] character string representation described in [RFC4122]. For example, "597ae2f6-16a6-1027-98f4-d28b5365dc14".
That is, the LDAP encoding of the UUID type is the [ASCII] character string representation. (Much like the LDAP encoding of an INTEGER typer is a character string representation.)
But this is about transferring attribute/assertion values of the UUID syntax, such as values of the entryUUID attribute.
When the UUID is transfered in the Syncrepl cookies, it's as a String, not as a byte[] (with a format like xxx-yyyy-zzzz, kindof). Is there any reason not to transfer the UUID as a byte[] ?
Syncrepl is built upon LDAP Content Sync, RFC 4533, carries syncUUID values in entryUUID fields. This field ought to be transferred as 16- type long OCTET STRING. The string representation discussed in RFC 4530 is not applicable. That is, the on the wire encoding of a entryUUID field in LDAP sync is not the same as the encoding of the entryUUID attribute.
When LDAP sync was originally implemented, this is the way it was (IIRC). If the RFC 4533 LDAP string encoding, or other string encoding, is being used, I would consider it to be a bug.
-- Kurt