[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] UTF-8 full support in LDIF / LDIF v2
On Mar 21, 2009, at 12:32 AM, Yves Dorfsman wrote:
Hi,
I'd like to re-start this thread.
I have been re-reading the earlier messages, and have put some
thought into it as well. I have also been communicating with the RFC-
editor and Alexey Melnikov (one of the Area Directors for LDAP). I
have also taken a stab at the new text to jumpstart the discussion.
Scope:
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.
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.)
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.
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.
My reasoning is that:
-the change is relatively simple
-the lack of UTF-8 support is a problem that affects me directly
-I understand the problem
-adding other major functionalities will probably delay the RFC,
while we could get this one out relatively fast, while working on
the other functionalities for another version.
Alexey said that he'd like to have all the options on the table.
Other items include (this is not intended to be exhaustive, I suspect
others have more items):
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.
There were also suggestions of adding a "charset" specification (yuk).
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.
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.
Authorship:
I have tried to contact Gordon Good, the original author of RFC 2849,
but have not heard from him yet (could be due to spam filters). The
RFC-Editor and Alexey say there are procedures around that, and we
can leave that as a last minute item.
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.)
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.
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.
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.
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.
Here are the two versions I have created:
http://www.sollers.ca/hg/ldif-utf8/file/d307d875966f/proposal.txt#l1
and a side by side diff:
http://www.sollers.ca/projects/ldif-utf8/files/proposal-diff.html
and with the addition of rfc 4525:
http://www.sollers.ca/hg/ldif-utf8/file/213f3b5dcd86/proposal.txt#l1
side by side diff:
http://www.sollers.ca/projects/ldif-utf8/files/rfc4525addon.html
--
Yves.
http://www.sollers.ca/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext