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