[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] 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/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext