Re: UTF-8 full support in LDIF / LDIF v2

Yves,

Yves Dorfsman wrote:
> I've been thinking about this and trying a few things. My conclusion is 
> that the best solution would be the good old here document.
> 
> objectclass: inetOrgPerson
> organizationName:<<EOT
> The two line
>   company
> EOT
> sn: Jensen
> 
> 
> 
> With the following specifications:
> Any of the following characters (or sequence in the case of CR+LF) can 
> be used as a separator (<SEP>):
> 
> LF (U+000A), CR (U+000D), CR+LF (U+000D followed by U+000A), NEL 
> (U+0085), FF (U+000C), LS (U+2028), PS U+2029)
> 
> Any sequence of characters can be used instead of EOT, but cannot 
> include a separator character. The same sequence has to be used at the 
> begining and the end.
> 
> Any UTF-8 character, except separators, can be used on each line.
> 
> Any separator can be used to separate the lines.
> 
> The text start after EOT<SEP>, and finishes with the last character 
> before <SEP>EOT. The organization name in the example above is exactly 
> two lines, the last separator is not part of the text.
> 
> No need or possibility to escape characters, no possibility of folding 
> lines  .

I would be more amenable to a here-document scheme if there were no
special treatment for line separators. That is, if the UTF-8 character
sequence between the end of the introducer and the beginning of the
terminator is the literal directory attribute value without any modification.
That means that any line separators in the attribute value come out
as is, and may be different from the usual LDIF line separator.
Some tools will display these line breaks nicely and some won't, but even
a misaligned display is more accessible than a base64 representation of
the value.

The downside of a here-document scheme is the need to scan the value
before hand to make sure it doesn't contain the terminator sequence,
which becomes awkward for streaming applications, so I'd be inclined to
keep the current scheme as an alternative.

Regards,
Steven

> 
> 
>