[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



Kurt,

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Thursday, 20 July 2000 1:37
> To: steven.legg@adacel.com.au
> Cc: ietf-ldapext@netscape.com
> Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt
> 
> 
> 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.

That would be so if server A and server B both had references to some
third server, but I was talking about the situation where server A
masters the entry, server B has a reference to the entry in server A,
and server C replicates from both server A and server B. Server A tells
server C that the object class is say, organization, while server B tells
server C that the object class is referral.

Where a DSE is a placeholder for an entry that isn't held locally that
DSE shouldn't contain shared information that contradicts the remote
master entry. It's painful for replication if it does.

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

The DSEType is not immutable in X.500 and is also permitted to be
different between servers having knowledge of the same DN. What is "glue"
for one server will be "entry" for another and maybe "shadow" as well
for a third. The semantics of the reference can be established just as
well from the attribute type or from the attribute type and option.

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

That depends on how you interpret clause 19 of X.501:1993. It might be
legal for a DSE that is not of type "entry", "alias" or "subentry" to
have an objectClass attribute without all the mandatory attributes.
 
> 
> >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?".
> 
>

Regards,
Steven