>  I must agree with you. Unless ASN.1 has undergone a big change in this
>  regard (which is possible I suppose) you are not allowed to just ignore
>  tagged types that don't match. People have no doubt spent a great deal of
>  effort (coding and testing) trying to get ASN.1 parsers to pick up
>  all these types of problems and correctly report a decoding problem.

Humm. I believe we have a different reading of ASN.1 + of the "be
tolerant with what you receive" pragma. The decoding routine generated
by the MAVROS compiler incorporate the following features:

* Verify the presence of all Mandatory elements in SET or SEQUENCE, and
  report an error if one such element is missing.

* Verify the syntax of all Mandatory and Optional elements which happen
  to be present.

* Complain if a SET includes two occurences of a tagged element, or if
  a SEQUENCE contains unexpected elements before the last mandatory
  element has been decoded.

* IGNORE, and skip over, unexpected tagged elements within sets or at
  the end of sequences.

This was programmed before the "extensibility" rules were defined. I
presume that in order to comply with this new rules, we should somehow
pass to the application the unexpected elements, instead of merely
ignoring them.

The rationale is simple: unexpected elements "don't hurt" as long as
all mandatory elements are present -- the message still "makes sense".
As a consequence, the 88 DUAs generated with the MAVROS compiler, e.g.
SNI's "DIR-X" or E3X "Pizarro", will gracefully support the 1992
extensions to X.500.

Christian Huitema