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

Hi Michael,

Michael Str=F6der wrote:
> HI!
>=20
> when displaying an input form for renaming an entry I'd like to let the=
=20
> user search for possible new superior DNs. If applicable I'd like to=20
> construct the search filter derived from applicable DIT structure rules.
> So the question is how to find the structural object classes which are=20
> allowed for superior entries.
>=20
> X.501 (1993) section 12.6.5 says:
> "Each object and alias entry is governed by a single DIT structure rule=
."
>=20
> Currently I determine the governing structure rule by looking up the=20
> best matching name form for 1. the structural object class and 2. the=20
> current old RDN.

In general, you also need the governingStructureRule of the current
superior entry, but it is easier to just look at the governingStructureRu=
le
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
> and lookup the superior structural object classes via the accompanying=20
> name forms.
>=20
> But now I wonder what to do in case the user wants to change the RDN=20
> together with a new superior DN in one rename operation? From my=20
> understanding changing the RDN could lead to another governing structur=
e=20
> rule. Is that right?

Yes, it could. In the general case the structural object class of the ent=
ry
being renamed/moved would permit a number of candidate name forms, each w=
ith
its own set of mandatory and optional naming attributes. For each name fo=
rm,
the structure rules specify the permitted governingStructureRule values f=
or the
new superior entry of the entry being renamed/moved. The structuralObject=
Class
of the superior entries doesn't come into it directly, but can be determi=
ned
from the name form associated with the structure rule corresponding to ea=
ch
of the permitted values for the governingStructureRule of the new superio=
r.
It would be easier to search for entries having a governingStructureRule =
with
one of the permitted values, and more precise since the relationship betw=
een
structuralObjectClass and governingStructureRule is one to many.

The server will work out the new governingStructureRule for the renamed/m=
oved
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 allo=
w
the user to rename the entry first (explicitly or implicitly selecting on=
e
of the applicable name forms), then that will constrain which new superio=
r
entries are available.

Regards,
Steven

>=20
> Ciao, Michael.
>=20
> P.S.: I'd appreciate interop testing over Internet regarding this...
>=20