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

Re: [ldapext] new version of LDIF



On Sat, 2008-12-20 at 06:55 +0100, Hallvard B Furuseth wrote:
> Yves Dorfsman writes:
> > From my experience with open-ldap and what I have read on the net about the 
> > other servers, all the LDAP servers will happily import LDIF files with 
> > "plain UTF-8", but they all follow the RFC when it comes to write LDIF, and 
> > base 64 encode anything that contains a characters other than SAFE-CHAR.
> > Same thing for the python-ldap library.
> > 
> > So really, there isn't a lot that needs to be changed, and it shouldn't 
> > disturb the existing products at all, it will just give them another option 
> > for writing.
> 
> In that case I think you're talking of an update to LDIFv1, to align
> the RFC with current practice.  An update most implementations would
> need to do nothing to support.  Is that what you are volunteering to
> do?  If so, a free-for-all with change wishes would be a bit
> pointless, unless someone else gets inspired to do LDIFv2.
> 
> Bumping the version number would require work on many implementations
> and installations:  They'd begin to receive LDIFv2 files, and would
> thus feel pressure to accept them.
> 
> Of course, which changes to include will still be debatable.  _Some_
> implementatinos likely follow the RFC and reject 8-bit data.  Others
> may follow the grammar except the UTF-8 part, and would choke on my
> suggestion to loosen the grammar.  An optional feature ("charset:")
> could likely go in if it doesn't conflict with an existing extension.

I think another point is also how far you want to go.
So far an LDIF file is basically just a dump, a copycat image of a
directory, something you can use basically only as loading from zero.
But it's usefulness decreases greatly if you want to use4 it on "dirty"
directories, as LDIF currently has no understanding of existing objects,
conditional modifications and so on.

I am sure many people have developed their own formats and tools to do
conditional updates, and so we have in our own project.

Now would it be interesting for others to go as far as adding clues to
the format about how the server should behave?
What to do if the entry or the attribute mentioned in the LDIF file
already exist, whether it should be replaced, changed, added on top,
etc ... ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo@samba.org>
Senior Software Engineer at Red Hat Inc. <simo@redhat.com>

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