Re: Named Referrals Questions.

[Leonid Dubinsky <dub@shym.com>]

Christopher Lukas wrote:
 
> Leonid Dubinsky wrote:
> > QUESTION 1.
> >
> > The draft seems to imply that objects with a 'ref' attribute can have
> > subordinate objects with a 'ref' attribute. This can be used to make
> > subordinate referrals more specific. Mark Smith confirms that this is
> > the idea. I think this should be more explicit in the text.
> >
> > QUESTION 2.
> >
> > The draft seems to also imply that objects with a 'ref' attribute can
> > have "normal" subordinate objects held by the same server. This can be
> > used to make superior referrals smart, i.e. to keep superior referrals
> > for each naming context held by the server in an object superior to that
> > naming context.
> >
> > Such "smart" superior references can be used to provide referrals more
> > specific (and meaningful) than the default superior reference held in
> > the root DSE.
> 
> I think both of these are not specifically allowed, but seem like _one_
> way to do "smart" superior references. I think the reason we didn't
> specifically describe this as a way to do smart superior references is
> that it is not the only way to do them. Section 6 says:
> 
> If the LDAP server's root DSE does not contain a ref attribute, the
> server may return one or more references that the server determines via
> a method not defined in this document to be appropriate.
> 
> By this we meant to allow some kind of smart superior references not
> necessarily based on ref entries. I was actually thinking of some kind
> of DN-based index which would have the same functionality as your idea.
> I like your idea becuase it seems natural, but I can't help but feel
> that there might be some other way someone would want to be smart about
> superior references hence leaving this open seems like a good idea. Of
> course, off-hand, I can't think of any other ways, but I feel like there
> are. Any thoughts on this?

It is nice to be able to do more and to be more intelligent than the
standard requires, but the standard must specify enough to ensure (or at
least allow for) interoperability. Specifically, referrals based on ref
enries may be managed remotely, in a server-independent manner, using
LDAP protocol requests with 'manageDsaIT' control. We all agree that
"smart" superior referrals (David Chadwick tells me to call them
"immediate superior references") are usefull. If the standard does not
specify any support for them, servers will support them anyways, but it
will become impossible to write - say - a tool for configuring referrals
in multiple servers (from different vendors), and such tools will be
essential real soon IMHO.

I feel that the more of the server configuration - referrals, schema,
indexing - is exposed and made modifiable through normal ("natural")
LDAP mechanisms - the better. Different information may be stored
differently on different servers (including DN-based indexes), as long
as it is presented to the clients in the form of directory entries.


> >WHEN DOES THE SERVER RETURN "NO SUCH OBJECT" RESULT IN THE PRESENCE OF
> >REFERENCES?
> >
> 
> This seems like a reasonable thing to put in the draft. I think it's
> implied by the document which is, of course, obivous to the authors, but
> perhaps not obvious to everyone else.

Not obvious to me for sure. This is what I came up with when trying to
understand the draft's implications and what Mark Smith answered:

Me>  A reference that is subordinate to a normal (non-reference) object
and
  that, in turn, has subordinate (directly or indirectly) normal objects
  held by the same server is difficult to interpret, at least for me. It
  can be used - I think - to 'glue' together servers which hold objects
  from the same naming context: some children of an object in one
server,
  some in another. I also think that this probably was not the intent.

Mark> I agree.  Perhaps that configuration should be disallowed.

Me> QUESTION: Can one naming context be split among different servers?

  In Section 5.1.1.2 of the draft it says "there are four cases", but I
  only found three. Maybe in the missing fourth case is the answer to
both
  previous and (related) next question:

  QUESTION: Does the server ever return NO SUCH OBJECT result (assuming
  that superior reference is present), or is it up to the client to
  realize that there is, indeed, no such object from the fact that
  referrals loop?

Mark> In the absence of any smarts about whether a default superior
reference
  will be returned, I think a server will always return one if it has
  one.  But I don't expect all servers to be configured with a superior
  reference.  Loops are bad and should be avoided when configuring
  referrals.


In short, if the information about when does the server return "no such
object" result is implied in the draft, the implication is burried under
much more weird ones. This should be made explicit.


> Sorry it took a while to get on this, but work on these things tends to
> be fitful.

No problem! I understand. I just did not know how long to wait before
giving up.

Thanks a lot!

-- 
Leonid Dubinsky                  Engineer
All opinions are mine, not my employer's.