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
