RE: Protocol: Ignore SEQUENCE elements...

["Steven Legg" <steven.legg@adacel.com.au>]

John,

John McMeeking wrote:
> I also have problems with doing this for SET and SEQUENCE.  I 
> am willing to
> accept it only because it is easier to make a general 
> statement about how
> the server should behave: as if they weren't there.  But even then, it
> requires some level of confidence that implementations really 
> do ignore
> ignore these extensions (i.e. a test suite that injects such 
> constructs).
> And I'm not sure what the ramifications are to a client 
> application for
> such a blanket statement.  Presumably the client has to deal with the
> possibility that the extensions are not supported.  We handle this in
> controls by providing both a method for the client to discover if the
> extension (control) is supported, and by including a 
> criticality indicator
> in the client request.

X.500 deals with such situations with the criticalExtensions BIT STRING
in the CommonArguments. Each feature added to the ASN.1 through extensibility
has an associated bit in criticalExtensions. The client sets the bits for
features it is using and which it requires the server to support.
If the server does not understand a bit, or doesn't support the feature
it represents, then the operation is failed. If a bit is not set then a
server is free to ignore the extensions for that feature.

I agree with Jim's assertion that some extensions make more sense as
extensions to the ASN.1 rather than as controls. In the future, if one
or more such extensions are to be added to LDAP then something like
the criticalExtensions BIT STRING could be added to LDAP at the same time
(e.g. as a critical control). Alternatively a simple null-valued control
(also critical) could be defined for each feature that extends the ASN.1.
The presence of the control is equivalent to the bit being set. The absence
of the control is equivalent to the bit not being set.

Regards,
Steven