[Ietf-not43] Re: Requirement 3.1.8

[Peter Gietz]

Eric A. Hall wrote:

> on 8/19/2003 12:25 PM hardie at qualcomm.com wrote:
> 
> 
>>There seem to me too different cases here:
>>
>>1) Server needs to say "I won't provide $YOU with service"
>>
>>and
>>
>>2)Server needs to say "I won't return results to $QUERY to $YOU".
>>
>>I understand how the bind mechanisms apply to 1.  The question,
>>as I understand it, is how to satisfy 2.  If there are multiple ways
>>it could be solved in FIRS, could you please pick any one of them
>>and describe it in medium-level detail, so that we can move past
>>the question of whether this requirement is met?
> 
> 
> I have added the following sentence to the discussion on the firsVersion
> control in core-03 (not-yet published):
> 
>   Servers MAY adjust the list of supported resource types as necessary
>   or desirable.
> 
> This essentially means that a server can tell client-X that a particular
> resource is supported while telling client-Y that the exact same resource
> is not supported. Since the firsVersion control is encouraged to be
> returned in response to a successful bind, this mechanism imposes no
> additional mandatory round-trips.
> 

Either the client has to include the query it wants to send in the bind 
control, or Ted's 2) is not fulfilled.

I still don't really understand 2) anyway. What is the difference between:

2a) client sends $QUERY in a search request; server says "I won't return 
results to $QUERY to $YOU"

2b) client asks what would you do if I send $QUERY; server says "I won't 
return results to $QUERY to $YOU"

That is why I thought 2b would make more sence if the client can 
retrieve general server policy published as LDAP data (Solution A).

A search control with the function "don't perform the search, just tell 
me, if you would answer this request" as alternative is even easier to 
specify. (Solution B)

It would sort of be the same as specifying this in the bind control, 
with intended query data given by the client with the bind request. But 
then the answer would be only for one specific query, or the client 
would send a list of all intended queries. (Solution C1)

Or and this seems to be the path Eric wants to follow, the server gives 
back a general answer together with the bind response to the client what 
kind of queries it is willing to answer to this particular client. 
(Solution C2) This would be similiar to the policy publishing solution, 
but not expressed in LDAP data, but in the bind control response.

What I want to say here is
- However 3.1.8. is to be interpreted, there are several solutions to 
fulfil it

- Solution C2, as Eric seems to propose is doable, but it needs a 
detailed specification of what kind of entries (defined by object class) 
and what kind of attributes (defined by an attribute list) will be 
returned to this particular client. If there are different policies for 
different subtrees, the DN of the subtree has to be specified as well. 
So an answer could be something like:

dn: x=y, dc=xxx, dc=yyy$oc: inetOrgPerson$at: attr1, attr2, attr3$oc: 
inetIpv6Network$at: attr4, attr5, attr6
dn: x=z, dc=xxx, dc=yyy$oc: inetOrgPerson$at: attr1, attr2, attr3

With this, a client can compute, which kind of queries will be serverd 
and which won't.

Cheers,

Peter



-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: peter.gietz at daasi.de
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________