Subject: RE: New draft on knowledge references in LDAP

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 13 Jul 2000 12:39:27 +1000

Roland,

I was a little confused by your description of the nssr attribute.

In a search result, do you actually return the attribute as part of the
entry it is in?

Why isn't NSSR processing invoked as part of a one-level search, or is it
your intention that the client should see the nssr attribute in the result
and act on it as if it were a continuation reference?

The X.500 model would have the nssr attribute in the superior entry
(otherwise it couldn't be non-specific) and wouldn't return it without the
manageDsaIt bit. It is not clear to me how you intend it should be used.
X500 compliant implementations would not return multiple entries relating to
the nssr entry.

Ron.

-----Original Message-----
From: Roland Hedberg [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 6:43
To: [email-masked]
Cc: [email-masked]
Subject: New draft on knowledge references in LDAP

Could you please publish the attached draft.

-- Roland
------------------------------------------------
Roland Hedberg      phone     : +47 23 08 29 96
Dalsveien 53        mobile(NO): +47 90 66 44 52
No-0775 Oslo        mobile(SE): +46 70 520 420 3
Norway

---

From: Roland Hedberg <[email-masked]>
Date: Thu, 13 Jul 2000 09:24:26 +0200

Ron,

> In a search result, do you actually return the attribute as part of the

No.
 
> manageDsaIt bit. It is not clear to me how you intend it should be used.

The intention was that the 'nssr' attribute would act as it's X.500 
equivalent.

More specifically there are two special cases where 'refer;nssr' is
needed: 
1) where a organization wants to keep the authority for a entry
even is all the children to that entry is managed by another organization.
2) when someone would like to support onelevel searches in a efficient
way when several entries on one level resides on different servers.

> X500 compliant implementations would not return multiple entries relating to

I'm not sure, given that you don't have chaining and therefore can not
rely on any intermediate server to remove duplicated entries, how you 
would go about to avoid duplicated entries.
The servers involved have no idea what has happend before or what is 
happening after they get the query, both acts as if they where the only 
one asked. So only the client has the complete picture.

-- Roland