[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] UTF-8 full support in LDIF / LDIF v2
Kurt Zeilenga wrote:
I personally would prefer to address the UTF-8 support only, and
possibly other minor issues, but no other major change.
My view is that I rather not suffer the pain of updating the LDIF format
multiple times, and certainly rather not suffer significant pain for
just minor change.
I like the idea of addressing one change at a time. You address that one,
and spend all the time and energy on making sure you got it right, then when
that's done, you move on to the next...
Also, I might note that adding just UTF-8 is not totally a minor change,
there are a few oddities to consider. For instance, what would be
allows for end-of-line characters? Would we use Net-UTF8? (I hope not
as Net-UTF8 implies normalization and that goes against interchanging
arbitrary sequences of Unicode code points.)
Agreed, this is not minor, what I meant was I'd like to do UTF-8 +
*possibly* other minor changes, but I would rather not do UTF-8 + other
major changes. Sorry if I wasn't clear.
Having said that, if we get to a consensus on other changes that we can add
to my changes, or even if somebody wants to take my proposition and add
other change to it, I'm fine with that. My issue is UTF-8, that's what drove
me here, that's what I want to be fixed.
LDIF primary purpose is for interchange of directory data. Just adding
UTF-8 support doesn't allow for any additional interchange of
information. The UTF-8 change is for secondary purposes, to allow
humans to more easily see what they are interchanging, to allow humans
to directly modify the LDIF.
Good point, but UTF-8 sure helps for debugging ! Diffing base64 is
completely useless.
Also you could argue that the beauty of LDIF is its simplicity for humans.
If we don't care about that aspect, we could completely give up LDIF, and go
with something more complex like an XML format, or even a binary one.
I rather spend my time on adding features that do allow for the a
interchange of more directory data. Also LDIF ought to have similar
extensibility as LDAP itself has.
Let's start a list, and see who wants what in/out...
Extending LDIF to support all LDAP requests, e.g., an LDAP Transaction
Extending LDIF to support all LDAP responses, e.g., Entries, References,
Intermediate Responses, and Result returned in response to an LDAP
Search request.
Extending LDIF to support XML values.
Really ?
There were also suggestions of adding a "charset" specification (yuk).
Is there something we cannot do with Unicode ? I don't understand the
advantage of a "charset" keyword. If anything, I'd rather look at an
"encoding" keyword to support the different encodings of Unicode, for east
asian scripts for example which apparently takes a lot less space when
encoded in UTF-16. But, UTF-16 in itself is quite a bit more complex than
UTF-8, requiring a byte order mark etc... I was thinking this could wait a
future version.
Version scheme:
Last year I wrote that the version number is limited to one digit.
That was a mistake, I re-read RFC 2234 (the specification of
Backus-Naur Form), and what is in the current RFC is one digit or
more, so this is a non-issue.
This, I think, is an error. Generally errors should be fixed when
revising a document.
No, *I* am the one who made a mistake, there is nothing wrong with the
current spec. for the version number, back in december, I thought there was,
but I was wrong. It's a non-issue.
Escaping UTF-8 characters:
RFC 2253 (UTF-8 String Representation of Distinguished Names
) allows for escaping characters with backslashes and hex numbers. I
can see the point when working from the command line, and say your
terminal is not set properly, or you don't have the appropriate
keyboard, but I am not sure about files... What do you guys think ?
I rather avoid adding escaping.
Agreed, I'd just like to confirm this isn't a personal bias.
A non-issue.
Example in UTF-8:
The RFC-Editor is very clear on this, RFCs are ASCII only but we can
add a postscript file with examples containing UTF-8 if we want. I am
not sure there is much value, this is pretty trivial.
(Though I rather the IETF would change the RFC format from ASCII to
UTF-8, that's another fight.)
No kidding.
There are various conventions for providing examples of UTF-8 protocols
(and formats). IIRC, there's an RFC about how this (though I don't
recall its number). And I think at least once such example ought to be
included.
Yes, I believe you need to add a PDF or PS version to the original. I can
look at that. Is there a tradition on how to pick the names for the example,
or is it completely random ?
Removing some paragraphs:
Should we remove some paragraph that don't seem to be relevant any
more, such as:
" The application/directory MIME content-type [RFC2425] is a general
framework and format for conveying directory information, and is
independent of any particular directory service. The LDIF format is
a simpler format which is perhaps easier to create, and may also be
used, as noted, to describe a set of changes to be applied to a
directory.
"
I would oppose removing this text. Any replacement of the LDIF
specification needs to consider the impact on use of LDIF in MIME
encoded contents of the application/directory type.
It seems to me that this paragraph is giving historical information and
justifying some of the reasons behind LDIF... Am I wrong here.
If I am making an error and it's worth keeping, than that's fine.
Expired draft:
Refence [Armijo00] is a draft expired in 2001. It is used in example
7. Is this still relevant ?
The revised document should provide more relevant examples. In
particular, examples should use standard track controls. So this
(informative) reference ought to be replaced accordingly based upon
which standard track controls are used in examples.
I could not find any new version of this document, of a replacement for it.
As this just become standard practice ? Or is there a written standard for it ?
RFC4525:
I noticed that RFC 4525 has updated the LDIF definition. Should this
be included in this RFC ?
Yes, as LDIFv1 is formally RFC 2829 as updated by RFC 4525 (that's what
UPDATES means).
I have created an extra file with its inclusion.
Ok. I'll just merge the two files an drepost then.
--
Yves.
http://www.sollers.ca/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext