RE: LCUP Issue: UUID

["Liben, Michael (GTS)" <mliben@xxxxxxxxxxxxxxx>]

I don't think specifying a UUID algorithm is necessary. If the durn thing is universally unique--as its name implies--then specifying the algorithm should be irrelevant. 

Specifying a 'well-defined sting representation' would be exremely useful.

Mike

-----Original Message-----
From: Steven Legg [mailto:steven.legg@xxxxxxxxxxxxx] 
Sent: Wednesday, September 04, 2002 2:31 AM
To: 'John McMeeking'; ietf-ldup@xxxxxxx
Subject: 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