Re: ASN1 - syncInfoValue

[Lee Jensen <lee_jensen@sento.com>]

On Wed, 2005-03-16 at 10:40 -0800, Kurt D. Zeilenga wrote:
> At 09:57 AM 3/16/2005, Lee Jensen wrote:
> >I figured out my problem from yesterday... It seems the decoding
> >specification I was using did not set the certain boolean elements to
> >optional so they were expected and the decoding did not work properly.
> 
> Note that OPTIONAL != DEFAULT FALSE.
> 
> I suggest you look at how DEFAULT FALSE is handled elsewhere in
> net::ldap.  Such ASN.1 constructions are common in LDAP.

Actually that's the reason I ended up using OPTIONAL... Below is another
part of Net::LDAP's ASN1 spec:
    Control ::= SEQUENCE {
        type             LDAPOID,
        critical         BOOLEAN OPTIONAL, -- DEFAULT FALSE,
        value            OCTET STRING OPTIONAL }

It would seem that Convert::ASN1 doesn't support default values which I
believe it should. It causes a bit of ambiguity because when say LDAP
returns a syncInfoMessage the refreshDeletes flag is just missing as
opposed to False... Maybe I should work on adding optional value
functionality to Convert::ASN1 while I'm at it. Otherwise I have to make
assumptions in my code that non-existent means false, but that causes
problems with DEFAULT TRUE... Lame...

> 
> >I have another issue. I am essentially just wondering essentially how
> >are the syncUUIDs encoded?
> 
> Each syncUUID is a OCTET STRING of size 16.  So, the
> its encoded as 04 10 followed by the 16 octets of the UUID.
> 
> >When I try to print out the decoded OCTET
> >STRINGS they are not standard ascii or utf-8 characters.
> 
> You cannot just print the UUID as its octets are not character
> data.  You need to encode them (using say the UUID string
> format) before printing.

K this all makes sense... I guess I was just confused about the
discrepency between the string representation stored as entryUUID in
LDAP and the value I was getting back from the sync message. I'm not
aware of whether perl has a conversion function. Am I correct in using
the following RFC to implement conversion functions??
http://mirror.switch.ch/cgi-bin/search/nph-findstd?preview=draft-mealling-uuid-urn-05.txt&scope=draft

> 
> You actually should store them as an 16-octet value
> and compare them to the 16-octet value **represented by**
> the entryUUID value.  That is,
> do NOT:
>         compare(uuid2str(syncuuid), entryuuid))
> do:
>         compare(syncuuid, str2uuid(entryuuid))
> 
> as a single UUID has multiple possible string representations.
> 
> That is, follow the general rule that comparisons in LDAP are
> to be done between abstract values, not physical representations
> of those abstract values.

I'm confused as to why the "abstract" representation is binary data and
the physical is a string. How is the data actually stored in the
database? I assume you use the binary representation as a key not the
string. I would also assume that when you say request the entryUUID
attribute with ldapsearch it gets changed from it's binary form to the
string representation.

Again, I really appreciate the help and clarification...

Lee Jensen