Re: [ldapext] updating LDIF [RFC2849]

[Michael Ströder <michael@stroeder.com>]

Hallvard B Furuseth wrote:
> 3. The "ldif-attrval-record" entry format (the one with just "type:
>    value" lines) is most concise, readable, and - *almost* - most
>    convenient, but too limited.  One can do without, but that's a pity.
> 
>    * It does not support "control:".
> 
>    * A program which generates it, maybe from user input, must take
>      care not to use "changetype" or "control" as the first attribute
>      type.  This would switch to the verbose ldif-change-record format.
> 
>    * It implies the LDAP Add operation, 

IMO the ldif-attrval-record does not imply anything at all. It's
representing static data not an operation. The
program/script reading ldif-attrval-record has to interpret it and may
locally imply an operation if appropriate. Therefore I also don't miss
e.g. control: at all.

> but would also have been convenient with changetype:modify too, as
> with old Umich LDAP.

I don't agree on that.

>    The problem is that the "changetype:" keyword is overloaded.  It
>    specifies both which LDAP operation to perform and which LDIF
>    format the current record is written in.

And I think this is the right thing to do.

>    To match this, "changetype:" could take an optional format parameter,
>    maybe "simple"/"detailed", followed by the current change parameter:

Nope!

I'd rather prefer a clear note that "ldif-attrval-record" and
"ldif-change-record" shouldn't be mixed in a single file without
carefully thinking about the (local) implications.

>      dn: ...
>      changetype: simple modify
>    Changetype "simple add" would imply "add:<attr>" for the
>    attributes, while "simple modify" would imply "replace:<attr>.

Please not! I don't see any benefit from extending
"ldif-attrval-record". I'd prefer to keep this format as simple as
it is right now. An application could derive deltas from
"ldif-attrval-record" if appropriate for an add or  modify operation in
a certain situation:
E.g. my web2ldap does this when adding/editing an entry in
"ldif-attrval-record" format. In this situation web2ldap already knows
whether a new entry is to be added or an existing entry is to be
modified. In the latter case the "ldif-attrval-record" simply specifies
what the entry should contain after the modify operation.

> 4. Line-folding of comments seems more a source of confusion than
>    anything useful to me.  If you need a multi-line comment, you can
>    just start each line with '#'.

+1

>  Maybe LDIF files SHOULD NOT contain
>    line-folded comments, and LDIF parsers MAY reject them as possibe
>    user errors (a comment in a middle of a line-folded attribute)?

Hmm, seems I have to check this in python-ldap's module ldif...

> Regarding extensions, including the extended changetype above:
> Tt may be worth adding a note that clients commonly are liberal in what
> they accept - e.g. they don't require the initial version number.  So
> it's best to try to design extensions so that a client which does not
> support it, will fail rather than do the wrong thing (like trying to add
> the extension name as an attribute).

How should a parser distinguish between an extension and an attribute
type without any a-priori knowledge?

Ciao, Michael.

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