[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] UTF-8 full support in LDIF / LDIF v2




Kurt Zeilenga wrote:

If others have similar or overlapping
requirements it would be better for us to use the same specification even
if it never becomes a proposed standard RFC.

I wouldn't object to experimenting here, just so long as it not confused with standard LDIF.

But if one is going to try to solve a particular problem within the standard community, they should try to solve it generally. That is, we should dismiss solutions which only work well for limited subsets of Unicode.


Would you feel better if we called it the LDAP Data Composition Format(LDCF)
instead of LDIFv2 or Extended LDIF ?

Well, if one was to have an experiment to develop a LDAP data format, which the whole content is say Net-Unicode, calling it something other than LDIF would be good to avoid confusing it with LDIF. Things to tackle would include

- how to represent text values needing to be in different Unicode normalization (in the directory) than the required normalization, - how to represent non-text Unicode values (arbitrary sequences of Unicode points), - if Net-Unicode line separators are to be considered part of the value, how to represent values requiring other line separators, and
- bidirectional values.

Note: not requiring a particular normalization in the file is not a solution to first item, as that merely leaves it up to tools as to which normalization (if any) to apply. So the first item just becomes, how to convey the normalization algorithm required for the value when represented in the LDAP request.

These are not simple problems and are unlikely to be solved well on the first publication, hence experimental track does seem appropriate for this feature.

I would like LDIF standard extensions work to be limited to improving data interchange capabilities (such as representation of LDAP responses), which is a much more straight forward problem, something we are far more likely to get right on the first publication.

Just when I was about to give up.... Anyway, if we go ahead with this, I am assuming we need to move the discussion to a different mailing list ?

Should it be an ietf mailing list, or should it happen somewhere else and come back here when it starts to take form ?

--
Yves.
http://www.sollers.ca/

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext