Re: parsing LDIF: leading spaces

[email protected] Wed, 30 Sep 2015 09:18:30 -0500
Newsgroups gmane.ietf.ldapext
Message-ID <826cca7f-5573-469c-ae1b-28109e4dd736.maildroid@localhost>
>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 protected]>
To: ldapext <[email protected]>
Sent: Wed, 30 Sep 2015 5:21 AM
Subject: [ldapext] parsing LDIF: leading spaces

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.

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext