Re: root knowledge

Colin Robbins <> Fri, 08 May 1992 09:00 UTC

Received: from by ietf.NRI.Reston.VA.US id aa03459; 8 May 92 5:00 EDT
Received: from by NRI.Reston.VA.US id aa05063; 8 May 92 5:05 EDT
Received: from by NRI.Reston.VA.US id aa05059; 8 May 92 5:05 EDT
X400-Received: by mta in / 400/C=gb/; Relayed; Fri, 8 May 1992 08:45:33 +0100
Date: Fri, 08 May 1992 08:45:33 +0100
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/ 400/C=gb/; bells.cs.u.831:]
Priority: Non-Urgent
DL-Expansion-History: ; Fri, 8 May 1992 08:45:33 +0100;
From: Colin Robbins <>
Message-ID: <"2510 Fri May 8 08:45:22 1992">
Cc:, "(Paul-Andre.PAYS)" <>,
In-Reply-To: <>
Subject: Re: root knowledge

This may be a simplistic response, and I may have missed some of the
points you are making.  However, why can't the X.500 protocols
themselves and some caching be used to obtain the knowledge required?

Taking c=GB for example, from the DIT (or local knowledge if you
like), you can establish the controlling DSA is one called "Inca Dove"
Why not bind to this DSA (DAP or DSP), and issue a request of the form:

subtree search baseobject:			 c=GB
	       filter:				 objectclass=organization
	       service control options:		 chainingProhibited
Because chaining is prohibited, the DSA will be forced to return a
partial outcome qualifier (POQ).  This will contain

	DN,	DSA Name,   DSA address

for each or the DSAs the "Inca Dove" would have to contact inorder to
complete the search.  If you cached this information, you could then
use it later to solve queries for the given DNs (i.e., When you need
to chain, look up the DN in a table of cached POQ's, and see if you
have any "DSA Name,   DSA address" information.  If you do - chain (or
issue a referral) to that DSA.

This will certainly work againt a QUIPU DSA, and I would expect it to
work against most other implementations.  There is a chance a DSA
could return "Error: Chaining required" or similar, (QUIPU won't!).
You may also need to bind as a particular authenticated user, as
some DSAs may heuristically prevent this form of searching for an
unauthenticated user - but that not a big problem. 

It just seems to be the right way to do it to me, no external agreements
about formats etc are needed, its all defined by X.500!