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

["Steven Legg" <steven.legg@adacel.com.au>]

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 ? Better if the referencing
entry is a DSE with no object class, or has the same object class as
the referenced entry.

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

Regards,
Steven