If LDIF were extended to allow (at least) DN replacement, this would = allow an LDIF to be used to update schema (without the LDIF being modified = for each DSA it is to be applied to). Something like an assignment = directive in form of a search URL could be used to assign a value to a = variable, then that variable could be used in subsequent LDIF records.

Is there any effort underway to do something like this?

Jim

--=__Part7252B3C1.0__=-- --===============1128915827== 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 --===============1128915827==-- From ldapext-bounces@ietf.org Sun Nov 7 23:26:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03630 for ; Sun, 7 Nov 2004 23:26:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR0wD-00029B-LX; Sun, 07 Nov 2004 23:15:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR0vI-00020x-B2 for ldapext@megatron.ietf.org; Sun, 07 Nov 2004 23:14:32 -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 XAA03255 for ; Sun, 7 Nov 2004 23:14:29 -0500 (EST) Received: from mail17.ca.com ([155.35.248.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR0vk-00058p-Gc for ldapext@ietf.org; Sun, 07 Nov 2004 23:15:01 -0500 Received: from ausyms21.ca.com ([155.35.201.5]) by mail17.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Nov 2004 15:13:58 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Subentries as children of the root Date: Mon, 8 Nov 2004 15:13:57 +1100 Message-ID: <1395B4B334FCC143B36AF788E68B638101FA55BB@ausyms21.ca.com> Thread-Topic: [ldapext] Subentries as children of the root Thread-Index: AcTEYB/ZuS5sqCJGQVyD9MTmLM5+OgA52UbA From: "Ramsay, Ron" To: "Jim Sermersheim" , X-OriginalArrivalTime: 08 Nov 2004 04:13:58.0218 (UTC) FILETIME=[5E838AA0:01C4C549] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: Steve McLain 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: quoted-printable 1) I would never expect the root DSE to be returned in a subtree search = from the root, so I don't see the business of referring the request to a = first-level DSA as relevant. A base-object search I would expect to = return an error unless the manageDSAIT bit is set, when it would perform = the reqest locally. I don't believe there is any DSA that can hold a = global root DSE. But I have no authority for this statement. 2.1) Surely, accessing a xr DSE using manageDSAIT will return the = reference and not the actual entry. That is, manageDSAIT allows access = to metadata, not privileged access to the entry (which is remote, so how = could it, unless it chained it, but you wouldn't expect manageDSAIT to = act in this manner). 3) But cn=3Dschema is not a subentry! At this point there is no = correlation between LDAP and X.500. I don't believe the root can be = either supr or admPoint. Just my $0.02 worth. Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Sunday, 7 November 2004 05:06 To: ldapext@ietf.org Cc: Steve McLain Subject: [ldapext] Subentries as children of the root A little over a month ago, in the thread "when is manageDsaIT needed for the root DSE?" I failed to take the next logical step in discussing what it means for the rootDSE to be treated as a non-local object. I actually have a few observations: =20 1) The root isn't *always* treated as non-local. If one uses the empty RDN sequence for a search base and a scope of wholeSubtree, they will get referred up until they are talking to a first-level DSA. Then the search will progress down the tree structure (See X.511, Clause 10.2.2). In X.511, it doesn't matter what the scope (subset) is. I infer that when the scope is baseObject proper X.500 DSAs will refer unless it's a first-level DSA, in which case the rootDSE is NOT treated as non-local, and may be returned (I would appreciate feedback here if I'm wrong). 1.1) (aside) In LDAP, if the scope is baseObject, and the filter is (objectclass=3D*), ManageDsaIT is assumed, and the rootDSE is returned. 2) We typically see that a DSE below a non-local entry is itself glue, cp, or xr. Essentially, if a DSE immediately subordinate to a non-local DSE is not a cp, ManageDsaIT is required to access it. 2.1) A different way of putting it (which produce different semantics) is that ManageDsaIT is required to access DSEs not part of any locally held naming context. This definition says that ManageDsaIT is always required to read the root object (even on first-level DSAs) 3) Many LDAP servers advertise a schema subentry immediately subordinate to the root (i.e. cn=3Dschema). To me, this says that the rootDSE is an admPoint and it's administrativeRole attribute is set to id-ar-subschemaAdminSpecificArea. Is it legal, on a non-first-level DSA for the rootDSE to be supr, admPoint, and root? 4) Assuming I'm correct on 1 and 2, and assuming people are not marking their subschema subentries as being a cp, then I assume ManageDsaIT is required to read these schema subentries (unless one is accessing a first-level DSA). This also means, that a wholeSubtree search from the root of the tree with the search subentries control present, and the ManageDsaIT control not present will return the root schema subentry for the first-level DSA, but no others (assuming these DSAs all have a schema subentry immediately subordinate to the root). 4.1) If 2.1 is more correct than 2, then ManageDsaIT is consistently required to read subentries immediately subordinate to the root. Or am I missing something that says "a subentry which is not part of a local naming context does not require ManageDsaIT to be read"? Jim _______________________________________________ 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 Mon Nov 8 00:12:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06300 for ; Mon, 8 Nov 2004 00:12:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR1fP-0008W3-Bg; Mon, 08 Nov 2004 00:02:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR1ep-0008Mk-Pm for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 00:01:35 -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 AAA05640 for ; Mon, 8 Nov 2004 00:01:32 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR1fI-00061Q-Kd for ldapext@ietf.org; Mon, 08 Nov 2004 00:02:05 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Sun, 07 Nov 2004 22:00:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Sun, 07 Nov 2004 22:00:17 -0700 From: "Jim Sermersheim" To: , Subject: RE: [ldapext] Subentries as children of the root Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: Steve McLain 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="===============0886355891==" 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. --===============0886355891== Content-Type: multipart/alternative; boundary="=__Part2B0BE971.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. --=__Part2B0BE971.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> "Ramsay, Ron" 11/7/04 11:13:57 PM >>> >1) I would never expect the root DSE to be returned in a subtree search from the root, so I don't see the business of referring the request to a first-level DSA as relevant. Referring the request is needed to service the intended operation. X.511, Clause 10.2.2 is clear that one may perform a subtree search from the tree root using an empty base. If a non-first-level DSA receives such a request, it must refer up (the sender wants the search to apply to the entire tree). I could be (and suspect I am) wrong about the root being returned on a first-level DSA in absence of ManageDsaIT. >A base-object search I would expect to return an error unless the manageDSAIT bit is set, when it would perform the reqest locally. I don't believe there is any DSA that can hold a global root DSE. But I have no authority for this statement. >2.1) Surely, accessing a xr DSE using manageDSAIT will return the reference and not the actual entry. That is, manageDSAIT allows access to metadata, not privileged access to the entry (which is remote, so how could it, unless it chained it, but you wouldn't expect manageDSAIT to act in this manner). I would shy away from saying "ManageDsaIT allows access to metadata". Lots of things can be considered to be metadata (stuff in subentries for example). Also, "the actual entry" is misleading. A locally held DSE (which happens to be of type xr) is still an "actual entry" and an "entry", it's just not the object entry. I prefer the definition in 2.1, or maybe the revised: "ManageDsaIT is required to access local DSEs not part of any locally held naming context" >3) But cn=schema is not a subentry! At this point there is no correlation between LDAP and X.500. I don't believe the root can be either supr or admPoint. You may be right in saying that an object named cn=schema cannot be a subentry, and that root is never an admPoint (though I'd like to see evidence supporting these assertions), but certainly root can be (and often is) a supr. >Just my $0.02 worth. > >Ron Jim -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Sunday, 7 November 2004 05:06 To: ldapext@ietf.org Cc: Steve McLain Subject: [ldapext] Subentries as children of the root A little over a month ago, in the thread "when is manageDsaIT needed for the root DSE?" I failed to take the next logical step in discussing what it means for the rootDSE to be treated as a non-local object. I actually have a few observations: 1) The root isn't *always* treated as non-local. If one uses the empty RDN sequence for a search base and a scope of wholeSubtree, they will get referred up until they are talking to a first-level DSA. Then the search will progress down the tree structure (See X.511, Clause 10.2.2). In X.511, it doesn't matter what the scope (subset) is. I infer that when the scope is baseObject proper X.500 DSAs will refer unless it's a first-level DSA, in which case the rootDSE is NOT treated as non-local, and may be returned (I would appreciate feedback here if I'm wrong). 1.1) (aside) In LDAP, if the scope is baseObject, and the filter is (objectclass=*), ManageDsaIT is assumed, and the rootDSE is returned. 2) We typically see that a DSE below a non-local entry is itself glue, cp, or xr. Essentially, if a DSE immediately subordinate to a non-local DSE is not a cp, ManageDsaIT is required to access it. 2.1) A different way of putting it (which produce different semantics) is that ManageDsaIT is required to access DSEs not part of any locally held naming context. This definition says that ManageDsaIT is always required to read the root object (even on first-level DSAs) 3) Many LDAP servers advertise a schema subentry immediately subordinate to the root (i.e. cn=schema). To me, this says that the rootDSE is an admPoint and it's administrativeRole attribute is set to id-ar-subschemaAdminSpecificArea. Is it legal, on a non-first-level DSA for the rootDSE to be supr, admPoint, and root? 4) Assuming I'm correct on 1 and 2, and assuming people are not marking their subschema subentries as being a cp, then I assume ManageDsaIT is required to read these schema subentries (unless one is accessing a first-level DSA). This also means, that a wholeSubtree search from the root of the tree with the search subentries control present, and the ManageDsaIT control not present will return the root schema subentry for the first-level DSA, but no others (assuming these DSAs all have a schema subentry immediately subordinate to the root). 4.1) If 2.1 is more correct than 2, then ManageDsaIT is consistently required to read subentries immediately subordinate to the root. Or am I missing something that says "a subentry which is not part of a local naming context does not require ManageDsaIT to be read"? Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part2B0BE971.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 11/7/04 11:13:57 = PM >>>
>1) I would never expect the root DSE to be returned = in a subtree search from the root, so I don't see the business of = referring the request to a first-level DSA as relevant.

Referring the request is needed to service the intended operation. = X.511, Clause 10.2.2 is clear that one may perform a subtree search from = the tree root using an empty base. If a non-first-level DSA receives such = a request, it must refer up (the sender wants the search to apply to = the entire tree). I could be (and suspect I am) wrong about the root being = returned on a first-level DSA in absence of ManageDsaIT.

>A base-object search I would expect to return an error unless the = manageDSAIT bit is set, when it would perform the reqest locally. I don't = believe there is any DSA that can hold a global root DSE. But I have no = authority for this statement.

>2.1) Surely, accessing a xr DSE = using manageDSAIT will return the reference and not the actual entry. That = is, manageDSAIT allows access to metadata, not privileged access to the = entry (which is remote, so how could it, unless it chained it, but you = wouldn't expect manageDSAIT to act in this manner).

I would shy away from saying "ManageDsaIT allows access to metadata". = Lots of things can be considered to be metadata (stuff in subentries for = example). Also, "the actual entry" is misleading. A locally held DSE = (which happens to be of type xr) is still an "actual entry" and an = "entry", it's just not the object entry. I prefer the definition in 2.1, = or maybe the revised:

"ManageDsaIT is required to access local DSEs not part of any locally = held naming context"

>3) But cn=3Dschema is not a subentry! At this point there is = no correlation between LDAP and X.500. I don't believe the root can be = either supr or admPoint.

You may be right in saying that an object named cn=3Dschema cannot be = a subentry, and that root is never an admPoint (though I'd like to see = evidence supporting these assertions), but certainly root can be (and = often is) a supr.

>Just my $0.02 worth.
>
>Ron

Jim

-----Original Message-----
From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On
Behalf Of Jim Sermersheim
Sent: Sunday, 7 November 2004 05:06
T= o: ldapext@ietf.org
Cc: = Steve McLain
Subject: [ldapext] Subentries as children of the root

A little over a month ago, in the thread "when is manageDsaIT needed = for
the root DSE?" I failed to take the next logical step in discussing = what
it means for the rootDSE to be treated as a non-local object. I = actually
have a few observations:

1) The root isn't *always* = treated as non-local. If one uses the empty
RDN sequence for a search = base and a scope of wholeSubtree, they will
get referred up until they = are talking to a first-level DSA. Then the
search will progress down = the tree structure (See X.511, Clause 10.2.2).
In X.511, it doesn't = matter what the scope (subset) is. I infer that
when the scope is = baseObject proper X.500 DSAs will refer unless it's a
first-level DSA, = in which case the rootDSE is NOT treated as non-local,
and may be = returned (I would appreciate feedback here if I'm wrong).

1.1) = (aside) In LDAP, if the scope is baseObject, and the filter is
(objectcl= ass=3D*), ManageDsaIT is assumed, and the rootDSE is returned.

2) = We typically see that a DSE below a non-local entry is itself glue,
cp, = or xr. Essentially, if a DSE immediately subordinate to a non-local
DSE = is not a cp, ManageDsaIT is required to access it.

2.1) A different = way of putting it (which produce different semantics)
is that ManageDsaI= T is required to access DSEs not part of any locally
held naming = context. This definition says that ManageDsaIT is always
required to = read the root object (even on first-level DSAs)

3) Many LDAP = servers advertise a schema subentry immediately
subordinate to the root = (i.e. cn=3Dschema). To me, this says that the
rootDSE is an admPoint = and it's administrativeRole attribute is set to
id-ar-subschemaAdminSpec= ificArea. Is it legal, on a non-first-level DSA
for the rootDSE to be = supr, admPoint, and root?

4) Assuming I'm correct on 1 and 2, and = assuming people are not marking
their subschema subentries as being a = cp, then I assume ManageDsaIT is
required to read these schema = subentries (unless one is accessing a
first-level DSA). This also = means, that a wholeSubtree search from the
root of the tree with the = search subentries control present, and the
ManageDsaIT control not = present will return the root schema subentry for
the first-level DSA, = but no others (assuming these DSAs all have a
schema subentry immediatel= y subordinate to the root).

4.1) If 2.1 is more correct than 2, = then ManageDsaIT is consistently
required to read subentries immediately= subordinate to the root.

Or am I missing something that says "a = subentry which is not part of a
local naming context does not require = ManageDsaIT to be read"?

Jim

________________________________= _______________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext

