[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP Extension Style Guide, re interaction between controls



Date sent:      	Fri, 18 Aug 2000 10:01:00 -0700
To:             	d.w.chadwick@salford.ac.uk
From:           	"Kurt D. Zeilenga" <Kurt@OpenLDAP.org>

> The issue is that the extension, as defined by two recognized
> controls, is NOT understood because the semantics of the
> combination is not defined.
> 

Sorry, missed that point

> LDAP allows for a non-critical control to be ignored. 

This is the bit that, on its own, would come into conflict with X.500 if 
the aforementioned defect is accepted.

> This
> implies that if a request contains two controls, one critical
> and one not, is submitted to a server which recognizes BOTH
> controls but does not understand the semantics of the
> combination, the server must either:
>   a) return unavailableCriticalExtension
>   b) perform the operation as if the non-critical extension
>   was not specified.
> 
> I prefer option a) as it follows from the similar case:

I do too, as this is the same as if both were critical, and would be in 
the spirit of the X.500 defect correction.


> a request contains two controls, a recognized critical
> control and a unrecognized non-critical control.

In this case I would suggest option b) is followed, as the server only 
understands one of the controls, and is obeying it.

But what about the case of two controls, both non-critical, both 
understood in isolation, but the combination not. What does the 
server do now - selectively ignore one of them? If so which one?

I think the PKIX and X.509 guys may also hit the above problems, 
given that certificate extensions are object identifiers and can be 
defined by anyone. I will raise this topic on the PKIX list. 

David

P.S. The problem does not (or should not) arise for DAP as all the 
extensions (controls) are specified together as a whole in one 
document, and each extension is identified by an integer. 
Interactions should be fully spelt out in the base standard, and 
private extensions cannot be defined (legally).

> 
> However, I can see the value offered in option b.
> 
> >I would like LDAP to 
> >either take the same stance for compatibility purposes, or to 
> >persuade the X.500 , PKIX and other groups that the proposed 
> >solution is wrong and that the server should be free to choose what
> >to do. Either way, I think that compatibility should be the target.
> 
> I concur!
> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************