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

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: michael <at> stroeder.com
http://www.stroeder.com

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 

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

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

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.

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

Michael,

Michael Ströder wrote:
> 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.
>>> 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,
> 
> You mean I could derive the possible structural object class from the 

IETF#73 LDAP BOF Proposal

I intend to send a BOF proposal for IETF#73 for the purpose of forming  
a new working group to undertake LDAP standards work.  Below is a  
rough proposal for your consideration and comments.  (I am surely  
biased as what new engineering efforts the proposed WG ought take on,  
please do feel free to offer other possible work items.)

-- Kurt

Lightweight Directory Access Protocol (LDAP) BOF

Chair(s): TBD

The purpose of this BOF is to discuss the formation of a working group  
to undertake LDAP standards work.  It is conceived that the proposed  
WG would undertake both the revision of existing technical  
specifications for LDAP extensions and the engineering of new LDAP  
extensions.

There are numerous existing technical specifications for LDAP  
extensions.  Most of the Standard Track specifications were published  
prior to the current LDAP "core" specification [RFC 4510] and are in  
the need of revision.  In some cases, it may be more appropriate to  
move the extension off the Standards Track.   While the work of  
determining which RFC should be revised (or moved off to a different  
track), and prioritization of the work, could be deferred to the WG,  
it is hoped that the BOF will reach some conclusions as to which  
revision work is of the highest priority.

There are also numerous extensions to LDAP which seem worthy of  
standardization. It is hoped that the BOF will reach some conclusion  

Re: [ldapext] IETF#73 LDAP BOF Proposal

Re: IETF#73 LDAP BOF Proposal

On Aug 30, 2008, at 7:47 AM, Alexey Melnikov wrote:

> Kurt,
> Can you be more specific about which documents you have in mind for  
> both groups of documents you proposed to work on?

For revision work, I think each LDAP extension specified as an RFC is  
a possible work candidate, especially those published pre-RFC4510.   
Obviously the working group cannot take on all at once, or even all  
ever.   So there needs to be some prioritization done here.   I have a  
few thoughts here, but have yet to attempt to put together my own top- 
few list.  Pre-BOF it would be good for each person willing to do work  
in this area to post their top-few candidates. We can then see if  
there is any consensus on what the proposed WG should be chartered to  
do first, put that into the proposed WG charter.  (My own top-few list  
would likely include updating LDIF [RFC2849].)

For new engineering, LDAP Transaction [draft-zeilenga-ldap-txn] and  
LDAP Relax Rules [draft-zeilenga-ldap-relax] tops my personal list.

In the next few weeks I'll try to put a draft a proposed WG charter  
for list discussion, and likely at BOF discussion.

-- Kurt

>
> On Fri, Aug 29, 2008 at 10:48 PM, Kurt Zeilenga <Kurt.Zeilenga <at> isode.com 
> > wrote:
> I intend to send a BOF proposal for IETF#73 for the purpose of forming
> a new working group to undertake LDAP standards work.  Below is a
> rough proposal for your consideration and comments.  (I am surely
> biased as what new engineering efforts the proposed WG ought take on,
> please do feel free to offer other possible work items.)
>
> -- Kurt
>
>
> Lightweight Directory Access Protocol (LDAP) BOF
>
> Chair(s): TBD
>
> The purpose of this BOF is to discuss the formation of a working group
> to undertake LDAP standards work.  It is conceived that the proposed
> WG would undertake both the revision of existing technical
> specifications for LDAP extensions and the engineering of new LDAP
> extensions.
>
> There are numerous existing technical specifications for LDAP
> extensions.  Most of the Standard Track specifications were published
> prior to the current LDAP "core" specification [RFC 4510] and are in
> the need of revision.  In some cases, it may be more appropriate to
> move the extension off the Standards Track.   While the work of
> determining which RFC should be revised (or moved off to a different
> track), and prioritization of the work, could be deferred to the WG,
> it is hoped that the BOF will reach some conclusions as to which
> revision work is of the highest priority.
>
> There are also numerous extensions to LDAP which seem worthy of
> standardization. It is hoped that the BOF will reach some conclusion
> as to short list of new extension work items to be undertaken (at
> least initially) by the proposed WG.  That short list might include,
> for instance, in LDAP Transactions and Extensions for X.500 Alignment.
>
> By including both revision and new engineering work items in a single
> working group it is hoped that the sufficient participation levels
> will be maintained to make reasonable progress in both revision and
> new engineering work.
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext
>