--=__Part2B0BE971.1__=-- --===============0886355891== 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 --===============0886355891==-- From ldapext-bounces@ietf.org Mon Nov 8 08:36:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05818 for ; Mon, 8 Nov 2004 08:36:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9Qo-0006tB-Eu; Mon, 08 Nov 2004 08:19:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9MC-0006AB-Js for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 08:14:52 -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 IAA03618 for ; Mon, 8 Nov 2004 08:14:50 -0500 (EST) Received: from du-005-009.access.de.clara.net ([212.82.228.9] helo=nb2.stroeder.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR9MZ-0008L7-DI for ldapext@ietf.org; Mon, 08 Nov 2004 08:15:26 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 99D002C823; Mon, 8 Nov 2004 09:15:25 +0100 (CET) Message-ID: <418F2B1D.7050508@stroeder.com> Date: Mon, 08 Nov 2004 09:15:25 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Dynamic values in LDIF References: In-Reply-To: X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Jim Sermersheim wrote: > > It's difficult (well, impossible I guess) to write an LDIF file which > can be used to update schema because one never knows the name of the > subschema subentry in effect for the object(s) for which the schema > is being updated. (I'm assuming a DSA which can modify schema. i.e. > X.501(93) Clause 14.5). There's not a single sub schema sub entry. In fact there could be many. => you have to know something a priory about the DSA before updating one of its sub schema sub entries. > Is there any effort underway to do something like this? Frankly I don't believe it's worth to think about something like this any further. If you modify something like the sub schema via LDAP you already implemented kind of a LDAP client and pointed it to a specific server. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Nov 8 08:38:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06138 for ; Mon, 8 Nov 2004 08:38:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9Tj-0007FK-TI; Mon, 08 Nov 2004 08:22:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9Nq-0006WD-EL for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 08:16:34 -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 IAA03833 for ; Mon, 8 Nov 2004 08:16:32 -0500 (EST) Received: from du-005-011.access.de.clara.net ([212.82.228.11] helo=nb2.stroeder.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR9ON-0008Qc-25 for ldapext@ietf.org; Mon, 08 Nov 2004 08:17:08 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 99D002C823; Mon, 8 Nov 2004 09:15:25 +0100 (CET) Message-ID: <418F2B1D.7050508@stroeder.com> Date: Mon, 08 Nov 2004 09:15:25 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Dynamic values in LDIF References: In-Reply-To: X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Jim Sermersheim wrote: > > It's difficult (well, impossible I guess) to write an LDIF file which > can be used to update schema because one never knows the name of the > subschema subentry in effect for the object(s) for which the schema > is being updated. (I'm assuming a DSA which can modify schema. i.e. > X.501(93) Clause 14.5). There's not a single sub schema sub entry. In fact there could be many. => you have to know something a priory about the DSA before updating one of its sub schema sub entries. > Is there any effort underway to do something like this? Frankly I don't believe it's worth to think about something like this any further. If you modify something like the sub schema via LDAP you already implemented kind of a LDAP client and pointed it to a specific server. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Nov 8 10:08:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16688 for ; Mon, 8 Nov 2004 10:08:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAu6-0002mw-TB; Mon, 08 Nov 2004 09:53:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAoZ-0000qP-A6 for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 09:48:15 -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 JAA14573 for ; Mon, 8 Nov 2004 09:48:13 -0500 (EST) Received: from murdock.dreamhost.com ([66.33.205.6] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAp7-0002to-Vb for ldapext@ietf.org; Mon, 08 Nov 2004 09:48:50 -0500 Received: from [127.0.0.1] (pcp04149991pcs.sanarb01.mi.comcast.net [68.41.54.14]) by murdock.dreamhost.com (Postfix) with ESMTP id E249116D259; Mon, 8 Nov 2004 06:48:06 -0800 (PST) Message-ID: <418F871F.2090102@pearlcrescent.com> Date: Mon, 08 Nov 2004 09:47:59 -0500 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Dynamic values in LDIF References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 We discussed some ideas along these lines when I was at Netscape. Our conclusion was that this took LDIF too close to a scripting language, and that standardization of such a thing probably would be difficult. But no one can stop you from trying ;-) -Mark Jim Sermersheim wrote: > It's difficult (well, impossible I guess) to write an LDIF file which > can be used to update schema because one never knows the name of the > subschema subentry in effect for the object(s) for which the schema is > being updated. (I'm assuming a DSA which can modify schema. i.e. > X.501(93) Clause 14.5). > > If LDIF were extended to allow (at least) DN replacement, this would > allow an LDIF to be used to update schema (without the LDIF being > modified for each DSA it is to be applied to). Something like an > assignment directive in form of a search URL could be used to assign a > value to a variable, then that variable could be used in subsequent LDIF > records. > > Is there any effort underway to do something like this? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Nov 8 14:13:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15887 for ; Mon, 8 Nov 2004 14:13:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREbe-0007i2-1c; Mon, 08 Nov 2004 13:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREPm-0004rd-V6 for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 13:38:55 -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 NAA10900 for ; Mon, 8 Nov 2004 13:38:51 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREQN-0001AR-1m for ldapext@ietf.org; Mon, 08 Nov 2004 13:39:32 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 08 Nov 2004 11:38:22 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Mon, 08 Nov 2004 11:37:57 -0700 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Dynamic values in LDIF Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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="===============1115776761==" 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. --===============1115776761== Content-Type: multipart/alternative; boundary="=__Part0E2ECD15.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. --=__Part0E2ECD15.0__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>> Michael Str=F6der 11/8/04 3:15:25 AM >>> >Jim Sermersheim wrote: >>=20 >> It's difficult (well, impossible I guess) to write an LDIF file which >> can be used to update schema because one never knows the name of the >> subschema subentry in effect for the object(s) for which the schema >> is being updated. (I'm assuming a DSA which can modify schema. i.e.=20 >> X.501(93) Clause 14.5). > >There's not a single sub schema sub entry. In fact there could be many. >=3D> you have to know something a priory about the DSA before updating = one=20 >of its sub schema sub entries. Exactly (thus the "in effect for the object(s)" bit). This is why I'm = wondering about a mechanism to (apriori) gather the knowledge needed to = update the schema which the application intends to update. >> Is there any effort underway to do something like this? > >Frankly I don't believe it's worth to think about something like this=20 >any further. If you modify something like the sub schema via LDAP you=20 >already implemented kind of a LDAP client and pointed it to a specific=20 >server. I apparently worded my message poorly. My intent is to NOT have to = implement anything other than an LDIF file. >Ciao, Michael. Jim --=__Part0E2ECD15.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

>>>> Michael Str=F6der <michael@stroeder.com> = 11/8/04 3:15:25 AM >>>
>Jim Sermersheim wrote:
>> =
>> It's difficult (well, impossible I guess) to write an LDIF = file which
>> can be used to update schema because one never = knows the name of the
>> subschema subentry in effect for the = object(s) for which the schema
>> is being updated. (I'm assuming = a DSA which can modify schema. i.e.
>> X.501(93) Clause = 14.5).
>
>There's not a single sub schema sub entry. In fact = there could be many.
>=3D> you have to know something a priory = about the DSA before updating one
>of its sub schema sub entries.

Exactly (thus the "in effect for the object(s)" bit). This is why I'm = wondering about a mechanism to (apriori) gather the knowledge needed = to update the schema which the application intends to update.

>> Is there any effort underway to do something like = this?
>
>Frankly I don't believe it's worth to think about = something like this
>any further. If you modify something like the = sub schema via LDAP you
>already implemented kind of a LDAP client = and pointed it to a specific
>server.

I apparently worded my message poorly. My intent is to NOT have to = implement anything other than an LDIF file.

>Ciao, Michael.

Jim

--=__Part0E2ECD15.0__=-- --===============1115776761== 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 --===============1115776761==-- From ldapext-bounces@ietf.org Mon Nov 8 14:13:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16011 for ; Mon, 8 Nov 2004 14:13:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREbs-0007mI-7B; Mon, 08 Nov 2004 13:51:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRESU-0005WE-3I for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 13:41:42 -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 NAA11161 for ; Mon, 8 Nov 2004 13:41:40 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRET4-0001Fv-OQ for ldapext@ietf.org; Mon, 08 Nov 2004 13:42:19 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 08 Nov 2004 11:41:10 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Mon, 08 Nov 2004 11:40:45 -0700 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Dynamic values in LDIF Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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="===============1478086577==" 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. --===============1478086577== Content-Type: multipart/alternative; boundary="=__PartA68665BD.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. --=__PartA68665BD.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Rats, I was hoping _not_ to be the one trying this. >>> Mark Smith 11/8/04 9:47:59 AM >>> We discussed some ideas along these lines when I was at Netscape. Our conclusion was that this took LDIF too close to a scripting language, and that standardization of such a thing probably would be difficult. But no one can stop you from trying ;-) -Mark Jim Sermersheim wrote: > It's difficult (well, impossible I guess) to write an LDIF file which > can be used to update schema because one never knows the name of the > subschema subentry in effect for the object(s) for which the schema is > being updated. (I'm assuming a DSA which can modify schema. i.e. > X.501(93) Clause 14.5). > > If LDIF were extended to allow (at least) DN replacement, this would > allow an LDIF to be used to update schema (without the LDIF being > modified for each DSA it is to be applied to). Something like an > assignment directive in form of a search URL could be used to assign a > value to a variable, then that variable could be used in subsequent LDIF > records. > > Is there any effort underway to do something like this? --=__PartA68665BD.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rats, I was hoping = _not_ to be the one trying this.

>>> Mark Smith <mcs@pea= rlcrescent.com> 11/8/04 9:47:59 AM >>>
We discussed some = ideas along these lines when I was at Netscape. Our
conclusion was = that this took LDIF too close to a scripting language,
and that = standardization of such a thing probably would be difficult.
But no = one can stop you from trying ;-)

-Mark

Jim Sermersheim = wrote:
> It's difficult (well, impossible I guess) to write an LDIF = file which
> can be used to update schema because one never knows = the name of the
> subschema subentry in effect for the object(s) = for which the schema is
> being updated. (I'm assuming a DSA which = can modify schema. i.e.
> X.501(93) Clause 14.5).
>
> = If LDIF were extended to allow (at least) DN replacement, this would =
> allow an LDIF to be used to update schema (without the LDIF being =
> modified for each DSA it is to be applied to). Something like an =
> assignment directive in form of a search URL could be used to = assign a
> value to a variable, then that variable could be used in = subsequent LDIF
> records.
>
> Is there any effort = underway to do something like this?

