2. Because of backend restrictions, clients have to handle the unsupportedCriticalExtension any way. Then, why have supportedControls it in the root DSE? Are the root DSE supportedControls a way to tell clients "don't even think about it :=)" ?
Thanks,
Mircea.
Mark C Smith wrote:
MIRCEA PANA wrote:
>
> In RFC2251, section "4.1.12 Controls", last paragraph specifies:
> "Servers list the controls which they recognize in the supportedControl
> attribute in the root DSE"
>
> How should this be interpreted?
> Option 1: "Servers SHOULD list all the controls which they recognize in
> the supportedControl attribute in the root DSE"
> Option 2: "Servers MAY list (some of the) controls which they recognize
> in the supportedControl attribute in the root DSE".My opinion is that Option 1 makes the most sense, i.e., this should be a
SHOULD.> The same question goes for RFC2252, section "5.2.4 supportedControl"
> which specifies: "The values of this attribute are the OBJECT
> IDENTIFIERs identifying controls which the server supports. If the
> server does not support any controls, this attribute will be absent."
> Should this read: "... identifying all the controls which the server
> supports."
> or should it read: "... identifying (some of the) controls which the
> server supports."I vote for "all."
> Or put it this way:
> How should a client deal with extensions?
> Option A: The client should search the root DSE to find out if a
> specific control is supported. If not in the "supportedControl" list of
> OID.s, then the client should not attempt to use the control.
> Option B: The client should ignore the root DSE's "supportedControl"
> list of OID.s and attempt to use the control any way. The server should
> then perform according to the specifications of RFC2251, section 4.1.12.I think either approach is valid for clients (try to use a control and
handle failures OR check the rootDSE before trying to use a control).
Note that some controls may be supported only on certain parts of the
DIT anyway due to chaining or other "backend" restrictions.--
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's. Got LDAP?
begin:vcard n:Pana;Mircea tel;pager:+1-613-364-1385 tel;fax:+1-613-591-3680 tel;work:+1-613-599-3600 x6907 x-mozilla-html:TRUE url:http://www.newbridge.com org:Newbridge Networks;Messaging and Directory Systems version:2.1 email;internet:mpana@newbridge.com title:Systems Architect adr;quoted-printable:;;PO Box. 13600.=0D=0A600 March Road;Kanata;Ontario;K2K 2E6;Canada fn:Mircea Pana end:vcard