RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:42 PM 7/19/00 +1000, Steven Legg wrote:

>Kurt,
>
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>> Sent: Saturday, 15 July 2000 3:13
>> To: ietf-ldapext@netscape.com
>> Subject: Re: I-D ACTION:draft-ietf-ldapext-refer-00.txt
>> 
>> 
>> Roland,
>
>[snip]
>
>> > 2.1 The refer attribute
>> >    The refer attribute can be further specified by the use 
>> of options as
>> >    defined in section 4.1.5 of [RFC2251]. This document defines five
>> >    options and their use. Future documents might defined 
>> other options.
>>  
>> Is an option required?  If not, what is the semantics of an optionless
>> refer attribute?
>> 
>> I also question this use of options.  Are there better approaches?
>> I would suggest tieing the semantics of the attribute to object
>> classes and/or type of the DSE its contained in.  That is, a refer
>> in the root dse is a superior reference, a refer in a referral
>> object (objectclass=referral) is a subordinate, etc..
>
>I would rather not tie the semantics to the object class, for the sake of
>replication. If an entry is represented by its appropriate object class
>in one server and by an entry with one of the referral classes in another
>it presents a problem to any server replicating from both sources.
>What is the object class of the merged object ?


This would be a replication error as one server was not using
standard track representation of the referral object.

>Better if the referencing
>entry is a DSE with no object class,

My primary reason of suggesting use of object classes, especially
for subordinate references, is that the semantics need to be
established when the entry is instantiated.  The DSE type associated
with the object should be immutable.

>or has the same object class as
>the referenced entry.

Then the object would be required to have all the required attributes
of these classes.

>I'd prefer to use separate attributes instead of separate options to convey
>the semantics but that's not critical.

This would at least remove the question "what are the semantics
of an optionless 'refer' attribute?".