--=__PartA68665BD.0__=-- --===============1478086577== 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 --===============1478086577==-- From ldapext-bounces@ietf.org Mon Nov 8 15:08:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23421 for ; Mon, 8 Nov 2004 15:08:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFWW-0006QX-02; Mon, 08 Nov 2004 14:49:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFEj-0001HH-IS for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 14:31:33 -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 OAA18031 for ; Mon, 8 Nov 2004 14:31:31 -0500 (EST) Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFFK-0002r4-Gw for ldapext@ietf.org; Mon, 08 Nov 2004 14:32:11 -0500 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 4275139440 for ; Mon, 8 Nov 2004 20:31:24 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19676-01-97 for ; Mon, 8 Nov 2004 20:31:24 +0100 (CET) Received: from [130.129.134.141] (unknown [130.129.134.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id E8C5F384FD for ; Mon, 8 Nov 2004 20:31:23 +0100 (CET) Message-ID: <418FC986.7010701@it.su.se> Date: Mon, 08 Nov 2004 20:31:18 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: sv, en, en-us MIME-Version: 1.0 To: "'ldapext@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at su.se X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: [ldapext] dc+idn 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 Could someone summarize the state of affairs with "internationalized dc"? It seems to me that there is an urgent need looming here. MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Nov 8 15:29:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26318 for ; Mon, 8 Nov 2004 15:29:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFoz-0001Aq-9j; Mon, 08 Nov 2004 15:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFcT-0007Ok-Jo for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 14:56:05 -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 OAA21641 for ; Mon, 8 Nov 2004 14:56:03 -0500 (EST) Received: from d0-156.vdsl.isp-service.de ([83.122.0.156] helo=nb2.stroeder.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFcu-0003f9-H7 for ldapext@ietf.org; Mon, 08 Nov 2004 14:56:43 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 82CF7CE8E1; Mon, 8 Nov 2004 20:54:04 +0100 (CET) Message-ID: <418FCEDB.3010405@stroeder.com> Date: Mon, 08 Nov 2004 20:54:03 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Dynamic values in LDIF References: In-Reply-To: X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Jim Sermersheim wrote: >=20 > >>>> Michael Str=F6der 11/8/04 3:15:25 AM >>> > >Jim Sermersheim wrote: > >> > >> It's difficult (well, impossible I guess) to write an LDIF file whi= ch > >> can be used to update schema because one never knows the name of th= e > >> subschema subentry in effect for the object(s) for which the schema= > >> is being updated. (I'm assuming a DSA which can modify schema. i.e.= > >> X.501(93) Clause 14.5). > > > >There's not a single sub schema sub entry. In fact there could be man= y. > >=3D> you have to know something a priory about the DSA before updatin= g one > >of its sub schema sub entries. > Exactly (thus the "in effect for the object(s)" bit). This is why I'm=20 > wondering about a mechanism to (apriori) gather the knowledge needed to= =20 > update the schema which the application intends to update. Kind of a mind-reading machine? ;-) Well, if someone would like to implement a generic sub schema modifying=20 program this would need as input params to modify a certain sub schema=20 at least: - machine (host:port) - naming context - authentication credentials - some connection-oriented stuff (e.g. LDAPS to a separate port) Frankly I have no clue how these params could be guessed. They are given = at run-time by an admin who simply knows them. Now if you invoke a=20 program with params you can't guess you can easily implement all your=20 sub schema modifications in that program. > I apparently worded my message poorly. My intent is to NOT have to=20 > implement anything other than an LDIF file. I can imagine quite well what you want. IMO it's simply not possible=20 without some program interpreting the LDIF data within some context=20 known a priori. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Nov 8 15:30:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26450 for ; Mon, 8 Nov 2004 15:30:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFp6-0001FS-Mp; Mon, 08 Nov 2004 15:09:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFdy-0007TZ-Da for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 14:57:38 -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 OAA21746 for ; Mon, 8 Nov 2004 14:57:36 -0500 (EST) Received: from d0-156.vdsl.isp-service.de ([83.122.0.156] helo=nb2.stroeder.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFeZ-0003hF-Hk for ldapext@ietf.org; Mon, 08 Nov 2004 14:58:16 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 546FCCE8E1; Mon, 8 Nov 2004 20:55:50 +0100 (CET) Message-ID: <418FCF46.30706@stroeder.com> Date: Mon, 08 Nov 2004 20:55:50 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Mark Smith Subject: Re: [ldapext] Dynamic values in LDIF References: <418F871F.2090102@pearlcrescent.com> In-Reply-To: <418F871F.2090102@pearlcrescent.com> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, Jim Sermersheim 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 Mark Smith wrote: > We discussed some ideas along these lines when I was at Netscape. Our > conclusion was that this took LDIF too close to a scripting language, ;-) > and that standardization of such a thing probably would be difficult. > But no one can stop you from trying ;-) Even when blowing up LDIF to a powerful scripting language this "LDIF script" would need DSA-specific input parameters (see my other response). Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Nov 8 17:22:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09775 for ; Mon, 8 Nov 2004 17:22:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHdO-0003ix-Hj; Mon, 08 Nov 2004 17:05:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHQR-0000lj-Mh for ldapext@megatron.ietf.org; Mon, 08 Nov 2004 16:51:49 -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 QAA06576 for ; Mon, 8 Nov 2004 16:51:45 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHR2-00075b-IS for ldapext@ietf.org; Mon, 08 Nov 2004 16:52:26 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 08 Nov 2004 14:51:14 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Mon, 08 Nov 2004 14:50:50 -0700 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Dynamic values in LDIF Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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="===============1337638717==" 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. --===============1337638717== Content-Type: multipart/alternative; boundary="=__Part6646A52A.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. --=__Part6646A52A.0__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael, =20 As I said, my original post must be lacking... =20 What I'm asking for is something like this: =20 1) An LDIF assignment record. This could look like other LDIF records = except there would be no changetype. It might looks something like this: =20 # the application updating schema assumes dc=3Dexample,dc=3Dcom exists. It = is going to update schema for this entry # if the application plans to update schema for objects subordinate to = this, it assumes that the schema AP for this entry also # applies to the subtree below it. If it cannot make this assumption, it = can perform this assignment/schema update combination # for each entry it plans to update. dn: dc=3Dexample,dc=3Dcom recordtype: assign myBase: subschemaSubentry =20 2) An LDIF substitution mechanism. This could be anything, but I'm using = the url construct as a simple example. It might look like: =20 dn: changetype: add # remainder of record to update the schema governing dc=3Dexample,dc=3Dcom If the subschemaSubentry attribute on dc=3Dexample,dc=3Dcom is cn=3Dschema,= dc=3Dcom, it will be substituted as the dn value for the change record. =20 Note that the machine (host:port), authN credentials, and connection-orient= ed stuff is handled by the tool (like ldapmodify) being used to apply the = ldif. The assignment record assumes the DSA to which the ldif is being = applied. =20 But I doubt anyone with the time to extend LDIF is going to pick this up, = so it doesn't matter anyway. =20 Jim >>> Michael Str=F6der 11/8/04 2:54:03 PM >>> Jim Sermersheim wrote: >=20 > >>>> Michael Str=F6der < michael@stroeder.com > 11/8/04 3:15:25 AM >>> > >Jim Sermersheim wrote: > >> > >> It's difficult (well, impossible I guess) to write an LDIF file which > >> can be used to update schema because one never knows the name of the > >> subschema subentry in effect for the object(s) for which the schema > >> is being updated. (I'm assuming a DSA which can modify schema. i.e. > >> X.501(93) Clause 14.5). > > > >There's not a single sub schema sub entry. In fact there could be many. > >=3D> you have to know something a priory about the DSA before updating = one > >of its sub schema sub entries. > Exactly (thus the "in effect for the object(s)" bit). This is why I'm=20 > wondering about a mechanism to (apriori) gather the knowledge needed = to=20 > update the schema which the application intends to update. Kind of a mind-reading machine? ;-) Well, if someone would like to implement a generic sub schema modifying=20 program this would need as input params to modify a certain sub schema=20 at least: - machine (host:port) - naming context - authentication credentials - some connection-oriented stuff (e.g. LDAPS to a separate port) Frankly I have no clue how these params could be guessed. They are = given=20 at run-time by an admin who simply knows them. Now if you invoke a=20 program with params you can't guess you can easily implement all your=20 sub schema modifications in that program. > I apparently worded my message poorly. My intent is to NOT have to=20 > implement anything other than an LDIF file. I can imagine quite well what you want. IMO it's simply not possible=20 without some program interpreting the LDIF data within some context=20 known a priori. Ciao, Michael. --=__Part6646A52A.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Michael,

As I said, my original post must be lacking...

What I'm asking for is something like this:

1) An LDIF assignment record. This could look like other LDIF records = except there would be no changetype. It might looks something like = this:

# the application updating schema assumes dc=3Dexample,dc=3Dcom = exists. It is going to update schema for this entry

# if the application plans to update schema for objects subordinate = to this, it assumes that the schema AP for this entry also

# applies to the subtree below it. If it cannot make this assumption, = it can perform this assignment/schema update combination

# for each entry it plans to update.

dn: dc=3Dexample,dc=3Dcom

recordtype: assign

myBase: subschemaSubentry

2) An LDIF substitution mechanism. This could be anything, but I'm = using the url construct as a simple example. It might look like:

dn: <localfile:///myBase>

changetype: add
# remainder of record to update the schema gov= erning dc=3Dexample,dc=3Dcom

If the subschemaSubentry attribute on dc=3Dexample,dc=3Dcom is = cn=3Dschema,dc=3Dcom, it will be substituted as the dn value for the = change record.

Note that the machine (host:port), authN credentials, and connection-o= riented stuff is handled by the tool (like ldapmodify) being used to apply = the ldif. The assignment record assumes the DSA to which the ldif is being = applied.

But I doubt anyone with the time to extend LDIF is going to pick this = up, so it doesn't matter anyway.

Jim

>>> Michael Str=F6der <michael@stroeder.com>= 11/8/04 2:54:03 PM >>>
Jim Sermersheim wrote:
> =
> >>>> Michael Str=F6der < michael@stroeder.com > 11/8/04 3:15:25 AM = >>>
> >Jim Sermersheim wrote:
> >>
> = >> It's difficult (well, impossible I guess) to write an LDIF file = which
> >> can be used to update schema because one never = knows the name of the
> >> subschema subentry in effect for = the object(s) for which the schema
> >> is being updated. (I'm = assuming a DSA which can modify schema. i.e.
> >> X.501(93) = Clause 14.5).
> >
> >There's not a single sub schema sub = entry. In fact there could be many.
> >=3D> you have to know = something a priory about the DSA before updating one
> >of its = sub schema sub entries.
> Exactly (thus the "in effect for the = object(s)" bit). This is why I'm
> wondering about a mechanism to = (apriori) gather the knowledge needed to
> update the schema which = the application intends to update.

Kind of a mind-reading machine? = ;-)

Well, if someone would like to implement a generic sub schema = modifying
program this would need as input params to modify a certain = sub schema
at least:
- machine (host:port)
- naming context
- = authentication credentials
- some connection-oriented stuff (e.g. LDAPS = to a separate port)

Frankly I have no clue how these params could = be guessed. They are given
at run-time by an admin who simply knows = them. Now if you invoke a
program with params you can't guess you can = easily implement all your
sub schema modifications in that program.
=
> I apparently worded my message poorly. My intent is to NOT have = to
> implement anything other than an LDIF file.

I can = imagine quite well what you want. IMO it's simply not possible
without = some program interpreting the LDIF data within some context
known a = priori.

Ciao, Michael.

