[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Change of name forms and DIT structure rules when renaming an entry
Hi Michael,
Michael Ströder wrote:
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.
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
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?
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
Ciao, Michael.
P.S.: I'd appreciate interop testing over Internet regarding this...