[Date Prev][Date Next]
Re: Models: Naming Contexts
>>> John McMeeking <firstname.lastname@example.org> 1/27/03 12:19:27 PM >>>
>Jim Sermersheim wrote:
>>From Models 05
>>> If the server believes it masters or shadows the entire
>>> directory, the attribute will have a single value, and that value
>>> be the empty string (indicating the null DN of the root).
>>What if the server is a first level DSA which masters the root of
>>DIT, and also one or more other naming contexts?
>>I believe this is a flaw and should be corrected to allow the
>>namingContexts attribute to hold values in addition to the empty
>I'm having a hard time with the notion of mastering the root of the
>and some other subtree. Would that be something like:
> namingContexts: <empty string>
> namingContexts: o=my company,c=us
Yes, this could happen if it mastered the root as well as o=my
company,c=us, but not c=us (it would likely have a subordinate reference
>If you then create the entry "c=us", would "o=my company,c=us" still
>listed as a namingcontext?
If o=my company has no siblings that are mastered elsewhere, I would
think that c=us would suffice. But if there are subordinate references
under c=us, I would expect to see both values.
>Since "" is not the root of a DIT subtree, perhaps it would be more
>appropriate for such servers to return the root entries of subtrees
>actually present on the server. As new subtrees are created, the
>namingContexts attribute would be updated accordingly.
Why is "" not the root of a DIT? If I perform a subtree search where
the base is "", I am asking to search the entire DIT. See Section 10.2.2
of X.511 (especially "or possibly the root"). I want to know *when* I
can search from the DIT root, and I also want to know which contiguous
naming contexts a server holds.
That said, I do think there's a problem with my original request:
A naming context is defined to be a subtree. A server either masters
the entire DIT or it doesn't. If a server doesn't master the entire DIT,
the empty name cannot be advertised. If a server does master the entire
DIT, there shouldn't be namingContexts subordinate to the root. I was
mistakenly mixing up my notion of "areas of replication" with
namingContexts. I will re-state what I think the real problem is in
>I'm trying to think of cases where it would be necessary for the
>to advertise that "c=au" could be added to the directory, but doesn't
>yet exist. It seems more useful in this scenario to only list the
>that have been created. If the server only holds the subtree "o=my
>c=us" I'd still expect that to be present in the namingcontexts
>even if the entry doesn't exist.
I'm getting stuck on a couple things: first, there's no way to
advertise names that "could be added". I think you're trying to say that
there's an implicit advertisement for this, but I'm not seeing it. Next
I don't believe values of the namingContexts attribute should point to
non-existent entries in the local DIB fragment. I think I'm missing what
you're saying though.