[Ietf-not43] First draft on Relay bags in FIRS

[Peter Gietz]

Andrew,

Thanks for your valuable comments.

Andrew Newton wrote:
> Peter,
> 
> What you have defined seems to be fairly straight forward.  However, I 
> think it needs further refinement per the requirements.

Yes that is what I wrote in the Open Issues section.

> 
> Peter Gietz wrote:
> 
>>
>>    Servers that support this control MAY decide to only serve clients
>>    that support and use this control.  If a server wants to thus enforce
>>    the control, every search request without this control SHOULD be
>>    responded to with the resultCode unwillingToPerform (53).
> 
> 
> This does not cover all the error conditions listed:
> 
> from 3.1.13.1
> 
>>    The protocol MUST provide different error messages to indicate
>>    whether the bag is of unrecognized format (permanent failure), if it
>>    contains unacceptable data (permanent failure), or if it contains
>>    data that means processing is refused at this time (transient
>>    failure).
> 
> 
> Also, it would seem that for best interoperability, the error codes for 
> bags should be specific to the use of the control.  As in, "unwilling to 
> perform (generic reason)" and "unwilling to perform because bag is 
> unrecognized".

Well, I thought we should try to use the already defined LDAP error 
codes. I have BTW never seen an LDAP specification that uses error codes 
not specified in RFC2251. There is an expired but quite valuable Draft 
(http://www.watersprings.org/pub/id/draft-just-ldapv3-rescodes-02.txt) 
that deals with LDAP error codes. having gone through that document 
again, I propose the following error codes:

the bag:
1.) is of unrecognized format (permanent failure): protocolError (2)
2.) contains unacceptable data (permanent failure): unwillingToPerform
    (53)
3.) contains data that means processing is refused at this time
     (transient failure): busy (51)

To quote the afore mentioned document:
> 5.2.2.4.2 protocolError(2)
> 
>    Applicable operations: all.

>    A protocol error should be returned by the server when an invalid or
>    malformed request is received from the client. This may be a request
>    that is not recognized as an LDAP request, for example, if a
>    nonexistent operation were specified in LDAPMessage.  As well, it may
>    be the result of a request that is missing a required parameter, such
>    as a search filter in a search request. If the server can return an
>    error, which is more specific than protocolError, then this error
>    should be returned instead. For example if the server does not
>    recognize the authentication method requested by the client then the
>    error authMethodNotSupported should be returned instead of
>    protocolError. The server may return details of the error in the
>    error string.

> 5.2.2.4.9 unwillingToPerform(53)
> 
>    Applicable operations: all.
> 
>    This error code should be returned by the server when a client
>    request is properly formed but which the server is unable to complete
>    due to server-defined restrictions.  For example, the server, or some
>    part of it, is not prepared to execute this request, e.g. because it
>    would lead to excessive consumption of resources or violates the
>    policy of an Administrative Authority involved [X511, Section 12.8].
>    If the server is able to return a more specific error code such as
>    adminLimitExceeded it should. This error may also be returned if the
>    client attempts to modify attributes which can not be modified by
>    users, e.g., operational attributes such as creatorsName or
>    createTimestamp [X511, Section 7.12]. If appropriate, details of the
>    error should be provided in the error message.

> 5.2.2.4.7 busy(51)
> 
>    Applicable operations: all.
> 
>    This error code may be returned if the server is unable to process
>    the clientÆs request at this time. This implies that if the client
>    retries the request shortly the server will be able to process it
>    then.
> 

If I hear no protest, I will align the draft along these lines.
We could additionally specify apropriate errorMessages the server should 
return along with the error code, which may contain FIRS specifics 
without breaking the LDAP protocol.

If people insist in defining new error codes for FIRS, we may want to 
return them in a dedicated FIRS control and not in the resultCode field.


> 
> Finally, a question.  Is this one bag per referral or one bag per 
> response/result set?


No, and this has implications for the relay bag: The searchresponse can 
include an unlimited number of referrals but only one controlValue. That 
is why I sort of asumed that the Relay Bag contains only general 
information about the referring server and about what that server has to 
say about the client (authentication status, etc.).

If the Relay bag has also to contain information about the referred to 
server, we would have a problem here.


Cheers,

Peter

> 
> -andy
> 

-- 
_______________________________________________________________________

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
_______________________________________________________________________