Re: [ldapext] updating LDIF [RFC2849] (was: IETF#73 LDAP BOF Proposal)

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt Zeilenga writes:
> I was thinking it would be good to, at a minimum, to revise RFC 2849
> for clarity (no version bump).
>
> It may be appropriate to consider updating it to support extensions.
> That is, in addition to a version indicator, add a required-extension
> indicator.  That way readers can determine whether they'll be able to
> read the file without having to read the whole file.  Just the
> addition of this would lead to the version number having to be bumped.

Sounds good to me.  The spec does have its annoyances, and I'm not sure
which real-world programs follow it with those anyway.  I think fixing
those and adding required-extension would be worth a version bump:

1. An LDIF file consists of 1 or more entries.

   0 or more would be more convenient.

2. It cannot start or end with an empty line.  Recurrent cause of parse
   errors as people write comments at the beginning or end of the file,
   separated from each other and the LDIF entries by empty lines.  Also
   since (CR)LF is only a separator, it's an error when people produce
   entry-strings as blobs ending with 2 (CR)LFs.

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, but would also have been
     convenient with changetype:modify too, as with old Umich LDAP.

   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.

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

     dn: ...
     changetype: simple modify
     attr: value
     attr: value
     ...

   Changetype "simple add" would imply "add:<attr>" for the
   attributes, while "simple modify" would imply "replace:<attr>.
   Umich LDAP had options for changetype add/modify and
   attribute change type modify/replace; it turned out people
   usually used "replace" along with "modify".  OpenLDAP made
   this the default once, but has since gotten stricter.

   Though one could also add a third keyword saying what to do with the
   attributes.  "changetype: simple modify:<add, replace or delete>".

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 '#'.  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)?


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).
Thus I did not suggest a new LDIF line "format: simple/detailed", and
I made the format parameter the first instead of second changetype
parameter.  That way sloppy old clients that only pay attention to the
first keyword, will choke rather than apply the wrong kind of change.

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