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

Yves Dorfsman wrote:
>
> I have not received any feed back on this message, and am not sure how to
> interpret that.
>
> Is everybody getting tired of the debate ?
> Is the idea of a here document syntax too ridiculous ?

Using the same syntax as the existing Unix shells is problematic, since there 
are already shell scripts that construct LDIF using here-documents. So yes, it 
appears your suggestion is not very well thought out.

This is also the wrong place (or the wrong time) to be discussing multi-line 
values; the purpose of LDIF is to faithfully transmit values stored in a 
directory. As such, whether a value is "multi-line" or not, and how those line 
breaks are represented, is determined solely by the attribute's syntax. 
Anything you discuss here in the LDIF spec is purely cosmetic. E.g., for your 
example below, one can easily write:

organizationName: A Very Long
   Organization name just
   to make a point

but the breaks are immaterial. If you want to talk about actual multi-line 
values with some kind of embedded line-break then you need to define a syntax 
with those properties.

> Is UTF-8 support in LDIF not that important ?

LDIF is just a transfer format, like base64. Any string data carried within it 
is already understood to be in UTF-8. So yes, UTF-8 is important, but it's 
already a given. You're confusing the content with the container.

> Am I the only one thinking xml is not a good replacement for LDIF, if so,
> should we help Steven with the xmled RFC ?

I don't see how the question is related, but IMO, the less XML exists, the better.

> Thanks.
>
>
> Yves Dorfsman wrote:
>>
>> Steven Legg wrote:
>>
>>>>>>> See http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt
>>
>> I did look at it, personally I find it difficult for humans, for
>> diff'ing etc... XML has its place, but so does pure text.
>>
>>
>>>> Yes I was wondering about that, do we need multi-line values as work
>>>> around because schemas aren't precise enough ?
>>>
>>> No, we need them because sheets of paper, computer screens and RFCs are
>>> not infinitely wide. :-) Human-readability, line breaks and indenting
>>> tend
>>> to go hand-in-hand.
>>
>>
>> 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

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/