The Normalize() API (slap_mr_normalize_func) receives a Syntax* pointing to the syntax per which it is normalizing. However, when used in conjunction with MRA filters, it might be useful to know what syntax the value that is being normalized conforms to, rather than for what syntax normalization is taking place.
Note that what syntax the normalizer is normalizing for is somehow already determined by the specific normalization function that is in use.
Also note that when the normalization of the asserted value occurs inside an MRA filter, the normalizer receives a pointer to the original syntax of the attribute rather than of the syntax it is normalizing for!
I think an easy solution would be to swap the behavior: pass the asserted syntax when normalizing the asserted value, and the attribute's syntax when normalizing the attribute value. A better solution would be to extend the API in order to pass both.
p.
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]
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[] ?
Emmanuel Lecharny wrote:
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 [RFC4122http://www.apps.ietf.org/rfc/rfc4122.html]
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[] ?
Unfortunately you snipped the following text right after what you've cited:
In LDAP, UUID values are encoded using the [ASCII] character string representation described in [RFC4122]. For example, "597ae2f6-16a6-1027-98f4-d28b5365dc14".
So for this particular syntax RFC 4530 defines a LDAP string representation. That's what's transferred over the wire.
Ciao, Michael.
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>]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[] ?
Could be an oversight. RFC4533 and the syncprov implementation were not always in sync with each other. (ironic...)
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
Kurt Zeilenga wrote:
On Aug 14, 2009, at 9:18 AM, Emmanuel Lecharny wrote:
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.
As far as I can see in our code and on the wire, we're using the binary format in the controls, exactly as RFC4533 states.
Kurt Zeilenga wrote:
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 [RFC4122RFC 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.
Ok, got it.
(Much like the LDAP encoding of an INTEGER typer is a character string representation.)
Well, UUID are not meant to be Human Readable, unless you have to register for a M$ product ;)
But this is about transferring attribute/assertion values of the UUID syntax, such as values of the entryUUID attribute.
Ok. I was confusing cookie UUID and entryUUID value. Cookies are transfered as byte[16], when entryUUID are considered as String.
Thanks for the clarification !
-
Emmanuel Lecharny -
Emmanuel Lécharny
-
Howard Chu -
Kurt Zeilenga -
masarati＠aero.polimi.it -
Michael Ströder