Re: Models: Naming Contexts

["Jim Sermersheim" <jimse@novell.com>]

I'm going to flip flop on this one more time--I'm back to my original
assertion. Imagine a server that holds [dc=com] [dc=novell,dc=com]
[dc=ibm,dc=com] (subordinate reference) [dc=org] (subordinate reference)
and [dc=net] (subordinate reference).

The server is a first level DSA. I want to know that it masters the
root of the tree, regardless of the fact that it has subordinate
references directly below the root. I want to be able to search from the
root of the tree and receive the search result references for the
subref's, intermixed with the search results in the dc=novell,dc=com
subtree.

Jim


<previous message below>

>>> John McMeeking <jmcmeek@us.ibm.com> 1/27/03 12:19:27 PM >>>
>
>Jim Sermersheim wrote:
>
>>From Models 05
>>
>>>5.1.2. 'namingContexts'
><snip>
>>>  If the server believes it masters or shadows the entire
>>>  directory, the attribute will have a single value, and that value
>will
>>>  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
the
>>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
>>string.
>
>I'm having a hard time with the notion of mastering the root of the
DIT
>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
to c=us).

>If you then create the entry "c=us", would "o=my company,c=us" still
be
>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
another mail.

>I'm trying to think of cases where it would be necessary for the
server
>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
subtrees
>that have been created.  If the server only holds the subtree "o=my
>company,
>c=us" I'd still expect that to be present in the namingcontexts
attribute
>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.

>John McMeeking

Jim