Re: Handling of unexpected ASN.1

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> 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

Yes, I tend to agree.

>> 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 ?

Something like that.

> 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.

Hm. If we limited this to just ignoring stuff at the end would it be
simpler?

> Graham.



Cheers,

Chris