--=__Part6646A52A.0__=-- --===============1337638717== 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 --===============1337638717==-- From ldapext-bounces@ietf.org Wed Nov 10 16:08:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02964 for ; Wed, 10 Nov 2004 16:08:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzVK-0007iP-Jb; Wed, 10 Nov 2004 15:55:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzCK-00028I-TU for ldapext@megatron.ietf.org; Wed, 10 Nov 2004 15:36:09 -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 PAA25129 for ; Wed, 10 Nov 2004 15:36:06 -0500 (EST) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzDJ-0004ki-BY for ldapext@ietf.org; Wed, 10 Nov 2004 15:37:12 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iAAKa2Zv074888; Wed, 10 Nov 2004 20:36:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041110153113.030d6758@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 10 Nov 2004 15:36:29 -0500 To: Leif Johansson From: "Kurt D. Zeilenga" Subject: Re: [ldapext] dc+idn In-Reply-To: <418FC986.7010701@it.su.se> References: <418FC986.7010701@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 02:31 PM 11/8/2004, Leif Johansson wrote: >Could someone summarize the state of affairs with "internationalized >dc"? It seems to me that there is an urgent need looming here. First, here are some earlier starts on this: http://www.watersprings.org/pub/id/draft-zeilenga-ldap-idn-04.txt http://www.watersprings.org/pub/id/draft-hall-ldap-idn-00.txt However, at present, I'm thinking that internationalization of domain components (and like things) is better handled above the directory.... otherwise internationalized and non-internationalized clients will not interoperate properly. Kurt - Kurt > MVH leifj > >_______________________________________________ >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 Wed Nov 10 16:14:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04052 for ; Wed, 10 Nov 2004 16:14: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 1CRzYh-0002A9-IJ; Wed, 10 Nov 2004 15:59:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzKb-0007t3-LJ for ldapext@megatron.ietf.org; Wed, 10 Nov 2004 15:44:41 -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 PAA27670 for ; Wed, 10 Nov 2004 15:44:39 -0500 (EST) Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzLb-0005ZN-SV for ldapext@ietf.org; Wed, 10 Nov 2004 15:45:45 -0500 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id BF6B139318; Wed, 10 Nov 2004 21:44:27 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03253-02-100; Wed, 10 Nov 2004 21:44:27 +0100 (CET) Received: from [130.129.134.141] (unknown [130.129.134.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 066823802D; Wed, 10 Nov 2004 21:44:26 +0100 (CET) Message-ID: <41927DA1.8030907@it.su.se> Date: Wed, 10 Nov 2004 21:44:17 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: sv, en, en-us MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] dc+idn References: <418FC986.7010701@it.su.se> <6.1.2.0.0.20041110153113.030d6758@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041110153113.030d6758@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at su.se X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Kurt D. Zeilenga wrote: > At 02:31 PM 11/8/2004, Leif Johansson wrote: > >>Could someone summarize the state of affairs with "internationalized >>dc"? It seems to me that there is an urgent need looming here. > > > First, here are some earlier starts on this: > http://www.watersprings.org/pub/id/draft-zeilenga-ldap-idn-04.txt > http://www.watersprings.org/pub/id/draft-hall-ldap-idn-00.txt > > However, at present, I'm thinking that internationalization > of domain components (and like things) is better handled > above the directory.... otherwise internationalized > and non-internationalized clients will not interoperate > properly. > Well that may be so but It occured to me the other day that one way to allow the directory to expose idn's to the user is to create a transfer option (;idna-decode or something to that effect) which would return dc and associatedDomain in the ACE-decoded form. A quick read of the application requirements from RFC3490 seems to indicate that a transfer option might be constructed that would fullfill these requirements. MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Nov 10 16:51:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08680 for ; Wed, 10 Nov 2004 16:51:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0AJ-0004qQ-IQ; Wed, 10 Nov 2004 16:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS02u-00011E-GM for ldapext@megatron.ietf.org; Wed, 10 Nov 2004 16:30:28 -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 QAA06641 for ; Wed, 10 Nov 2004 16:30:26 -0500 (EST) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS03w-00082V-DP for ldapext@ietf.org; Wed, 10 Nov 2004 16:31:32 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iAALUPZv075199; Wed, 10 Nov 2004 21:30:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041110162739.03321030@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 10 Nov 2004 16:30:52 -0500 To: Leif Johansson From: "Kurt D. Zeilenga" Subject: Re: [ldapext] dc+idn In-Reply-To: <41927DA1.8030907@it.su.se> References: <418FC986.7010701@it.su.se> <6.1.2.0.0.20041110153113.030d6758@127.0.0.1> <41927DA1.8030907@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 03:44 PM 11/10/2004, Leif Johansson wrote: >Kurt D. Zeilenga wrote: >>At 02:31 PM 11/8/2004, Leif Johansson wrote: >> >>>Could someone summarize the state of affairs with "internationalized >>>dc"? It seems to me that there is an urgent need looming here. >> >>First, here are some earlier starts on this: >> http://www.watersprings.org/pub/id/draft-zeilenga-ldap-idn-04.txt >> http://www.watersprings.org/pub/id/draft-hall-ldap-idn-00.txt >>However, at present, I'm thinking that internationalization >>of domain components (and like things) is better handled >>above the directory.... otherwise internationalized >>and non-internationalized clients will not interoperate >>properly. > >Well that may be so but It occured to me the other day that one way >to allow the directory to expose idn's to the user is to create a >transfer option (;idna-decode or something to that effect) which >would return dc and associatedDomain in the ACE-decoded form. A >quick read of the application requirements from RFC3490 seems to >indicate that a transfer option might be constructed that would >fullfill these requirements. The problem with this approach is that until the transfer encoding is widely implemented and deployed, clients could not rely on its presence. With the above-the-directory approach, internationalized clients can be developed and deployed today need for internationalized support in the servers. Kurt > MVH leifj > > >_______________________________________________ >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 Wed Nov 10 16:55:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09055 for ; Wed, 10 Nov 2004 16:55:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0Nw-0002Xs-AW; Wed, 10 Nov 2004 16:52:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0BA-0005JU-4r for ldapext@megatron.ietf.org; Wed, 10 Nov 2004 16:39:00 -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 QAA07761 for ; Wed, 10 Nov 2004 16:38:57 -0500 (EST) Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0CB-0008DU-9w for ldapext@ietf.org; Wed, 10 Nov 2004 16:40:04 -0500 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id E53F438E62; Wed, 10 Nov 2004 22:38:57 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10154-01-90; Wed, 10 Nov 2004 22:38:57 +0100 (CET) Received: from [130.129.134.141] (unknown [130.129.134.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 698EC38605; Wed, 10 Nov 2004 22:38:57 +0100 (CET) Message-ID: <41928A5F.2040009@it.su.se> Date: Wed, 10 Nov 2004 22:38:39 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: sv, en, en-us MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] dc+idn References: <418FC986.7010701@it.su.se> <6.1.2.0.0.20041110153113.030d6758@127.0.0.1> <41927DA1.8030907@it.su.se> <6.1.2.0.0.20041110162739.03321030@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041110162739.03321030@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at su.se X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Kurt D. Zeilenga wrote: > At 03:44 PM 11/10/2004, Leif Johansson wrote: > >>Kurt D. Zeilenga wrote: >> >>>At 02:31 PM 11/8/2004, Leif Johansson wrote: >>> >>> >>>>Could someone summarize the state of affairs with "internationalized >>>>dc"? It seems to me that there is an urgent need looming here. >>> >>>First, here are some earlier starts on this: >>> http://www.watersprings.org/pub/id/draft-zeilenga-ldap-idn-04.txt >>> http://www.watersprings.org/pub/id/draft-hall-ldap-idn-00.txt >>>However, at present, I'm thinking that internationalization >>>of domain components (and like things) is better handled >>>above the directory.... otherwise internationalized >>>and non-internationalized clients will not interoperate >>>properly. >> >>Well that may be so but It occured to me the other day that one way >>to allow the directory to expose idn's to the user is to create a >>transfer option (;idna-decode or something to that effect) which >>would return dc and associatedDomain in the ACE-decoded form. A >>quick read of the application requirements from RFC3490 seems to >>indicate that a transfer option might be constructed that would >>fullfill these requirements. > > > The problem with this approach is that until the transfer > encoding is widely implemented and deployed, clients could > not rely on its presence. With the above-the-directory > approach, internationalized clients can be developed and > deployed today need for internationalized support in the > servers. Right, but this is no worse than what the client can expect today! Today the client will se ACE-encoded values in dc and associatedDomain. Those are perfectly legal domain names. The transfer option simply allows clients and servers who implement this option to retrieve the ACE-decoded values. This would naturally depend on feature-negotiation (via say the root-DSE). MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Nov 11 12:54:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07505 for ; Thu, 11 Nov 2004 12:54:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSJ3n-0006LL-25; Thu, 11 Nov 2004 12:48:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIwY-0005Mt-P7 for ldapext@megatron.ietf.org; Thu, 11 Nov 2004 12:41:10 -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 MAA06304 for ; Thu, 11 Nov 2004 12:41:08 -0500 (EST) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSIxk-0008Gt-UF for ldapext@ietf.org; Thu, 11 Nov 2004 12:42:25 -0500 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel10.hp.com (Postfix) with ESMTP id 873E12F882; Thu, 11 Nov 2004 09:41:08 -0800 (PST) Received: from cacexc10.americas.cpqcorp.net ([16.92.1.47]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Nov 2004 09:40:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Password Policy OIDs Date: Thu, 11 Nov 2004 09:40:09 -0800 Message-ID: <632116003944094FB495E72A6EDB90B26A25DE@cacexc10.americas.cpqcorp.net> Thread-Topic: [ldapext] Password Policy OIDs Thread-Index: AcS7G/8BQyf9VpGhRUyr9dmcnCFZqwM6/80g From: "Neal-Joslin, Robert (HP-UX Lab R&D)" To: "Jim Sermersheim" , X-OriginalArrivalTime: 11 Nov 2004 17:40:10.0371 (UTC) FILETIME=[7DCD9530:01C4C815] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Jim, =20 I have a highly delayed comment about pwdCheckQuality. I assume that the OID is intended to define a collection of rules that are used for password strength checking. What do you think about making pwdCheckQuality a list of OIDs? This means that the list of strength rules are defined by the attribute value, not the OID. For example OID "9.1.2.3.1" would define "Minimum 1 upper case character required", OID "9.1.2.3.2" would define "No words from a local language dictionary", etc... Perhaps even another OID "9.1.2.3.3" would say "Password must pass at least 80% of the rules defined in pwdCheckQuality." pwdCheckQuality: 9.1.2.3.1 9.1.2.3.2 9.1.2.3.3=20 The problem I see with a single OID is that if an administrator finds that a particular strength rule is troublesome, the only way to disable a rule would be to define a new rule set with a new OID. Bob ________________________________ From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On Behalf Of Jim Sermersheim Sent: Monday, October 25, 2004 10:16 PM To: andrew.sciberras@eB2Bcom.com Cc: ldapext@ietf.org Subject: Re: [ldapext] Password Policy OIDs =09 =09 Yeah, I suppose we could do that as well. I'm looking at the differences between the 00 version and the 09 version: =20 For the pwdPolicy class: - pwdDefaultStorageScheme has been dropped - pwdFailureCountResetTime has changed to pwdFailureCountInterval=20 - pwdGraceLoginLimit has changed to pwdGraceAuthNLimit=20 - pwdCheckSyntax has changed to pwdCheckQuality. It's syntax changed from boolean to integer, but I'm proposing to chainge it to oid - pwdAttribute has been added as a MUST - The usage of all attributes on pwdPolicy has changed from directoryOperation to userOperation - The OID assigned to all attribute has changed at least once =20 There used to be a pwdInfoObj aux class which defined the state attribute. That's gone, but the attributes have gone through these changes: - pwdExpirationTime and pwdAllowChangeTime have been replaced by pwdChangedTime - pwdExpWarned has been dropped - pwdRetryCount and pwdRetryCountResetTime have been replaced by pwdFailureTime - pwdAccountUnlockTime has been replaced by pwdAccountLockedTime - pwdGraceLeft has been replaced by pwdGraceUseTime - The data format of pwdHistory has changed - pwdReset has been added - pwdPolicySubEntry has been added - The OIDs of these have all changed at least once as well =20 Version 04 (July 2001) introduced the OIDs (prior to that, they actually used OIDs relative to an unnamed arc. Less has changed between the 04 and 08 versions in the schema definitions, but semantic changed (including buggy specifications) have changed over those four versions. I also believe most implementations were written to one of 04 - 07 =20 So, it seems a good time to me to update the OIDs, as well as the names. I prefer to keep names that I don't believe will change syntactically or semantically. These include: pwdMinAge, pwdMaxAge, and pwdInHistory (though I might like pwdHistorySize better), pwdHistory (though I can see the format possibly changing, thus a name change would be good), and pwdPolicySubentry. I can think of similar or better names for the rest of them. =09 Jim >>> Andrew Sciberras 10/25/04 8:11:01 PM >>> G'Day Jim, =09 I think that this is a good idea, however your email suggests that=20 changing the OID's will disambiguate the semantics by which a password=20 policy is being enforced. Do you plan to change the short name=20 descriptors of the attributes as well? =09 =09 Andrew Sciberras =09 =09 Jim Sermersheim wrote: =09 > This does bring up another point I wanted to discuss though... >=20 > This draft was written way back when it was popular to assign OIDs in > I-D's. A practice that has lost favor partly due to implementations > using those OIDs and experiencing problems as semantics changed but OIDs > didn't. >=20 > I'd like to move this I-D forward, and I don't want to be tied to any > semantics defined in previous versions. I propose that we replace the > existing OIDs with requests for IANA OIDs. This way, existing > implementations won't appear to be invalid according to the current and > future revisions, and I won't have to worry so much about breaking > existing implementations. >=20 > What do other's think? >=20 > Jim >=20 =09 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Nov 11 20:55:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25262 for ; Thu, 11 Nov 2004 20:55:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSQbc-0006Gu-2Y; Thu, 11 Nov 2004 20:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSQaL-0002aA-GX for ldapext@megatron.ietf.org; Thu, 11 Nov 2004 20:50:45 -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 UAA24897 for ; Thu, 11 Nov 2004 20:50:43 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSQbb-0003KZ-Lz for ldapext@ietf.org; Thu, 11 Nov 2004 20:52:04 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 11 Nov 2004 18:50:12 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 11 Nov 2004 18:49:54 -0700 From: "Jim Sermersheim" To: , Subject: RE: [ldapext] Password Policy OIDs Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 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="===============1393865856==" 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. --===============1393865856== Content-Type: multipart/alternative; boundary="=__Part7959A1D2.2__=" 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. --=__Part7959A1D2.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit A group of us were just talking about this yesterday. I like the direction it goes in, but it doesn't go far enough. For example, if 9.1.2.3.1 means "minimum of 1 uppercase character", then how do I specify "minimum of 2 uppercase"? Similar problems exist for other quality rules: - foce the inclusion of two of these special characters "#%&!@" - Ensure the password isn't a word found at http://www.outpost9.com/files/wordlists/common-passwords.zip. So I think we need someone to propose a rules language (preferrably one already standardized) which could be used for this purpose. Bob Morgan hinted that SAML authentication contexts might do the trick. I haven't looked at that yet. Jim >>> "Neal-Joslin, Robert (HP-UX Lab R&D)" 11/11/04 12:40:09 PM >>> Hi Jim, I have a highly delayed comment about pwdCheckQuality. I assume that the OID is intended to define a collection of rules that are used for password strength checking. What do you think about making pwdCheckQuality a list of OIDs? This means that the list of strength rules are defined by the attribute value, not the OID. For example OID "9.1.2.3.1" would define "Minimum 1 upper case character required", OID "9.1.2.3.2" would define "No words from a local language dictionary", etc... Perhaps even another OID "9.1.2.3.3" would say "Password must pass at least 80% of the rules defined in pwdCheckQuality." pwdCheckQuality: 9.1.2.3.1 9.1.2.3.2 9.1.2.3.3 The problem I see with a single OID is that if an administrator finds that a particular strength rule is troublesome, the only way to disable a rule would be to define a new rule set with a new OID. Bob ________________________________ From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On Behalf Of Jim Sermersheim Sent: Monday, October 25, 2004 10:16 PM To: andrew.sciberras@eB2Bcom.com Cc: ldapext@ietf.org Subject: Re: [ldapext] Password Policy OIDs Yeah, I suppose we could do that as well. I'm looking at the differences between the 00 version and the 09 version: For the pwdPolicy class: - pwdDefaultStorageScheme has been dropped - pwdFailureCountResetTime has changed to pwdFailureCountInterval - pwdGraceLoginLimit has changed to pwdGraceAuthNLimit - pwdCheckSyntax has changed to pwdCheckQuality. It's syntax changed from boolean to integer, but I'm proposing to chainge it to oid - pwdAttribute has been added as a MUST - The usage of all attributes on pwdPolicy has changed from directoryOperation to userOperation - The OID assigned to all attribute has changed at least once There used to be a pwdInfoObj aux class which defined the state attribute. That's gone, but the attributes have gone through these changes: - pwdExpirationTime and pwdAllowChangeTime have been replaced by pwdChangedTime - pwdExpWarned has been dropped - pwdRetryCount and pwdRetryCountResetTime have been replaced by pwdFailureTime - pwdAccountUnlockTime has been replaced by pwdAccountLockedTime - pwdGraceLeft has been replaced by pwdGraceUseTime - The data format of pwdHistory has changed - pwdReset has been added - pwdPolicySubEntry has been added - The OIDs of these have all changed at least once as well Version 04 (July 2001) introduced the OIDs (prior to that, they actually used OIDs relative to an unnamed arc. Less has changed between the 04 and 08 versions in the schema definitions, but semantic changed (including buggy specifications) have changed over those four versions. I also believe most implementations were written to one of 04 - 07 So, it seems a good time to me to update the OIDs, as well as the names. I prefer to keep names that I don't believe will change syntactically or semantically. These include: pwdMinAge, pwdMaxAge, and pwdInHistory (though I might like pwdHistorySize better), pwdHistory (though I can see the format possibly changing, thus a name change would be good), and pwdPolicySubentry. I can think of similar or better names for the rest of them. Jim >>> Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 10/25/04 8:11:01 PM >>> G'Day Jim, I think that this is a good idea, however your email suggests that changing the OID's will disambiguate the semantics by which a password policy is being enforced. Do you plan to change the short name descriptors of the attributes as well? Andrew Sciberras Jim Sermersheim wrote: > This does bring up another point I wanted to discuss though... > > This draft was written way back when it was popular to assign OIDs in > I-D's. A practice that has lost favor partly due to implementations > using those OIDs and experiencing problems as semantics changed but OIDs > didn't. > > I'd like to move this I-D forward, and I don't want to be tied to any > semantics defined in previous versions. I propose that we replace the > existing OIDs with requests for IANA OIDs. This way, existing > implementations won't appear to be invalid according to the current and > future revisions, and I won't have to worry so much about breaking > existing implementations. > > What do other's think? > > Jim > --=__Part7959A1D2.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

