RE: LCUP Issue: UUID

John,

John McMeeking wrote:
> I think that some reasonable uses of the attribute warrant a string
> representation.  For example, an application may want to search for an
> entry with a specific entryuuid.  And some LDUP conflict resolution
> procedures call for renaming an entry to have a DN like 
> "cn=some value +
> entryuuid=xxxx".  Constructing such search filters and DNs is 
> much cleaner
> if entryuuid has a string syntax.

I agree.

> Granted, a well-written application
> should be able to construct search filters and DNs containing binary
> values.  Case ignore match may be too restrictive.

The allComponentsMatch matching rule, already referenced by URP,
performs a character by character code-point comparison when applied
to a string type (there are some caveats on DirectoryString).
This avoids all the letter case, white-space and other normalization
that comes with caseIgnoreMatch and caseExactMatch.

> Certainly, there is no
> reason why an application can't use the entry uuid in the 
> case provided by
> the originating server.
> 
> That aside, don't we have to define what an entry uuid looks 
> like?

Yes.

> A maximum size would probably be helpful to 
> server vendors so
> as to not have to provide a search and storage mechanism (DB table for
> example) that has to support arbirary length values generated by other
> servers.

Speaking as a vendor, I already support arbitrary length attribute values.
A maximum size for entry uuids would be an irritation rather than an
advantage to me.

> Just to get things started, I propose that we use the DCE 
> UUID algorithms,
> which have a well defined string representation.  And we 
> should be able to
> define a entryuuid syntax with a string representation, which 
> is probably a
> bit cleaner than using "directory string" or "octet string."

What character set does the DCE algorithm use ? Would PrintableString
or IA5String be sufficient ? Otherwise we can just define an LDAP syntax
OID for UTF8String.

Regards,
Steven