attribute followed by 2nd colon results in "illegal base64 data at input"

[nikkicoon]

given an LDIF dump with an entry containing this attribute:
dircount: some.server.domain.tld 1 76 846
I get:
Error in line 84: illegal base64 data at input byte 15

The python implementation for ldif dumps does not complain about this.

value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
                                ":" FILL (BASE64-STRING) /
                                "<" FILL url)
                           ; See notes 7 and 8, below

SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
                           ; any value <= 127 decimal except NUL, LF,
                           ; and CR

SAFE-INIT-CHAR           = %x01-09 / %x0B-0C / %x0E-1F /
                           %x21-39 / %x3B / %x3D-7F
                           ; any value <= 127 except NUL, LF, CR,
                           ; SPACE, colon (":", ASCII 58 decimal)
                           ; and less-than ("<" , ASCII 60 decimal)

SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]

This include SPACE (32) if I'm right, so is the error right? The specs say that spaces are allowed.

[nikkicoon]

curious enough this happens in a file with 8 entries. In a file with roughly 6371008 entries this doesn't get processed by what I'm using.

It's possible that this is why hspark0582@96ec9ec was done in a fork

[nikkicoon]

Strange enough I'm unable to reproduce this in a test so far.

[nikkicoon]

I had an error in a function dealing with the empty value bug as a workaround..

[nikkicoon]

we have lines like (attribute names and values changed):
exampleAttr:: (many letters a-zA-Z)=

The double "::" seems to trip up ldif where the python one presumably deals fine with it.