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

From: Michael Ströder <[email-masked]>
Date: Thu, 04 Sep 2008 14:38:42 +0200

(Follow-up only on ldapext.)

Kurt Zeilenga wrote:
> (My own top-few list  
> would likely include updating LDIF [RFC2849].)

Somewhat I'm curious what you have in mind.
Only updating or extending?

Since today LDIF snippets are also used for templates, e.g. with
additional proprietary syntax for composing attribute values based on
other attributes, I'm currently thinking about how to do this right. I
have some rough ideas. Well, my favourite approach would not change the
LDIF syntax anyway.

Ciao, Michael.
_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 4 Sep 2008 07:18:42 -0700

> Only updating or extending?

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.

If we do bump the version, then it seems reasonable to consider  
whether there are desired features which are so useful that they  
should be integrated into core format instead of handled as  
extensions.  One that comes to mind here is Steven Legg's XML value  
feature.

-- Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 13 Sep 2008 21:04:46 +0200

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 15 Sep 2008 10:27:57 -0700

I've submitted a BOF proposal to Apps ADs for their consideration.   
Amongst other factors in determining whether to approve this BOF, they  
will need to be convinced that there is sufficient level of  
participation in the BOF and the proposed WG.   It would be helpful  
for those interested to express their interest, either on list or in  
person to Alexey (who has agreed to chair the BOF), and/or myself,  
within the next week or so.

Regards, Kurt

On Aug 29, 2008, at 2:48 PM, Kurt Zeilenga wrote:
> Lightweight Directory Access Protocol (LDAP) BOF
>
> Chair(s): TBD
>
> The purpose of this BOF is to discuss the formation of a working  
> group to undertake LDAP standards work.  It is conceived that the  
> proposed WG would undertake both the revision of existing technical  
> specifications for LDAP extensions and the engineering of new LDAP  
> extensions.
>
> There are numerous existing technical specifications for LDAP  
> extensions.  Most of the Standard Track specifications were  
> published prior to the current LDAP "core" specification [RFC 4510]  
> and are in the need of revision.  In some cases, it may be more  
> appropriate to move the extension off the Standards Track.   While  
> the work of determining which RFC should be revised (or moved off to  
> a different track), and prioritization of the work, could be  
> deferred to the WG, it is hoped that the BOF will reach some  
> conclusions as to which revision work is of the highest priority.
>
> There are also numerous extensions to LDAP which seem worthy of  
> standardization. It is hoped that the BOF will reach some conclusion  
> as to short list of new extension work items to be undertaken (at  
> least initially) by the proposed WG.  That short list might include,  
> for instance, in LDAP Transactions and Extensions for X.500 Alignment.
>
> By including both revision and new engineering work items in a  
> single working group it is hoped that the sufficient participation  
> levels will be maintained to make reasonable progress in both  
> revision and new engineering work.
>
>

---

From: Ludovic Poitou <[email-masked]>
Date: Mon, 15 Sep 2008 21:12:03 +0200

Hi Kurt,

I am interested in participating to both the BOF and proposed WG.

Ludovic.

On Sep 15, 2008, at 7:27 PM, Kurt Zeilenga wrote:

> Amongst other factors in determining whether to approve this BOF,  
> they will need to be convinced that there is sufficient level of  
>> the work of determining which RFC should be revised (or moved off  
>> to a different track), and prioritization of the work, could be  
>> standardization. It is hoped that the BOF will reach some  
>> conclusion as to short list of new extension work items to be  
>> undertaken (at least initially) by the proposed WG.  That short  
>> list might include, for instance, in LDAP Transactions and  
>> Extensions for X.500 Alignment.
>>

Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Lead               Directory Services
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Peter Buonora <[email-masked]>
Date: Tue, 16 Sep 2008 10:35:47 -0400

I would be interested in participating.

Thanks,
Peter

Kurt Zeilenga wrote:
>> extensions.  Most of the Standard Track specifications were published 
>> prior to the current LDAP "core" specification [RFC 4510] and are in 
>> the need of revision.  In some cases, it may be more appropriate to 
>> move the extension off the Standards Track.   While the work of 
>> determining which RFC should be revised (or moved off to a different 
>> track), and prioritization of the work, could be deferred to the WG, 
>> it is hoped that the BOF will reach some conclusions as to which 
>> revision work is of the highest priority.
>>
>> By including both revision and new engineering work items in a single 
>> working group it is hoped that the sufficient participation levels 
>> will be maintained to make reasonable progress in both revision and 
>> new engineering work.
>>
>>
>

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 16 Sep 2008 09:03:18 -0700

A number of folks have asked me whether there was a requirement to  
attend any particular IETF meeting to participate in this effort.
The answer is "no".   Those who are willing to participate, via any  
means, are encouraged to express their interest.

Regards, Kurt

---

From: Gavin Henry <[email-masked]>
Date: Tue, 16 Sep 2008 17:04:07 +0100 (BST)

I'm also very interested in participating.

Thanks.

-- 
Kind Regards,

Gavin Henry.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E [email-masked]

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.
_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: "Clément OUDOT" <[email-masked]>
Date: Tue, 16 Sep 2008 18:07:09 +0200

So am I!

Thanks,

Clément OUDOT

---

From: "Neil A. Wilson" <[email-masked]>
Date: Tue, 16 Sep 2008 11:23:23 -0500

> within the next week or so.

I would like to participate.

Neil Wilson

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 16 Sep 2008 18:43:10 +0200

Kurt Zeilenga writes:
> participation in the BOF and the proposed WG.

I'd participate in the WG's mailinglist and hopefully some WG meeting,
but probably not this BOF.

One question about the WG charter: Stick to features with existing
implementations, or consider significant new invention, or leave
that choice open?

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Sep 2008 17:47:15 +0100

>implementations, or consider significant new invention, or leave
I would think that the choice is open at the moment. If you have some 
suggestions (in either category), now would be a good time to mention them.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 16 Sep 2008 18:52:45 +0200

> suggestions (in either category), now would be a good time to mention them.

No, just curious at the moment.  Workflow and results can be rather
different for the two.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 16 Sep 2008 09:20:56 +0200

Hallvard B Furuseth wrote:
>    * 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.

>    format the current record is written in.

And I think this is the right thing to do.

>    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.

>    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.

>    just start each line with '#'.

+1

>  Maybe LDIF files SHOULD NOT contain

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

> 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.

---

From: Howard Chu <[email-masked]>
Date: Tue, 16 Sep 2008 11:47:10 -0700

I'm interested as well.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: Steven Legg <[email-masked]>
Date: Wed, 17 Sep 2008 08:57:44 +1000

I won't be attending the BOF, but I will participate in a working group,
including as editor for some of the working group documents.

Regards,
Steven

---

From: Michael Ströder <[email-masked]>
Date: Wed, 17 Sep 2008 15:06:54 +0200

> within the next week or so.

I'd be willing to contribute to the work of the WG but will not attend
the BOF.

Ciao, Michael.

---

From: Pierangelo Masarati <[email-masked]>
Date: Wed, 17 Sep 2008 15:08:43 +0200

> I'd be willing to contribute to the work of the WG but will not attend

Same for me.  Cheers, p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   [email-masked]
-----------------------------------

---

From: Andrew Findlay <[email-masked]>
Date: Thu, 18 Sep 2008 10:05:19 +0100

> I've submitted a BOF proposal to Apps ADs for their consideration.   

I won't be at IETF#73 but count me in for the working group.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------
_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext