Subject: Change of name forms and DIT structure rules when renaming an entry

From: Michael Ströder <[email-masked]>
Date: Mon, 18 Aug 2008 15:18:31 +0200

HI!

when displaying an input form for renaming an entry I'd like to let the 
user search for possible new superior DNs. If applicable I'd like to 
construct the search filter derived from applicable DIT structure rules.
So the question is how to find the structural object classes which are 
allowed for superior entries.

X.501 (1993) section 12.6.5 says:
"Each object and alias entry is governed by a single DIT structure rule."

Currently I determine the governing structure rule by looking up the 
best matching name form for 1. the structural object class and 2. the 
current old RDN. Then I can derive the possible superior structure rules 
and lookup the superior structural object classes via the accompanying 
name forms.

But now I wonder what to do in case the user wants to change the RDN 
together with a new superior DN in one rename operation? From my 
understanding changing the RDN could lead to another governing structure 
rule. Is that right?

Ciao, Michael.

P.S.: I'd appreciate interop testing over Internet regarding this...

-- 
Michael Ströder
E-Mail: [email-masked]
http://www.stroeder.com

---

From: Steven Legg <[email-masked]>
Date: Wed, 20 Aug 2008 09:58:06 +1000

Hi Michael,

Michael Ströder wrote:
> current old RDN.

In general, you also need the governingStructureRule of the current
superior entry, but it is easier to just look at the governingStructureRule
of the entry to be moved. Ultimately though, the governingStructureRule
of the entry to be moved doesn't matter.

 > Then I can derive the possible superior structure rules

Yes, it could. In the general case the structural object class of the entry
being renamed/moved would permit a number of candidate name forms, each with
its own set of mandatory and optional naming attributes. For each name form,
the structure rules specify the permitted governingStructureRule values for the
new superior entry of the entry being renamed/moved. The structuralObjectClass
of the superior entries doesn't come into it directly, but can be determined
from the name form associated with the structure rule corresponding to each
of the permitted values for the governingStructureRule of the new superior.
It would be easier to search for entries having a governingStructureRule with
one of the permitted values, and more precise since the relationship between
structuralObjectClass and governingStructureRule is one to many.

The server will work out the new governingStructureRule for the renamed/moved
entry from the governingStructureRule of the new superior and the naming
attributes of the renamed/moved entry.

If you allow the user to select the new superior first, then that will
constrain which name forms are available to rename the entry. If you allow
the user to rename the entry first (explicitly or implicitly selecting one
of the applicable name forms), then that will constrain which new superior
entries are available.

Regards,
Steven

---

From: Michael Ströder <[email-masked]>
Date: Thu, 21 Aug 2008 10:02:33 +0200

Steven,

I really appreciate your comment.

Steven Legg wrote:
> 
> Michael Ströder wrote:
>> when displaying an input form for renaming an entry I'd like to let 
>> the user search for possible new superior DNs. If applicable I'd like 
>> to construct the search filter derived from applicable DIT structure 
>> rules.
> superior entry,

You mean I could derive the possible structural object class from the 
governingStructureRule of the superior entry? Hmm, there could be more 
possible structural object classes of superior entries.

> but it is easier to just look at the governingStructureRule
> of the entry to be moved.

That's how I currently implemented it.

> Ultimately though, the governingStructureRule

...because the RDN could also change...

>> understanding changing the RDN could lead to another governing 
>> structure rule. Is that right?
> 
> Yes, it could. In the general case the structural object class of the
> entry being renamed/moved would permit a number of candidate name
> forms, each with its own set of mandatory and optional naming
> attributes. For each name form, the structure rules specify the
> permitted governingStructureRule values for the new superior entry of
> the entry being renamed/moved. The structuralObjectClass of the
> superior entries doesn't come into it directly, but can be determined
>  from the name form associated with the structure rule corresponding
> to each of the permitted values for the governingStructureRule of the
> new superior.

I could sort this out since I already have working code for determining 
the current name form of an entry and for determining the 
governingStructureRule. Not sure how to come up with a good user 
interface for that though.

Thinking about this a little bit more I came up with another difficulty: 
The new superior DN might reside in a part of the DIT where another 
subschema is defined. So this is a real blocker.

> of the applicable name forms), then that will constrain which new superior

Yes. But the problem is that it might be necessary for the user to 
change both in one rename operation. From my understanding changing the 
name form could lead to the situation where the old superior is not 
valid anymore.

This all gets very hairy. At the moment I can't imagine a user interface 
which really helps the user to do the right thing without the user 
knowing a lot about how DIT structure rules and name forms work.

I will take a simpler approach with client-side configuration. Probably 
I will display a pre-configured select list of named LDAP URLs for 
searching the new superior entries. This would also work with servers 
which don't support DIT structure rules and name forms.

Ciao, Michael.

---

From: Steven Legg <[email-masked]>
Date: Fri, 22 Aug 2008 16:09:11 +1000

Michael,

Michael Ströder wrote:
>>> So the question is how to find the structural object classes which 
>>> are allowed for superior entries.
>>>
> governingStructureRule of the superior entry?

I was just making the point that an entry's governingStructureRule also
depends on the governingStructureRule of its superior. However, you don't
need to know the current governingStructureRule of the entry or its superior.

 > Hmm, there could be more

... because it only tells you about one valid possibility for a new
superior. There can be others. Clearly, the entry could be moved
under any new superior (in the same subschema administrative area)
that has the same governingStructureRule as its old superior, provided
the moving entry's naming attributes are not changed, because the
structural object class, name form and superior entry
governingStructureRule will all be the same in the new location.
If the moving entry was schema-valid before the move it will be
schema-valid after the move. By examining the name forms and structure
rules in the schema it is possible to work out what other
possibilities are valid, but they may necessitate a change to the
naming attributes and may cause the governingStructureRule of the moved
entry to change. The current governingStructureRule of the entry
to be moved doesn't affect what's a valid possibility and what's not.

The possibilities in the schema boil down to a collection of pairs
where the first item is an acceptable governingStructureRule value
for a new superior and the second item is an acceptable name form
for the entry to be moved, i.e., the first item tells you where the entry
can go and the second item tells you whether the RDN needs to change.

>>> and lookup the superior structural object classes via the 
>>> accompanying name forms.
>>>

It means that the search filter is only valid within the scope of the
subschema used to form it. It's rare for a single server to have more than
one subschema area, so you could make that simplifying assumption, but in
the more general case it means emitting one search for each subschema area
the client knows about. It would help to ask for the subschemaSubentry to be
returned so that matched entries that are not in the expected subschema area
can be detected and ignored. Depending on the server implementation, you
might be able to put a subschemaSubentry equality assertion in the search
filter.

> change both in one rename operation.

I was assuming one operation, but allowing that it might be put together
in a multi-step interaction at the user interface. Which step the user
takes first constrains what can be done on the second step, but it isn't
until after the second step that the "save" button gets clicked.

Presenting the user with a list of (superior DN, eligible naming attribute
types) pairs to choose from would be one way of combining both steps in a single
action. Of course, if the naming attribute types in the selection are different
from the current naming attributes, the user interface should enter a screen
to have the user edit them before allowing the operation to be submitted.

 > From my understanding changing the

Correct.

> knowing a lot about how DIT structure rules and name forms work.

The governing structure rules are determined by structural object classes
and name forms. A name form is basically a set of naming attributes, so
the object class and "what attributes are used for naming" are all that
the user really needs to be exposed to.

> which don't support DIT structure rules and name forms.

Whether or not you get back governingStructureRule is probably an accurate
test of whether the server supports structure rules and name forms.

Regards,
Steven