A group of us were just talking about this yesterday. I like the = direction it goes in, but it doesn't go far enough. For example, if = 9.1.2.3.1 means "minimum of 1 uppercase character", then how do I specify = "minimum of 2 uppercase"? Similar problems exist for other quality = rules:

- foce the inclusion of two of these special characters "#%&!@"

- Ensure the password isn't a word found at http://www.outpost9.com/file= s/wordlists/common-passwords.zip.

So I think we need someone to propose a rules language (preferrably = one already standardized) which could be used for this purpose. Bob Morgan = hinted that SAML authentication contexts might do the trick. I = haven't looked at that yet.

Jim

>>> "Neal-Joslin, Robert (HP-UX Lab R&D)" = <bob.joslin@hp.com> 11/11/04 12:40:09 PM >>>
Hi = Jim,

I have a highly delayed comment about pwdCheckQuality.

I= assume that the OID is intended to define a collection of rules that = are
used for password strength checking. What do you think about = making
pwdCheckQuality a list of OIDs? This means that the list of = strength rules
are defined by the attribute value, not the OID. For = example OID
"9.1.2.3.1" would define "Minimum 1 upper case character = required", OID
"9.1.2.3.2" would define "No words from a local language = dictionary", etc...
Perhaps even another OID "9.1.2.3.3" would say = "Password must pass at least
80% of the rules defined in pwdCheckQuality= ."

pwdCheckQuality: 9.1.2.3.1 9.1.2.3.2 9.1.2.3.3

The = problem I see with a single OID is that if an administrator finds that = a
particular strength rule is troublesome, the only way to disable a = rule
would be to define a new rule set with a new OID.

Bob

________________________________

From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@i= etf.org] On
Behalf Of Jim Sermersheim
Sent: Monday, October = 25, 2004 10:16 PM
To: andrew.sciberras@eB2Bcom.com
Cc: ldapext@ietf.org
Subject: Re: [ldapext] Password = Policy OIDs

Yeah, I suppose we could do that as well. I'm = looking at the
differences between the 00 version and the 09 version:
For the pwdPolicy class:
- pwdDefaultStorageScheme has been = dropped
- pwdFailureCountResetTime has changed to pwdFailureCountInterva= l
- pwdGraceLoginLimit has changed to pwdGraceAuthNLimit
- = pwdCheckSyntax has changed to pwdCheckQuality. It's syntax changed
from = boolean to integer, but I'm proposing to chainge it to oid

- = pwdAttribute has been added as a MUST
- The usage of all attributes on = pwdPolicy has changed from
directoryOperation to userOperation
- The = OID assigned to all attribute has changed at least once

There used = to be a pwdInfoObj aux class which defined the state
attribute. That's = gone, but the attributes have gone through these changes:
- pwdExpiratio= nTime and pwdAllowChangeTime have been replaced by
pwdChangedTime
- = pwdExpWarned has been dropped
- pwdRetryCount and pwdRetryCountResetTime= have been replaced by
pwdFailureTime
- pwdAccountUnlockTime has = been replaced by pwdAccountLockedTime
- pwdGraceLeft has been replaced = by pwdGraceUseTime
- The data format of pwdHistory has changed
- = pwdReset has been added
- pwdPolicySubEntry has been added
- The = OIDs of these have all changed at least once as well

