Subject: Re: [ldapext] Dynamic values in LDIF

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Nov 2004 11:37:57 -0700

>>>> Michael Ströder <[email-masked]> 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.
>=> 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

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Nov 2004 11:40:45 -0700

Rats, I was hoping _not_ to be the one trying this.

>>> Mark Smith <[email-masked]> 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

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

---

From: Michael Ströder <[email-masked]>
Date: Mon, 08 Nov 2004 20:54:03 +0100

Jim Sermersheim wrote:
> 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.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Nov 2004 14:50:50 -0700

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=example,dc=com 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=example,dc=com
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 governing dc=example,dc=com

If the subschemaSubentry attribute on dc=example,dc=com is cn=schema,dc=com, it will be substituted as the dn value for the change record.
 
Note that the machine (host:port), authN credentials, and connection-oriented 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öder <[email-masked]> 11/8/04 2:54:03 PM >>>
Jim Sermersheim wrote:
> 
> >>>> Michael Ströder < [email-masked] > 11/8/04 3:15:25 AM >>>
> >Jim Sermersheim wrote:
> >>

Ciao, Michael.