Subject: Re: Models: Naming Contexts

From: John McMeeking <[email-masked]>
Date: Mon, 27 Jan 2003 13:19:27 -0600

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
???
If you then create the entry "c=us", would "o=my company,c=us" still be
listed as a namingcontext?

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.

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.

>Please refer to X.501 Section 18.5
>
>Jim

John McMeeking

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 27 Jan 2003 13:02:19 -0700

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 <[email-masked]> 1/27/03 12:19:27 PM >>>
>
>Jim Sermersheim wrote:
>
>>From Models 05
>>
>>>5.1.2. 'namingContexts'
><snip>

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

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

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

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

Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 28 Jan 2003 09:46:50 -0700

Right, I caught something like that with my subsequent message--thanks.

Jim

>>> Hallvard B Furuseth <[email-masked]> 1/28/03 8:48:15 AM
>>>
Jim Sermersheim writes:
> If a server does master the entire DIT, there shouldn't be
> namingContexts subordinate to the root.

What if the server masters "" and o=foo,c=US, but not c=US?

-- 
Hallvard

---

From: Christopher Oliva <[email-masked]>
Date: Tue, 28 Jan 2003 13:10:10 -0500

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:[email-masked]]
Sent: Monday, January 27, 2003 3:02 PM
To: [email-masked]
Subject: Re: Models: Naming Contexts

Jim

<previous message below>

Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 28 Jan 2003 14:03:46 -0700

I prefer #1 as there is/are server(s) that already do this today. I also
note that the reason given for the attribute (This attribute allows a
client to choose suitable base objects for searching when it has
contacted a server.) is well aligned with the notion of advertising the
DIT root ("") when the server is a first-level DSA. This reconciles this
advertisement attribute with the fact that X.511 allows a search to be
based at the tree root.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 1/28/03 1:24:12 PM >>>
>DIT, and also one or more other naming contexts?

Well, this sentence wouldn't apply in this case.  So, taking the
specification literally, the namingContext attribute would have
one value for each naming contexts it masters or shadows, the
context prefix of the naming context.  This would NOT include ""
as "" is not a valid context prefix.

>string.  Please refer to X.501 Section 18.5

I have a couple of alternatives approaches which could be taken
1)  replace first paragraph of 5.1.2 with:
    The 'namingContexts' attribute lists the context prefixes of the
    naming contexts the server masters or shadows (in part or in
whole).
    If the server is a first-level DSA [X.501], it should list (in
    addition) an empty string (indicating the root of the DIT).
    If the server does not master or shadow any information (e.g. it
    is an LDAP gateway to a public X.500 directory) this attribute
will
    be absent.  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 root of the
    DIT).  This attribute allows a client to choose suitable base
    objects for searching when it has contacted a server.

  and then noting in Changes the change to first-level DSA case.

2)  replace first paragraph of 5.1.2 with:
    The 'namingContexts' attribute lists the context prefixes of the
    naming contexts the server masters or shadows (in part or in
whole).
    If the server does not master or shadow any information (e.g. it
    is an LDAP gateway to a public X.500 directory) this attribute
will
    be absent.  This attribute allows a client to choose suitable base
    objects for searching when it has contacted a server.

  and then noting that listing "" as a value of namingContexts has
been
  deprecated in Appendix A.

Comments?

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 28 Jan 2003 14:41:19 -0700

I think what it boils down to is, once the user has determined that the
root can be searched, it can perform a *single* search operation, and
use referral handling if it wants to progress the operation through the
entire tree.

Jim

>>> Christopher Oliva <[email-masked]> 1/28/03 11:10:10 AM
>>>

- 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:[email-masked]] 
Sent: Monday, January 27, 2003 3:02 PM
To: [email-masked] 
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).

references directly below the root. I want to be able to search from
the

Jim

<previous message below>

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

the base is "", I am asking to search the entire DIT. See Section
10.2.2

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

Jim