[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ASN1 - syncInfoValue
A quick clarifying note...
Below, by entryUUID, I was referring to the entryUUID operational
attribute whole values are transferred in LDAP using a particular
string representation. An LDAPsync implementation actually gets
entry UUIDs as syncUUIDs, each a 16-octet value. So, normally,
one is just comparing 16-octet values with 16-octet values.
There may be cases where one might want to compare a syncUUID
with the string value of the entryUUID attribute of an entry,
in such cases, one should convert the string to the 16-octet
instead of trying to convert the 16-octet to a string.
Kurt
At 10:40 AM 3/16/2005, Kurt D. Zeilenga wrote:
>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.
>
>Kurt
>
>>Thanks for all your help.
>>
>>Lee Jensen
>>
>>On Tue, 2005-03-15 at 13:40 -0800, Kurt D. Zeilenga wrote:
>>> At 01:08 PM 3/15/2005, Lee Jensen wrote:
>>> >On Tue, 2005-03-15 at 12:59 -0800, Kurt D. Zeilenga wrote:
>>> >> I not familiar with net::ldap debugging statements to know
>>> >> what's really happen underneath. Suggest you provide a
>>> >> hex dump of the whole PDU. Off hand, it looks like the
>>> >> ending SET OF syncUUID is missing, possibly an empty set
>>> >> (31 00).
>>> >>
>>> >
>>> >Well the debugging is actually from Convert::ASN1 but here is the hex
>>> >dump anyway:
>>> >
>>> >30 81 92 02 01 02 79 81 8C 8A 18 31 2E 33 2E 36 0.....y....1.3.6
>>> >2E 31 2E 34 2E 31 2E 34 32 30 33 2E 31 2E 39 2E .1.4.1.4203.1.9.
>>> >31 2E 34 8B 70 A3 6E 31 6C 04 10 40 59 47 D0 23 1.4.p.n1l..@YG.#
>>> >7A 10 29 91 2A 90 61 61 9A 89 0B 04 10 D2 80 A8 z.).*.aa........
>>> >BA 25 FA 10 29 8E 95 94 C1 3F CB 53 CE 04 10 9B .%..)....?.S....
>>> >33 A5 F2 26 C1 10 29 9E 3A E7 B7 04 1D 82 48 04 3..&..).:.....H.
>>> >10 F5 52 BF 82 26 C1 10 29 9E 3B E7 B7 04 1D 82 ..R..&..).;.....
>>> >48 04 10 5C 6D 13 D4 26 C2 10 29 9E 3C E7 B7 04 H..\m..&..).<...
>>> >1D 82 48 04 10 D4 BE C4 3E 26 C4 10 29 92 95 DC ..H.....>&..)...
>>> >CB 4F 43 CF 50 __ __ __ __ __ __ __ __ __ __ __ .OC.P
>>>
>>> This looks okay to me. The SyncInfoValue.syncIdSet has no
>>> cookie (its OPTIONAL), no refreshDeletes (its the DEFAULT),
>>> and a non-empty SET OF syncUUIDs.
>>>
>>> >AND
>>> >
>>> >30 49 02 01 02 79 44 8A 18 31 2E 33 2E 36 2E 31 0I...yD..1.3.6.1
>>> >2E 34 2E 31 2E 34 32 30 33 2E 31 2E 39 2E 31 2E .4.1.4203.1.9.1.
>>> >34 8B 28 A2 26 04 24 63 73 6E 3D 32 30 30 35 30 4.(.&.$csn=20050
>>> >33 31 35 31 36 33 33 33 30 5A 23 30 30 30 30 30 315163330Z#00000
>>> >31 23 30 30 23 30 30 30 30 30 30 __ __ __ __ __ 1#00#000000
>>>
>>> This looks okay to me as well. The SyncInfoValue.refreshPresent
>>> has a cookie and no refreshDeletes (its the DEFAULT).
>>>
>>>
>>>
>>> >Thanks for your help Kurt,
>>> >
>>> >Lee
>>> >
>>> >> Kurt
>>> >>
>>> >> At 08:58 AM 3/15/2005, Lee Jensen wrote:
>>> >> >I am attempting to modify the Net::LDAP module for perl to understand
>>> >> >openLDAP's content synchronization controls (syncrepl functionality).
>>> >> >
>>> >> >I am currently able to use refresh and persist mode and retrieve the
>>> >> >cookies/controls that come back with each result but I am having a
>>> >> >problem with the syncInfoMessage. It's an intermediate message as
>>> >> >defined in the RFC.
>>> >> >http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-sync-06.txt
>>> >> >
>>> >> >My question is this... In the RFC the syncInfoValue is defined as
>>> >> >follows:
>>> >> > syncInfoValue ::= CHOICE {
>>> >> > newcookie [0] syncCookie,
>>> >> > refreshDelete [1] SEQUENCE {
>>> >> > cookie syncCookie OPTIONAL,
>>> >> > refreshDone BOOLEAN DEFAULT TRUE
>>> >> > },
>>> >> > refreshPresent [2] SEQUENCE {
>>> >> > cookie syncCookie OPTIONAL,
>>> >> > refreshDone BOOLEAN DEFAULT TRUE
>>> >> > },
>>> >> > syncIdSet [3] SEQUENCE {
>>> >> > cookie syncCookie OPTIONAL,
>>> >> > refreshDeletes BOOLEAN DEFAULT FALSE,
>>> >> > syncUUIDs SET OF syncUUID
>>> >> > }
>>> >> > }
>>> >> >
>>> >> >I have code to enable Net::LDAP::ASN to parse this specification but
>>> >> >something just doesn't seem quite right. I can't tell if there is a
>>> >> >problem with the ASN decoder or what. I get 2 seemingly different
>>> >> >messages coming back when I do dumps...
>>> >> >
>>> >> >THIS which comes back if I connect with no cookie:
>>> >> >
>>> >> >0000 73: SEQUENCE {
>>> >> >0002 1: INTEGER = 2
>>> >> >0005 68: [APPLICATION 25] {
>>> >> >0007 24: [CONTEXT 10]
>>> >> >0009 : 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 34 32 30 33
>>> >1.3.6.1.4.1.4203
>>> >> >0019 : 2E 31 2E 39 2E 31 2E 34 __ __ __ __ __ __ __
>>> >__ .1.9.1.4
>>> >> >0021 40: [CONTEXT 11]
>>> >> >0023 : A2 26 04 24 63 73 6E 3D 32 30 30 35 30 33 31
>>> >35 .&.$csn=20050315
>>> >> >0033 : 31 36 33 33 33 30 5A 23 30 30 30 30 30 31 23 30
>>> >163330Z#000001#0
>>> >> >0043 : 30 23 30 30 30 30 30 30 __ __ __ __ __ __ __ __
>>> >0#000000
>>> >> >004B : }
>>> >> >004B : }
>>> >> >
>>> >> >AND THIS which comes back if my client connects with an older cookie,
>>> >> >followed by the response above.
>>> >> >
>>> >> >0000 146: SEQUENCE {
>>> >> >0003 1: INTEGER = 2
>>> >> >0006 140: [APPLICATION 25] {
>>> >> >0009 24: [CONTEXT 10]
>>> >> >000B : 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 34 32 30 33
>>> >1.3.6.1.4.1.4203
>>> >> >001B : 2E 31 2E 39 2E 31 2E 34 __ __ __ __ __ __ __
>>> >__ .1.9.1.4
>>> >> >0023 112: [CONTEXT 11]
>>> >> >0025 : A3 6E 31 6C 04 10 40 59 47 D0 23 7A 10 29 91
>>> >2A .n1l..@YG.#z.).*
>>> >> >0035 : 90 61 61 9A 89 0B 04 10 D2 80 A8 BA 25 FA 10
>>> >29 .aa.........%..)
>>> >> >0045 : 8E 95 94 C1 3F CB 53 CE 04 10 9B 33 A5 F2 26
>>> >C1 ....?.S....3..&.
>>> >> >0055 : 10 29 9E 3A E7 B7 04 1D 82 48 04 10 F5 52 BF
>>> >82 .).:.....H...R..
>>> >> >0065 : 26 C1 10 29 9E 3B E7 B7 04 1D 82 48 04 10 5C 6D
>>> >&..).;.....H..\m
>>> >> >0075 : 13 D4 26 C2 10 29 9E 3C E7 B7 04 1D 82 48 04
>>> >10 ..&..).<.....H..
>>> >> >0085 : D4 BE C4 3E 26 C4 10 29 92 95 DC CB 4F 43 CF
>>> >50 ...>&..)....OC.P
>>> >> >0095 : }
>>> >> >0095 : }
>>> >> >
>>> >> >The CONTEXT 11 field should just be the responseValue which by
>>> >> >definition should be a SyncInfoValue but it won't parse that way.
>>> >> >
>>> >> >Could someone please provide some help with this. Honestly I'm
>>> >> >confused and don't know exactly what to try next.
>>> >> >
>>> >> >Lee
>>> >>
>>>