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 ; 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 ; 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: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Fri, 01 Apr 2005 00:01:33 -0700 From: "Vithalprasad Gaitonde" To: , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

Kurt,
This section says:
A Password Modify request is an=20 ExtendedRequest with the requestName
field containing passwdModifyOID = OID and=20 optionally provides a
requestValue field.
The rfc = does=20 not specify what is the expected server behaviour when the extension = contains=20 only the passwdModifyOID and no value.

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.

Also in section 2, the rfc says:

If oldPasswd is present and the provided value cannot = be=20 verified or
is incorrect, the server SHALL NOT change the = user=20 password.

In this case, what is the LDAP error that the server should send bac = to the=20 client.

Prasad

--=__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 ; 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 ; 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" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] RFC 3062 section 2.1 and section 3 In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 ; 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 and editorial comments to . 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 > > > >_______________________________________________ >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 ; 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 ; 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: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Thu, 14 Apr 2005 06:16:14 -0600 From: "Vithalprasad Gaitonde" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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

Howard,
Following is the change we could do to section "For= mal=20 Syntax Definition of LDIF"

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

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

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

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

ldif-file =3D ldif-content / ldif-change= s /=20 included-content-ldifs / included-changes-ldifs

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

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

Let me know what you think.

Thanks,

Prasad

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

I agree, I would definitely have a use for = this.=20 Haven't thought about
what the syntax should be yet.

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

_______________________________________________
Ldapext= =20 mailing list
Ldapext@ietf.org= =20
https://www1.ietf.o= rg/mailman/listinfo/ldapext=20

--=__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 ; 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 ; 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 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 Subject: Re: [ldapext] referencing one LDIF file from another References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 ; 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 ; 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: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Thu, 14 Apr 2005 07:43:35 -0600 From: "Vithalprasad Gaitonde" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 Good point, = Howard.
Here's another try: Does this work for you ?

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

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

ldif-file =3D ldif-content / ldif-changes / included-content-ldifs
included-content-ldifs =3D 1*(1*SEP included-ldif-file-content)
included-changes-ldifs =3D 1*(1*SEP included-ldif-file-changes)

ld= if-content =3D version-spec included-content-ldifs 1*(1*SEP ldif-attrval-re= cord)

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

Prasad

>>> Howard Chu <hyc@hi= ghlandsun.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-co= ntent =3D "include:" FILL fileName
> ;where the contents of filename = confirm to ldif-file of type ldif-content
>
> included-ldif-fi= le-content =3D "include:" FILL fileName
> ;where the contents of = filename confirm to ldif-file of type ldif-changes
> included-content= -ldifs =3D 1*(1*SEP included-ldif-file-content)
>
> included-c= hanges-ldifs =3D 1*(1*SEP included-ldif-file-changes)
>
> = ldif-file =3D ldif-content / ldif-changes / included-content-ldifs / =
> included-changes-ldifs
>
> ldif-content =3D = version-spec included-content-ldifs 1*(1*SEP
> ldif-attrval-record)<= BR>>
> ldif-changes =3D 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.o= rg/mailman/listinfo/ldapext
--=__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 ; 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 ; 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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 15 Apr 2005 19:48:40 +0200 To: "Vithalprasad Gaitonde" Subject: Re: [ldapext] referencing one LDIF file from another In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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