RE: naming contexts

["Kurt D. Zeilenga" <Kurt@xxxxxxxxxxxx>]

At 05:24 PM 2001-12-06, Steven Legg wrote:
>Kurt D. Zeilenga wrote:
>> RFC 2256, 5.2.1. namingContexts
>>    The values of this attribute correspond to naming contexts
>>    which this server masters or shadows.
>
>Of course you mean RFC 2252, but I take the point. I didn't look
>beyond the description in RFC 2251 (doh!). However, I wonder if it
>should instead say: "The values of this attribute correspond to the context
>prefixes of naming contexts which this server masters and the names
>of the base entries for replication areas that this server shadows." ?

Well, the problem is partial replication.  Consider a naming context
containing has N entries where N-1 are immediately subordinate to
context prefix and a replica which holds these N-1 entries (and not
the context prefix).  Your definition would require N-1 namingContext
values.

The LDAP/X.500 models assume that the shadow server has knowledge
as where the context prefix is mastered.  While publishing this
the context prefix may lead the client to believe the shadow server
holds the context prefix, this is a bad assumption.  The value
means that the shadow server holds a portion of the naming context.
This is "good enough" for most uses (the shadow generally has
knowledge to refer the client as needed).

>In X.525, the root of a shadowed subtree doesn't have to correspond
>to a context prefix entry. It can be a subordinate of a context prefix.
>Perhaps it is more useful to a client to know the topmost shadowed
>entry rather than the context prefix ?

Well, that could be argued.  But LDAP/X.500 is the way it is.  I
have no problem with replicaContexts behaving in this manner (though
I believe the partial replication issue applies here as well).

My concern is that LDUP does not define how a server is to
populate namingContext.  I argue it need to be defined in a manner
consistent with LDAP technical specification [including, by reference,
Section 17 of X.500(93)].  I believe the best (only?) way to do this
is to term one of the masters the "primary" in respect to this naming
context information (and, as Ed suggests, portions of replication
management information).

Kurt