Handling of unexpected ASN.1

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

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

I don't think Net::LDAP can handle this. Well, I think this is really
something that Convert::ASN1 cannot handle. eg:

-------------------
my $decode = Convert::ASN1->new();
my $encode = Convert::ASN1->new();
# Attempt to allow for extra stuff when decoding
$decode->prepare(q<
		 SEQUENCE {
		     version INTEGER,
		     name    OCTET STRING,
		     ext     ANY OPTIONAL
		 }
		 >);
$encode->prepare(q<
		 SEQUENCE {
		     version INTEGER,
		     name    OCTET STRING,
		     flag    BOOLEAN,
		     foo     PrintableString
		 }
		 >);

my $pdu = $encode->encode(version => 1,
			  name => 'cn=Chris Ridd',
			  flag => 1,
			  foo => 'foo');

my $o = $decode->decode($pdu);
# Returns undef.
-------------

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.

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

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

Does this make any sense?

Cheers,

Chris