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

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

At 12:16 PM 7/20/00 +1000, Steven Legg wrote:
>> >> Is an option required?  If not, what is the semantics of 
>> an optionless
>> >> refer attribute?

No answer to this yet.

>> >> I also question this use of options.  Are there better approaches?
>
>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.

Yes, this is quite different.  This requires C to maintain clear
separation of information which A is authority over and information
which B is authority over and to restrict updates to accordingly.

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

The proposal suggests using named entries to representing references.
For a subordinate reference, it proposes that this object have
an attributes associates with naming, object class referral, and
object class extensible object.  This information my be in
contradiction with the actual entry DSE it refers to.

When DSE are replicated, receiving server must have a clear
mechanism for determining the update is associated with the
portion of the DSE.  I've suggested one approach, there are others.

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

This is my primary concern.  I am not sure it makes sense
to change an entry into an subordinate reference just by
adding a 'refer' attribute.  I believe you should have to
delete the entry and add a 'referral' entry.  I also think
that a 'referral' entry MUST have a 'refer' attribute.

>The DSEType is not immutable in X.500

Correct, I should have said that DSEtype is not modifiable by the
user.

The implication is that certain DSEtype changes make little
(or no) sense and using the presence or lack of presence of
an attribute type (or types) to indicate such may not be
optimal.

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

The proposal models references as entries, with object classes,
with RDN attributes, with musts/may requirements.