On Mon, 3 Mar 2003, Edmond G wrote:
> The one open point is different handling of this case
> in ASN.1 standards. So if that's an older protocol
> using ASN.1 standard 208,209 , the adding and removing
> of zeros (trailing bits) is not allowed.
The addition and removal of zero trailing bits was allowed by X.208/X.209,
but it was not clearly stated. This is one of the things that X.680/X.690
clarifies. X.208 stated that an IdentifierList or (incredibly) a comment
could be used to indicate whether trailing zero bits were significant.
Also, it did not establish a default that said that if there is no comment
the trailing zero bits are (or are not) significant. In short, it was
ambiguous. The text focussed more on the needs of protocol specifiers and
was fairly clear on the significance of trailing bits when used in the
value notation, but was unclear/ambiguous as to how this carried through
in encodings.
> So for the decoder (in this case) would means invalid value and
> decoding error when the SizeConstraint is violated.
> Is this right?
As Tom, Bruno, Olivier and John pointed out, the size constraint applies
to the abstract value, not to the actual length found in the BER encoding.
For example, I might have the following two encodings:
03 02 04F0
23 08 23 06 23 04 03 02 04F0
These encodings are of different lengths, but the abstract value in both
cases is '1111'B. The size constraint applies to the '1111'B, not the
actual BER encoding. When a NamedBitList is used in defining the BIT
STRING, it is the responsibility of the decoder to ensure that the
value returned to the application satisfies the constraint, for trailing
bits could have been removed by the encoder.
-------------------------------------------------------------------------
Bancroft Scott Toll Free :1-888-OSS-ASN1
OSS Nokalva International:1-732-302-0750
[EMAIL PROTECTED] Tech Support :1-732-302-9669 x-1
1-732-302-9669 x-200 Fax :1-732-302-0023
http://www.oss.com
