Subject: [ldapext] parsing LDIF: leading spaces

From: Michael Ströder <[email-masked]>
Date: Wed, 30 Sep 2015 12:21:11 +0200

HI!

How does implementors here parse LDIF with *leading* spaces in value-spec
defined in RFC 2849?

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

Since [1] and even its pre-predecessor [2] says that this means zero or more
occurences of SPACE the following gets ambigous:

foo:  bar
foo: bar
foo:bar

One could read RFC 2849 that all these result in the same attribute value
'bar'. But does that meet the expectations or would this cause interop issues?

Before somebody claims that values with leading spaces must be base64-encoded:

from RFC 2849:

      8)  Values or distinguished names that end with SPACE SHOULD be
          base-64 encoded.

This is only a SHOULD and AFAICS it says nothing about leading spaces.

[1] https://tools.ietf.org/html/rfc5234#section-3.6
[2] https://tools.ietf.org/html/rfc2234#section-3.6

Ciao, Michael.

---

From: [email-masked]
Date: Wed, 30 Sep 2015 09:18:30 -0500

>From RFC 2849, item 4 under Notes on LDIF Syntax:  "Any value that ... begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded."  Since SAFE-INIT-CHAR excludes SPACE, any value that starts with SPACE MUST be base-64 encoded.

-----Original Message-----
From: "Michael Ströder" <[email-masked]>
To: ldapext <[email-masked]>
Sent: Wed, 30 Sep 2015 5:21 AM
Subject: [ldapext] parsing LDIF: leading spaces

HI!

foo:  bar
foo: bar
foo:bar

from RFC 2849:

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 30 Sep 2015 19:06:11 +0200

[email-masked] wrote:
> From RFC 2849, item 4 under Notes on LDIF Syntax:  "Any value that ...
> begins with a character other than those defined as "SAFE-INIT-CHAR",
> above, MUST be base-64 encoded."  Since SAFE-INIT-CHAR excludes SPACE, any
> value that starts with SPACE MUST be base-64 encoded.

Aargh! Thanks for reminding me...

Ciao, Michael.