A couple of comments on this:
- the suggestion would allow the client to recognize a server as a first level DSA but I'm not sure where this term is defined in the specs and if the requirements for claiming that role have been established. It's defined in X.501 as not allowing a superior reference and holding a complete list of references to naming contexts below the root.
- I'm not sure what a client will gain by detecting the root in the namingContexts attribute (according to the new proposal). Because, a server might still have references to naming contexts it doesn't master or shadow. I suppose this will tell the client to stop its search after querying a first level DSA and receiving an "entry not found" error. Otherwise the client could continue its search to another server (to which it has acquired a reference). Perhaps this client behaviour should be documented - although I'm not sure how many existing clients would conform to that.
Chris.
-----Original Message-----
From: Jim Sermersheim [mailto:jimse@novell.com]
Sent: Monday, January 27, 2003 3:02 PM
To: ietf-ldapbis@OpenLDAP.org
Subject: Re: Models: Naming Contexts
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