Version 04 = (July 2001) introduced the OIDs (prior to that, they
actually used OIDs = relative to an unnamed arc. Less has changed between the
04 and 08 = versions in the schema definitions, but semantic changed
(including = buggy specifications) have changed over those four versions. I
also = believe most implementations were written to one of 04 - 07

So, it = seems a good time to me to update the OIDs, as well as the
names. I = prefer to keep names that I don't believe will change syntactically
or = semantically. These include:
pwdMinAge, pwdMaxAge, and pwdInHistory = (though I might like
pwdHistorySize better), pwdHistory (though I can = see the format possibly
changing, thus a name change would be good), = and pwdPolicySubentry. I can
think of similar or better names for the = rest of them.

Jim

>>> Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 10/25/04 8:11:01
PM >>>
G'Day Jim,

I = think that this is a good idea, however your email suggests that
changi= ng the OID's will disambiguate the semantics by which a
password =
policy is being enforced. Do you plan to change the short name =
descriptors of the attributes as well?

Andrew Sciberras
<= BR>
Jim Sermersheim wrote:

> This does bring up another point = I wanted to discuss though...
>
> This draft was written way = back when it was popular to assign OIDs
in
> I-D's. A practice = that has lost favor partly due to
implementations
> using those = OIDs and experiencing problems as semantics changed
but OIDs
> = didn't.
>
> I'd like to move this I-D forward, and I don't = want to be tied to
any
> semantics defined in previous versions. = I propose that we replace
the
> existing OIDs with requests for = IANA OIDs. This way, existing
> implementations won't appear to be = invalid according to the
current and
> future revisions, and I = won't have to worry so much about breaking
> existing implementations= .
>
> What do other's think?
>
> Jim
> =

Jim

>>> Howard Chu <hyc@highlandsun.com> = 11/22/04 7:18:57 AM >>>
Ludovic Poitou wrote:
> Draft 9 = has not been published yet. Still working on it.
>
> Adding = the NO-USER-MODIFICATION keyword to the state information would
> = prevent administrators to update the attributes for unlocking a user for =
> example, and would probably require the introduction of a set of =
> administration procedures for password policy management, such as =
> unlocking a locked account ...
> The security considerations= mention that ACI should be used to restrict
> access to the state = attributes. I think that the security considerations
> need a = little bit of work for clarification of the security issues and
> = the recommandations.

OK, I guess I can understand that. But I don't = think it's surprising to
require a special administration procedure to = directly manipulate these
attributes. After all, in their normal = operation, they are set
completely automatically by directory-internal = operations, so direct
manipulation of their values could be viewed as = an unusual/extraordinary
occurrence.

There was also a question = about whether a DSA should update an entry's
modifiersName / modifyTime= Stamp operational attributes whenever
performing a Password Policy = State Update. My opinion is no, since these
are internal operations, = but there's no explicit statement in the draft.
The decision has some = impact on replication, as some replication
mechanisms might only = propagate a change when they see a timestamp change.

> Howard = Chu wrote:
>
>> I vaguely recall someone mentioning that = the policy schema would be
>> updated again for draft 9, but I = can't seem to find it in my mailbox
>> now. (So was I just = imagining it?) Anyway, it seems that the state
>> information = needs to be defined with NO-USER-MODIFICATION in order to
>> = serve its purpose, otherwise any user with write access to their own =
>> entry can circumvent most of the policies.
--
-- = Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc =
Symas: Premier OpenSource Development and Support

--=__PartDEFE305B.1__=-- --===============0317478811== 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 --===============0317478811==-- From ldapext-bounces@ietf.org Tue Nov 23 01:45:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21563 for ; Tue, 23 Nov 2004 01:45:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWUFk-0000Oa-S9; Tue, 23 Nov 2004 01:34:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWUFF-0000B5-SG for ldapext@megatron.ietf.org; Tue, 23 Nov 2004 01:33:45 -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 BAA20741 for ; Tue, 23 Nov 2004 01:33:44 -0500 (EST) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWUIq-0004g2-EW for ldapext@ietf.org; Tue, 23 Nov 2004 01:37:29 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Mon, 22 Nov 2004 23:33:09 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Date: Mon, 22 Nov 2004 23:32:34 -0700 From: "Vithalprasad Gaitonde" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [ldapext] referencing one LDIF file from another 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 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. Thanks, Prasad _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Nov 23 02:11:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01741 for ; Tue, 23 Nov 2004 02:11:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWUnv-0002vH-Jo; Tue, 23 Nov 2004 02:09:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWUhh-0000Ks-Fs for ldapext@megatron.ietf.org; Tue, 23 Nov 2004 02:03:09 -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 CAA24845 for ; Tue, 23 Nov 2004 02:03:07 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWUlJ-0008VW-8s for ldapext@ietf.org; Tue, 23 Nov 2004 02:06:53 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with ESMTP id iAN72ugI025317; Tue, 23 Nov 2004 01:02:58 -0600 Message-ID: <41A2E0AA.1020007@highlandsun.com> Date: Mon, 22 Nov 2004 23:03:06 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041101 X-Accept-Language: en-us, en 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: cf4fa59384e76e63313391b70cd0dd25 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 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 Tue Nov 23 03:22:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13552 for ; Tue, 23 Nov 2004 03:22:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWVpU-00037C-4u; Tue, 23 Nov 2004 03:15:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWVjf-0001mX-05 for ldapext@megatron.ietf.org; Tue, 23 Nov 2004 03:09:15 -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 DAA12072 for ; Tue, 23 Nov 2004 03:09:12 -0500 (EST) Received: from [62.80.62.83] (helo=nb2.stroeder.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWVn6-00006P-Ef for ldapext@ietf.org; Tue, 23 Nov 2004 03:12:59 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id E04CCC97C9; Tue, 23 Nov 2004 07:57:14 +0100 (CET) Message-ID: <41A2DF4A.5090406@stroeder.com> Date: Tue, 23 Nov 2004 07:57:14 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Password Policy operational attributes References: In-Reply-To: X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Jim Sermersheim wrote: > > I also prefer that when these attributes are updates, that the > modification tracking attributes (modifyTimeStamp, modifyCSN, version, > whatever) are updated, I disagree strongly here. You'd loose very valuable information about who did the last administrative changes to an entry. IMO modification of password policy state information SHOULD NOT update 'modifyTimeStamp' and 'modifiersName'. Attributes used for replication SHOULD be updated off course ('modifyCSN' looks like such an attribute). > Likely we could remind server > implementors to do whatever is needed to cause replication to properly > happen. +1 Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Nov 23 07:48:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05303 for ; Tue, 23 Nov 2004 07:48:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWa4A-0007eW-02; Tue, 23 Nov 2004 07:46:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWZxa-00067q-37 for ldapext@megatron.ietf.org; Tue, 23 Nov 2004 07:39:54 -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 HAA04512 for ; Tue, 23 Nov 2004 07:39:52 -0500 (EST) Received: from e4.ny.us.ibm.com ([32.97.182.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWa1E-0001gw-Ta for ldapext@ietf.org; Tue, 23 Nov 2004 07:43:41 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iANCdInK630416 for ; Tue, 23 Nov 2004 07:39:18 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iANCdH7a193094 for ; Tue, 23 Nov 2004 07:39:17 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iANCdHmI019143 for ; Tue, 23 Nov 2004 07:39:17 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iANCdH14019133 for ; Tue, 23 Nov 2004 07:39:17 -0500 In-Reply-To: <41A2DF4A.5090406@stroeder.com> Subject: Re: [ldapext] Password Policy operational attributes To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Tue, 23 Nov 2004 06:39:15 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M3_11102004|November 10, 2004) at 11/23/2004 06:39:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Jim Sermersheim wrote on 11/23/2004 12:57:14 AM: > Jim Sermersheim wrote: > > > > I also prefer that when these attributes are updates, that the > > modification tracking attributes (modifyTimeStamp, modifyCSN, version, > > whatever) are updated, > > I disagree strongly here. You'd loose very valuable information about > who did the last administrative changes to an entry. > > IMO modification of password policy state information SHOULD NOT update > 'modifyTimeStamp' and 'modifiersName'. Attributes used for replication > SHOULD be updated off course ('modifyCSN' looks like such an attribute). I took Jim's comment as meaning that when the password policy attributes are directly modified by a client (e.g. the attributes are part of a modify request), modifyTimestamp, etc. should be updated. I don't think he was suggesting that modifyTimestamp should be set as a result of a bind failure, and my first reaction is that a failed bind should not update modifyTimestamp. > > > Likely we could remind server > > implementors to do whatever is needed to cause replication to properly > > happen. > > +1 > > Ciao, Michael. > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext