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

[Peter Gietz]

The first revision of the FIRS relay bag draft is almost done and I will 
post it to the list later today. I think I have included all comments 
made on the list. Ther is one comment from Steven, I didn't yet respond to:

Steven Legg wrote:
> Eric & Peter,
> 
> Eric A. Hall wrote:
> 
>>on 8/13/2003 8:37 AM Peter Gietz wrote:
>>
>>
>>>please find attached a first version of the promissed Draft on FIRS 
>>>Relay Bag.
>>
>>>   A FIRS client SHOULD evaluate if the server it initially 
>>
>>connects to
>>
>>>   supports this feature, by checking if the controlType Object
>>>   Identifier of the control specified in this document
>>>   (relayBagSearchOID) is stored in the attribute 
>>
>>supportedControl of
>>
>>>   the root DSE entry, which is specified in [RFC2251], section 3.4.
>>
>>I'll put some more time into this in a couple of days but the 
>>first thing
>>that jumps out at me is that this should be a MAY instead of 
>>a SHOULD. Too
>>many round-trips spent on query setup will make this service 
>>unusable for
>>fast lookups. There might be some other options for dealing 
>>with the need
>>for this, such as having the control returned as a bind 
>>response similar
>>to firsVersion.
> 
> 
> I don't see a need for any sort of check. The control in the request
> is required to be marked critical. The client should just send in its
> query with the control attached. FIRS-aware LDAP servers will do their
> job. Conformant LDAP servers that are not FIRS-aware will respond with
> the error unsupportedCriticalExtension.

After rereading the requirements I had to rephrase the criticality, 
since the requirements say in 3.1.13.1:
> The use of the relay bag MUST be OPTIONAL.

Thus the control in the request MAY be marked either critical or 
noncritical by the client. If marked non-critical the server may just 
ignore the control.

Nevertheless a server supporting the relay bag controll MAY refuse to 
serve a client request without the control (unwillingToPerform). Thus it 
does make sence for the client to check the rootDSE, it may do so after 
  receiving such an error code or before. If the client sends the 
request with the control marked critical the communication will be as 
you state above. If not, a root DSE lookup might make sence.


Cheers,

Peter




> 
> Regards,
> Steven
> 
> 
>>Also, does there need to be any wording on how the data should be
>>encapsulated within an LDAP URL?
>>
>>-- 
>>Eric A. Hall                                        
> 
> http://www.ehsco.com/
> Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
> 
> _______________________________________________
> Ietf-not43 mailing list
> Ietf-not43 at lists.verisignlabs.com
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43
> 

-- 
_______________________________________________________________________

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
_______________________________________________________________________