Subject: Re: Protocol: Ignore SEQUENCE elements...

From: John McMeeking <[email-masked]>
Date: Wed, 17 Sep 2003 08:54:21 -0500

I do not like the notion of a blanket statement to ignore unknown values in
an ENUMERATION or CHOICE type.  I don't think that it makes any sense for
any of the existing CHOICE or ENUMERATED types, with the possible exception
of resultCode.

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.

Yes,  X.680 does allow for extensible types, but you must explicitly define
them as extensible (using "...") and presumably the type "designer" has
considered the ramifications of making a given type extensible.

John  McMeeking

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 18 Sep 2003 11:10:00 +1100

John,

> extension (control) is supported, and by including a 

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