[snickers] Indefinate length encoding mystery solved

[Alex Karasulu <ao...@bellsouth.net>]

Hey guys,

Let me share just how much of a dumb azz I am. The indefinate encoding started
to perplex me so much I decided to send out an email to the Umich ldap list
regarding the problem. I asked about it and was told I should read the spec
better which I definately should have. It totally escaped me since I was so
deep into Snickers and just the BER spec from the ITU. It turns out the LDAP
spec clearly states that LDAP does not support the indefinate length encodings
as Howard Chu pointed out for me within section 5.1 of RFC 2251:

5.1. Mapping Onto BER-based Transport Services

The protocol elements of LDAP are encoded for exchange using the
Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the
high overhead involved in using certain elements of the BER, the
following additional restrictions are placed on BER-encodings of LDAP
protocol elements:

(1) Only the definite form of length encoding will be used.
...

BTW the indefinate encoding makes the codec code that much more difficult to
write which is why they abandoned using it. It would actually make chunking
possible for the encoding state. Since length must be known for the entire PDU
it must all be generated in advance before being flushed out the wire.
Definately not a good thing for chunking/streaming PDU's out the door for
clients and servers.

So I totally fudged up and looked like a fool on the list :-) (so what I say)
but the good news is the problem is just now about labor. This now sheds light
on why Snacc decoders worked just fine and LDAP specific decoders did not.
Basically Snacc is generic accepting all BER encodings and things like OpenLDAP
clients and the SUN JNDI provider are specific to LDAP without taking the
indefinate length into account.

Alex