From ldapext-bounces@ietf.org  Fri Apr  1 02:57:47 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23841
	for <ldapext-archive@lists.ietf.org>; Fri, 1 Apr 2005 02:57:47 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHH1G-0000CT-8M; Fri, 01 Apr 2005 02:56:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHH1E-0000BJ-CB
	for ldapext@megatron.ietf.org; Fri, 01 Apr 2005 02:56:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23753
	for <ldapext@ietf.org>; Fri, 1 Apr 2005 02:56:39 -0500 (EST)
Received: from lucius.provo.novell.com ([137.65.81.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHH8U-0006j3-Q6
	for ldapext@ietf.org; Fri, 01 Apr 2005 03:04:12 -0500
Received: from INET-PRV1-MTA by lucius.provo.novell.com
	with Novell_GroupWise; Fri, 01 Apr 2005 00:56:27 -0700
Message-Id: <s24c9c3b.049@lucius.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta
Date: Fri, 01 Apr 2005 00:01:33 -0700
From: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
To: <ldapext@ietf.org>, <Kurt@OpenLDAP.org>
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [ldapext] RFC 3062 section 2.1 and section 3
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0363677641=="
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--===============0363677641==
Content-Type: multipart/alternative; boundary="=__Part4A6949DD.0__="

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4A6949DD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Kurt,
This section says:
A Password Modify request is an ExtendedRequest with the requestName
field containing passwdModifyOID OID and optionally provides a
requestValue field.
The rfc does not specify what is the expected server behaviour when the
extension contains only the passwdModifyOID and no value.
My guess is that this will cause the server to generate a password for
the identity which is currently bound on the connection on which the
request was recieved and hence the server is required to return the
generated password in the extended response.
 
Also in section 2, the rfc says:
   If oldPasswd is present and the provided value cannot be verified
or
   is incorrect, the server SHALL NOT change the user password. 
 
In this case, what is the LDAP error that the server should send bac to
the client.
 
Prasad

--=__Part4A6949DD.0__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Kurt,<BR>This section says:<BR>A Password Modify request is an=20
ExtendedRequest with the requestName<BR>field containing passwdModifyOID =
OID and=20
<STRONG>optionally</STRONG> provides a<BR>requestValue field.<BR>The rfc =
does=20
not specify what is the expected server behaviour when the extension =
contains=20
only the passwdModifyOID and no value.</DIV>
<DIV>My guess is that this will cause the server to generate a password =
for the=20
identity which is currently bound on the connection on which the request =
was=20
recieved and hence the server is required to return the generated password =
in=20
the extended response.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Also in section 2, the rfc says:</DIV>
<DIV>&nbsp;&nbsp; If oldPasswd is present and the provided value cannot =
be=20
verified or<BR>&nbsp;&nbsp; is incorrect, the server SHALL NOT change the =
user=20
password. </DIV>
<DIV>&nbsp;</DIV>
<DIV>In this case, what is the LDAP error that the server should send bac =
to the=20
client.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Prasad</DIV></BODY></HTML>

--=__Part4A6949DD.0__=--


--===============0363677641==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0363677641==--



From ldapext-bounces@ietf.org  Fri Apr  1 04:09:27 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04558
	for <ldapext-archive@lists.ietf.org>; Fri, 1 Apr 2005 04:09:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DHI83-00039y-W6; Fri, 01 Apr 2005 04:07:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DHI7z-00038D-Mz
	for ldapext@megatron.ietf.org; Fri, 01 Apr 2005 04:07:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04493
	for <ldapext@ietf.org>; Fri, 1 Apr 2005 04:07:41 -0500 (EST)
Received: from boole.openldap.org ([204.152.186.50] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHIFG-00015S-Is
	for ldapext@ietf.org; Fri, 01 Apr 2005 04:15:15 -0500
Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net
	[24.205.218.53]) (authenticated bits=0)
	by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j3197bi2055669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Apr 2005 09:07:37 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.2.1.2.0.20050401005135.0346bbc0@mail.openldap.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 01 Apr 2005 01:07:15 -0800
To: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] RFC 3062 section 2.1 and section 3
In-Reply-To: <s24c9c3b.049@lucius.provo.novell.com>
References: <s24c9c3b.049@lucius.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

At 11:01 PM 3/31/2005, Vithalprasad Gaitonde wrote:
>Kurt,
>This section says:
>A Password Modify request is an ExtendedRequest with the requestName
>field containing passwdModifyOID OID and optionally provides a
>requestValue field.
>The rfc does not specify what is the expected server behaviour when the extension contains only the passwdModifyOID and no value.

If no control value is present, then no PasswdModifyRequestValue
is present, and hence, none of its fields are present.

>My guess is that this will cause the server to generate a password for the identity which is currently bound on the connection on which the request was recieved and hence the server is required to return the generated password in the extended response.

Well, more precisely, the message requests the server generate
a password for the current user.  The server is not required to
do so, it return an error if its unwilling or unable to provide
the requested service.

>Also in section 2, the rfc says:
>   If oldPasswd is present and the provided value cannot be verified or
>   is incorrect, the server SHALL NOT change the user password. 
> 
>In this case, what is the LDAP error that the server should send bac to the client.

The specification prescribes an appropriate resultCode.
If the server is busy, then returning busy might be
appropriate.  But if the password is invalid,
then invalidCredentials would be appropriate.

> 
>Prasad
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext


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


From ldapext-bounces@ietf.org  Tue Apr  5 23:19:14 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17196
	for <ldapext-archive@lists.ietf.org>; Tue, 5 Apr 2005 23:19:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJ13X-0007df-8x; Tue, 05 Apr 2005 23:18:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ13V-0007dV-AO
	for ldapext@megatron.ietf.org; Tue, 05 Apr 2005 23:18:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17097
	for <ldapext@ietf.org>; Tue, 5 Apr 2005 23:18:10 -0400 (EDT)
Received: from boole.openldap.org ([204.152.186.50] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ1Bk-0002LU-Cd
	for ldapext@ietf.org; Tue, 05 Apr 2005 23:26:45 -0400
Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net
	[24.205.218.53]) (authenticated bits=0)
	by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j363I8Vt054475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Apr 2005 03:18:09 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.2.1.2.0.20050405201247.054e2328@mail.openldap.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 05 Apr 2005 20:17:44 -0700
To: ldapext@ietf.org
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: ietf-ldapbis@OpenLDAP.org
Subject: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-cosine-00.txt
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

This I-D is primarily an update of RFC 1274.  With
LDAPBIS's user-schema I-D, and a soon to be submitted
zeilenga-ldap-domains, replaces RFC 2247 as well.
(I'm thinking about 2377bis as well.)

My intent is to submit this for publication in conjunction
with the revised LDAP TS being produced by the LDAPBIS
WG.  Please review.  Technical comments to <ldapext@ietf.org>
and editorial comments to <kurt@openldap.org>.

Thanks, Kurt

>To: i-d-announce@ietf.org
>From: Internet-Drafts@ietf.org
>Date: Tue, 05 Apr 2005 15:29:59 -0400
>Subject: I-D ACTION:draft-zeilenga-ldap-cosine-00.txt
>Reply-To: internet-drafts@ietf.org
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>        Title           : COSINE LDAP/X.500 Schema
>        Author(s)       : K. Zeilenga
>        Filename        : draft-zeilenga-ldap-cosine-00.txt
>        Pages           : 25
>        Date            : 2005-4-5
>        
>This document provides a collection of schema elements for use with
>  the Lightweight Directory Access Protocol (LDAP) from the COSINE and
>  Internet X.500 pilot projects.
>
>  This document obsoletes RFC 1274 and RFC 2247.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-cosine-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>        "get draft-zeilenga-ldap-cosine-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>        mailserv@ietf.org.
>In the body type:
>        "FILE /internet-drafts/draft-zeilenga-ldap-cosine-00.txt".
>        
>NOTE:   The mail server at ietf.org can return the document in
>        MIME-encoded form by using the "mpack" utility.  To use this
>        feature, insert the command "ENCODING mime" before the "FILE"
>        command.  To decode the response(s), you will need "munpack" or
>        a MIME-compliant mail reader.  Different MIME-compliant mail readers
>        exhibit different behavior, especially when dealing with
>        "multipart" MIME messages (i.e. documents which have been split
>        up into multiple messages), so check your local documentation on
>        how to manipulate these messages.
>                
>                
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID: <2005-4-5160053.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-zeilenga-ldap-cosine-00.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-zeilenga-ldap-cosine-00.txt>
>_______________________________________________
>I-D-Announce mailing list
>I-D-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/i-d-announce


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


From ldapext-bounces@ietf.org  Thu Apr 14 08:23:09 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06028
	for <ldapext-archive@lists.ietf.org>; Thu, 14 Apr 2005 08:23:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM3HP-000552-G0; Thu, 14 Apr 2005 08:17:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM3HN-00054a-Gb
	for ldapext@megatron.ietf.org; Thu, 14 Apr 2005 08:17:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05362
	for <ldapext@ietf.org>; Thu, 14 Apr 2005 08:16:56 -0400 (EDT)
Received: from lucius.provo.novell.com ([137.65.81.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM3RD-0004KE-NJ
	for ldapext@ietf.org; Thu, 14 Apr 2005 08:27:17 -0400
Received: from INET-PRV1-MTA by lucius.provo.novell.com
	with Novell_GroupWise; Thu, 14 Apr 2005 06:16:46 -0600
Message-Id: <s25e0ace.036@lucius.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta
Date: Thu, 14 Apr 2005 06:16:14 -0600
From: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
To: <hyc@highlandsun.com>
Subject: Re: [ldapext] referencing one LDIF file from another
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1287454946=="
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--===============1287454946==
Content-Type: multipart/alternative; boundary="=__Part3516241E.1__="

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3516241E.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Howard,
Following is the change we could do to section "Formal Syntax
Definition of LDIF"

included-ldif-file-content = "include:" FILL fileName
;where the contents of filename confirm to ldif-file of type
ldif-content

included-ldif-file-content = "include:" FILL fileName
;where the contents of filename confirm to ldif-file of type
ldif-changes

included-content-ldifs = 1*(1*SEP included-ldif-file-content)

included-changes-ldifs = 1*(1*SEP included-ldif-file-changes)

ldif-file = ldif-content / ldif-changes / included-content-ldifs /
included-changes-ldifs 

ldif-content = version-spec included-content-ldifs 1*(1*SEP
ldif-attrval-record)

ldif-changes = version-spec included-changes-ldifs 1*(1*SEP
ldif-change-record)

Let me know what you think.

Thanks,
Prasad

>>> Howard Chu <hyc@highlandsun.com> 11/23/2004 12:33:06 PM >>>
Vithalprasad Gaitonde wrote:
> RFC2849 doesnt seem to provide a way to include one ldif file into
> another ldif file though it does allow referencing an external file
for
> an attribute value.
> Has this been considered in the past ? 
> It seems like a useful thing to have when there are dependencies
across
> several ldif files.

I agree, I would definitely have a use for this. Haven't thought about

what the syntax should be yet.

-- 
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc 
Symas: Premier OpenSource Development and Support

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


--=__Part3516241E.1__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Howard,<BR>Following is the change we could do to section "<STRONG>For=
mal=20
Syntax Definition of LDIF"<BR></STRONG><BR>included-ldif-file-content =
=3D=20
"include:" FILL fileName<BR>;where the contents of filename confirm to =
ldif-file=20
of type ldif-content<BR><BR>included-ldif-file-content =3D "include:" =
FILL=20
fileName<BR>;where the contents of filename confirm to ldif-file of =
type=20
ldif-changes<BR></DIV>
<DIV>included-content-ldifs =3D 1*(1*SEP=20
included-ldif-file-content)<BR><BR>included-changes-ldifs =3D 1*(1*SEP=20
included-ldif-file-changes)<BR><BR>ldif-file =3D ldif-content / ldif-change=
s /=20
included-content-ldifs / included-changes-ldifs <BR><BR>ldif-content =
=3D=20
version-spec included-content-ldifs 1*(1*SEP=20
ldif-attrval-record)<BR><BR>ldif-changes =3D version-spec included-changes-=
ldifs=20
1*(1*SEP ldif-change-record)<BR></DIV>
<DIV>Let me know what you think.</DIV>
<DIV><BR>Thanks,</DIV>
<DIV>Prasad<BR><BR>&gt;&gt;&gt; Howard Chu &lt;hyc@highlandsun.com&gt;=20
11/23/2004 12:33:06 PM &gt;&gt;&gt;<BR>Vithalprasad Gaitonde wrote:<BR>&gt;=
=20
RFC2849 doesnt seem to provide a way to include one ldif file into<BR>&gt;=
=20
another ldif file though it does allow referencing an external file =
for<BR>&gt;=20
an attribute value.<BR>&gt; Has this been considered in the past ? =
<BR>&gt; It=20
seems like a useful thing to have when there are dependencies across<BR>&gt=
;=20
several ldif files.<BR><BR>I agree, I would definitely have a use for =
this.=20
Haven't thought about <BR>what the syntax should be yet.<BR><BR>-- <BR>-- =
Howard=20
Chu<BR>Chief Architect, Symas Corp. Director, Highland Sun<BR><U><A=20
href=3D"http://www.symas.com">http://www.symas.com</A></U> <U><A=20
href=3D"http://highlandsun.com/hyc">http://highlandsun.com/hyc</A></U> =
<BR>Symas:=20
Premier OpenSource Development and=20
Support<BR><BR>_______________________________________________<BR>Ldapext=
=20
mailing list<BR><U><A href=3D"mailto:Ldapext@ietf.org">Ldapext@ietf.org</A>=
</U>=20
<BR><U><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/ldapext">https://www1.ietf.o=
rg/mailman/listinfo/ldapext</A></U>=20
<BR></DIV></BODY></HTML>

--=__Part3516241E.1__=--


--===============1287454946==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1287454946==--



From ldapext-bounces@ietf.org  Thu Apr 14 09:06:14 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09396
	for <ldapext-archive@lists.ietf.org>; Thu, 14 Apr 2005 09:06:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM3va-0002l0-Kj; Thu, 14 Apr 2005 08:58:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM3vY-0002jl-Mj
	for ldapext@megatron.ietf.org; Thu, 14 Apr 2005 08:58:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08780
	for <ldapext@ietf.org>; Thu, 14 Apr 2005 08:58:27 -0400 (EDT)
Received: from highlandsun.propagation.net ([66.221.212.168])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM45P-00064F-9z
	for ldapext@ietf.org; Thu, 14 Apr 2005 09:08:48 -0400
Received: from [127.0.0.1] (highlandsun.com [66.221.212.169])
	by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id
	j3ECwJYP031959; Thu, 14 Apr 2005 06:58:20 -0600
Message-ID: <425E68F6.4020702@highlandsun.com>
Date: Thu, 14 Apr 2005 05:58:30 -0700
From: Howard Chu <hyc@highlandsun.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8b2) Gecko/20050401
MIME-Version: 1.0
To: Vithalprasad Gaitonde <gvithalprasad@novell.com>
Subject: Re: [ldapext] referencing one LDIF file from another
References: <s25e0ace.035@lucius.provo.novell.com>
In-Reply-To: <s25e0ace.035@lucius.provo.novell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
Content-Transfer-Encoding: 7bit

What do you think about using a URL here instead of a simple filename? 
For the common case it would usually be a FILE URL but I think we gain 
some future-proofing by making it fully hyperlinked. It may not be 
useful for utilities that just expect to process static data, but I have 
in mind to use LDAP URLs here as well.

Vithalprasad Gaitonde wrote:
> Howard,
> Following is the change we could do to section "*Formal Syntax 
> Definition of LDIF"
> *
> included-ldif-file-content = "include:" FILL fileName
> ;where the contents of filename confirm to ldif-file of type ldif-content
> 
> included-ldif-file-content = "include:" FILL fileName
> ;where the contents of filename confirm to ldif-file of type ldif-changes
> included-content-ldifs = 1*(1*SEP included-ldif-file-content)
> 
> included-changes-ldifs = 1*(1*SEP included-ldif-file-changes)
> 
> ldif-file = ldif-content / ldif-changes / included-content-ldifs / 
> included-changes-ldifs
> 
> ldif-content = version-spec included-content-ldifs 1*(1*SEP 
> ldif-attrval-record)
> 
> ldif-changes = version-spec included-changes-ldifs 1*(1*SEP 
> ldif-change-record)
> Let me know what you think.
> 
> Thanks,
> Prasad
> 
>  >>> Howard Chu <hyc@highlandsun.com> 11/23/2004 12:33:06 PM >>>
> Vithalprasad Gaitonde wrote:
>  > RFC2849 doesnt seem to provide a way to include one ldif file into
>  > another ldif file though it does allow referencing an external file for
>  > an attribute value.
>  > Has this been considered in the past ?
>  > It seems like a useful thing to have when there are dependencies across
>  > several ldif files.
> 
> I agree, I would definitely have a use for this. Haven't thought about
> what the syntax should be yet.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

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


From ldapext-bounces@ietf.org  Thu Apr 14 09:45:25 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12380
	for <ldapext-archive@lists.ietf.org>; Thu, 14 Apr 2005 09:45:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM4dn-0002S1-QF; Thu, 14 Apr 2005 09:44:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4dl-0002R5-Hb
	for ldapext@megatron.ietf.org; Thu, 14 Apr 2005 09:44:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12248
	for <ldapext@ietf.org>; Thu, 14 Apr 2005 09:44:07 -0400 (EDT)
Received: from lucius.provo.novell.com ([137.65.81.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4nd-0007uz-3t
	for ldapext@ietf.org; Thu, 14 Apr 2005 09:54:29 -0400
Received: from INET-PRV1-MTA by lucius.provo.novell.com
	with Novell_GroupWise; Thu, 14 Apr 2005 07:43:59 -0600
Message-Id: <s25e1f3f.039@lucius.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta
Date: Thu, 14 Apr 2005 07:43:35 -0600
From: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
To: <hyc@highlandsun.com>
Subject: Re: [ldapext] referencing one LDIF file from another
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0836115179=="
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--===============0836115179==
Content-Type: multipart/alternative; boundary="=__Part90B38197.1__="

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part90B38197.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Good point, Howard.
Here's another try: Does this work for you ?

included-ldif-file-content = "include:" FILL url
;where the url points to a file which confirms to ldif-file of type
ldif-content

included-ldif-file-content = "include:" FILL url
;where the url points to a file which confirms to ldif-file of type
ldif-changes

ldif-file = ldif-content / ldif-changes / included-content-ldifs

included-content-ldifs = 1*(1*SEP included-ldif-file-content)

included-changes-ldifs = 1*(1*SEP included-ldif-file-changes)

ldif-content = version-spec included-content-ldifs 1*(1*SEP
ldif-attrval-record)

ldif-changes = version-spec included-changes-ldifs 1*(1*SEP
ldif-change-record)

Prasad

>>> Howard Chu <hyc@highlandsun.com> 04/14/05 6:28 PM >>>
What do you think about using a URL here instead of a simple filename?

For the common case it would usually be a FILE URL but I think we gain

some future-proofing by making it fully hyperlinked. It may not be 
useful for utilities that just expect to process static data, but I
have 
in mind to use LDAP URLs here as well.

Vithalprasad Gaitonde wrote:
> Howard,
> Following is the change we could do to section "*Formal Syntax 
> Definition of LDIF"
> *
> included-ldif-file-content = "include:" FILL fileName
> ;where the contents of filename confirm to ldif-file of type
ldif-content
> 
> included-ldif-file-content = "include:" FILL fileName
> ;where the contents of filename confirm to ldif-file of type
ldif-changes
> included-content-ldifs = 1*(1*SEP included-ldif-file-content)
> 
> included-changes-ldifs = 1*(1*SEP included-ldif-file-changes)
> 
> ldif-file = ldif-content / ldif-changes / included-content-ldifs / 
> included-changes-ldifs
> 
> ldif-content = version-spec included-content-ldifs 1*(1*SEP 
> ldif-attrval-record)
> 
> ldif-changes = version-spec included-changes-ldifs 1*(1*SEP 
> ldif-change-record)
> Let me know what you think.
> 
> Thanks,
> Prasad
> 
> >>> Howard Chu < hyc@highlandsun.com > 11/23/2004 12:33:06 PM >>>
> Vithalprasad Gaitonde wrote:
> > RFC2849 doesnt seem to provide a way to include one ldif file into
> > another ldif file though it does allow referencing an external file
for
> > an attribute value.
> > Has this been considered in the past ?
> > It seems like a useful thing to have when there are dependencies
across
> > several ldif files.
> 
> I agree, I would definitely have a use for this. Haven't thought
about
> what the syntax should be yet.

-- 
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc 
Symas: Premier OpenSource Development and Support

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

--=__Part90B38197.1__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 6.00.2900.2604" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">Good point, =
Howard.<BR>Here's another try: Does this work for you ?<BR><BR>included-ldi=
f-file-content =3D "include:" FILL url<BR>;<STRONG>where the url points to =
a file which confirms to ldif-file of type ldif-content<BR></STRONG><BR>inc=
luded-ldif-file-content =3D "include:" FILL url<BR>;<STRONG>where the url =
points to a file which confirms to ldif-file of type ldif-changes<BR></STRO=
NG><BR>ldif-file =3D ldif-content / ldif-changes / included-content-ldifs<B=
R><BR>included-content-ldifs =3D 1*(1*SEP included-ldif-file-content)<BR><B=
R>included-changes-ldifs =3D 1*(1*SEP included-ldif-file-changes)<BR><BR>ld=
if-content =3D version-spec included-content-ldifs 1*(1*SEP ldif-attrval-re=
cord)<BR><BR>ldif-changes =3D version-spec included-changes-ldifs 1*(1*SEP =
ldif-change-record)<BR><BR>Prasad<BR><BR>&gt;&gt;&gt; Howard Chu &lt;hyc@hi=
ghlandsun.com&gt; 04/14/05 6:28 PM &gt;&gt;&gt;<BR>What do you think about =
using a URL here instead of a simple filename? <BR>For the common case it =
would usually be a FILE URL but I think we gain <BR>some future-proofing =
by making it fully hyperlinked. It may not be <BR>useful for utilities =
that just expect to process static data, but I have <BR>in mind to use =
LDAP URLs here as well.<BR><BR>Vithalprasad Gaitonde wrote:<BR>&gt; =
Howard,<BR>&gt; Following is the change we could do to section "*Formal =
Syntax <BR>&gt; Definition of LDIF"<BR>&gt; *<BR>&gt; included-ldif-file-co=
ntent =3D "include:" FILL fileName<BR>&gt; ;where the contents of filename =
confirm to ldif-file of type ldif-content<BR>&gt; <BR>&gt; included-ldif-fi=
le-content =3D "include:" FILL fileName<BR>&gt; ;where the contents of =
filename confirm to ldif-file of type ldif-changes<BR>&gt; included-content=
-ldifs =3D 1*(1*SEP included-ldif-file-content)<BR>&gt; <BR>&gt; included-c=
hanges-ldifs =3D 1*(1*SEP included-ldif-file-changes)<BR>&gt; <BR>&gt; =
ldif-file =3D ldif-content / ldif-changes / included-content-ldifs / =
<BR>&gt; included-changes-ldifs<BR>&gt; <BR>&gt; ldif-content =3D =
version-spec included-content-ldifs 1*(1*SEP <BR>&gt; ldif-attrval-record)<=
BR>&gt; <BR>&gt; ldif-changes =3D version-spec included-changes-ldifs =
1*(1*SEP <BR>&gt; ldif-change-record)<BR>&gt; Let me know what you =
think.<BR>&gt; <BR>&gt; Thanks,<BR>&gt; Prasad<BR>&gt; <BR>&gt; &gt;&gt;&gt=
; Howard Chu &lt;<U> <A href=3D"mailto:hyc@highlandsun.com">hyc@highlandsun=
.com</A></U> &gt; 11/23/2004 12:33:06 PM &gt;&gt;&gt;<BR>&gt; Vithalprasad =
Gaitonde wrote:<BR>&gt; &gt; RFC2849 doesnt seem to provide a way to =
include one ldif file into<BR>&gt; &gt; another ldif file though it does =
allow referencing an external file for<BR>&gt; &gt; an attribute value.<BR>=
&gt; &gt; Has this been considered in the past ?<BR>&gt; &gt; It seems =
like a useful thing to have when there are dependencies across<BR>&gt; =
&gt; several ldif files.<BR>&gt; <BR>&gt; I agree, I would definitely have =
a use for this. Haven't thought about<BR>&gt; what the syntax should be =
yet.<BR><BR>-- <BR>-- Howard Chu<BR>Chief Architect, Symas Corp. Director, =
Highland Sun<BR><U><A href=3D"http://www.symas.com/">http://www.symas.com</=
A></U> <U><A href=3D"http://highlandsun.com/hyc">http://highlandsun.com/hyc=
</A></U> <BR>Symas: Premier OpenSource Development and Support<BR><BR>_____=
__________________________________________<BR>Ldapext mailing list<BR><U><A=
 href=3D"mailto:Ldapext@ietf.org">Ldapext@ietf.org</A></U> <BR><U><A =
href=3D"https://www1.ietf.org/mailman/listinfo/ldapext">https://www1.ietf.o=
rg/mailman/listinfo/ldapext</A></U> <BR></BODY></HTML>

--=__Part90B38197.1__=--


--===============0836115179==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0836115179==--



From ldapext-bounces@ietf.org  Fri Apr 15 14:12:02 2005
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27806
	for <ldapext-archive@lists.ietf.org>; Fri, 15 Apr 2005 14:12:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMUw3-00083T-Rn; Fri, 15 Apr 2005 13:48:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMUw2-000835-3q
	for ldapext@megatron.ietf.org; Fri, 15 Apr 2005 13:48:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26280
	for <ldapext@ietf.org>; Fri, 15 Apr 2005 13:48:53 -0400 (EDT)
Received: from pat.uio.no ([129.240.130.16] ident=7411)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMV6G-00030A-OA
	for ldapext@ietf.org; Fri, 15 Apr 2005 13:59:29 -0400
Received: from mail-mx1.uio.no ([129.240.10.29])
	by pat.uio.no with esmtp (Exim 4.43)
	id 1DMUvv-0003C9-7M; Fri, 15 Apr 2005 19:48:47 +0200
Received: from bombur.uio.no ([129.240.186.42])
	by mail-mx1.uio.no with esmtp (Exim 4.43)
	id 1DMUvo-0006Uf-Jp; Fri, 15 Apr 2005 19:48:40 +0200
Received: from hbf by bombur.uio.no with local (Exim 4.44)
	id 1DMUvo-0006e3-Ij; Fri, 15 Apr 2005 19:48:40 +0200
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <hbf.20050415pl5t@bombur.uio.no>
Date: Fri, 15 Apr 2005 19:48:40 +0200
To: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
Subject: Re: [ldapext] referencing one LDIF file from another
In-Reply-To: <s25e1f3f.039@lucius.provo.novell.com>
References: <s25e1f3f.039@lucius.provo.novell.com>
X-Mailer: VM 7.18 under Emacs 21.3.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.014, required 12,
	autolearn=disabled, ALL_TRUSTED -2.82, AWL 1.81,
	UIO_MAIL_IS_INTERNAL -5.00)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: ldapext@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Vithalprasad Gaitonde writes:
> Here's another try: Does this work for you ?

As far as I can tell, all LDIF files of your grammar must include
at least one more LDIF file.

It should be possible for a file to include any number of files before
the first change/attrval records, or to contain only include statements
and no change/content records.  So with an "include:" statement one can
no longer see from the grammar whether the file will apply ldif-content
or ldif-changes.

Instead the parser must choose that from the first non-"include:" record
it encounters, possibly in an included file, and the RFC should proably
specify that it is an error if there are both change and content
records.

If we do it that way, I think the grammar can simply be:

  ldif-file    = version-spec 1*(1*SEP ldif-chunk)
  ldif-chunk   = ldif-attrval-record / ldif-change-record / include-ldif
  include-ldif = "include:" FILL url SEP


If implementors want to determine if it is a content or changes file
from looking at the file itself, we could instead have two include
statements:

  include-ldif-content: "include-content:" FILL url SEP
  include-ldif-changes: "include-changes:" FILL url SEP

and the grammar mod would be

  ldif-file                = ldif-content / ldif-changes ; (as before)

  ldif-content             = version-spec 1*(1*SEP ldif-content-chunk)
  ldif-changes             = version-spec 1*(1*SEP ldif-change-chunk)

  ldif-content-chunk       = ldif-attrval-record / include-ldif-content
  ldif-change-chunk        = ldif-change-record  / include-ldif-changes

-- 
Hallvard

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