>   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.
>
>   This appears very wrong, it appears that a standards group is trying to
>   change the meaning of another standards groups work just to solve their
>   own specific problems. Surely this is illegal. Otherwise we could have
>   a different version of ASN.1 for each protocol! This defeats the whole
>   purpose of having ASN.1 as a seperate and *independant* standard.

In general, ASN.1 tools should have this capability anyway as
other OSI standards specify rules-of-extensibility that require
a reveiver to ignore unknown tags in SET and SEQUENCE and
enumerated BIT STRINGs.  This requirement however, usually
relates only to the 'connect PDU' or equivalent (I cannot,
offhand, think of an example where it is required elsewhere),
and elsewhere such errors must be detected as such.  This
requires one to have the facility to invoke the decoder function
with a 'rules-of-extensibility-flag' or some such device.

>   I submit that intended and much better method to solve their problems
>   is to set aside another bit in the Versions field of the Bind for 1992
>   extensions. If you can negotiate the 1992 Version you can send the extended
>   PDUs otherwise you can't.

This would seem to be in accordance with other standards.

Alan Young.