Re: Handling of unexpected ASN.1

[Graham B. <gb...@po...>]

On Fri, Mar 23, 2001 at 05:22:33PM -0000, Chris Ridd wrote:
> (Obscure concern coming up!)
> 
> I believe that LDAP clients/servers are meant to be able to ignore
> 'unexpected' elements in ASN.1 SEQUENCEs (RFC 2251 section 4 para 1). This
> is to promote compatibility with future clients/servers which may be using
> a version of the protocol with extra stuff in.
> 

> If there is only one extra parameter in the encoded SEQUENCE, the 'ANY'
> catches it, which is correct. More than one extra parameter though, and the
> decode rightly fails.

I think this should be done as an option to the decoder, rather than modifying
the ASN.1

> What is needed (I think) is for a mechanism to allow for 'all remaining'
> elements of a SEQUENCE to end up in a single variable. In the Convert::BER
> days, this was done with a magic 'BER' type. This is OK if all the new
> extensions in the SEQUENCE are added at the end of the SEQUENCE - there's
> no guarantee that they will be all at the end of course...

Hm, well I cannot see an easy way to support new elements anywhere without
a considerable slowdown.

> Alternatively, there should be a way to configure a Convert::ASN1 object to
> ignore unknown things when decoding. (This option shouldn't be the default.)

Are you saying an option to skip anything unknown and ignore extra at end
of sequences, just as long as everything expected is extracted ?

That sounds simple, but becomes more complex when you have to consider the
situation where a new element is added before an existing element which is
already optional.

Graham.