ASN.1 across revisions

Bancroft Scott baos at OSS.COM
Sun Jun 28 22:14:32 EDT 1998


On Sun, 28 Jun 1998, Paul Long wrote:

> >From:        Bancroft Scott[SMTP:baos at OSS.COM]
> >It is an error for encoders not to encode extension additions that are
> >mandatory but missing if such extension additions do not occur within an
> >extension addition group and if no other extension addition values follow
> >the missing but mandatory extension. (I don't believe H.225 employs
> >extension addition groups (i.e., the "[[" and "]]" notation.))  This is
> >indicated in X.680:1997 clause 7.1 (X.680:1994 Amd.1 clause 6.1) which
> >unconditionally mandates that it be possible for decoded components that
> >are defined to both the sender and receiver be re-encodable by the
> >receiver.
>
> So, Bancroft, are you saying that it would be an error if FooGone,
> below, were encoded where Foo was called for?
>
>     Foo ::= SEQUENCE
>     {
>         bar                 INTEGER (0..127),
>         ...,
>         baz                 INTEGER (0..255) OPTIONAL,
>         integrityCheckValue ICV OPTIONAL,
>         importantExtension  SomeType OPTIONAL,
>         criticalExtension   OtherType
>     }
>
>     FooGone ::= SEQUENCE
>     {
>         bar                 INTEGER (0..127),
>         ...,
>         baz                 INTEGER (0..255) OPTIONAL,
>         integrityCheckValue ICV OPTIONAL,
>         importantExtension  SomeType OPTIONAL
>     }

No.  I am saying that such an encoding must be possible without an error
being signalled by the encoder, for it may be that the v3 encoder (which
knows about criticalExtension) is simply re-encoding a v2 message (in
which criticalExtension is not defined), something that clause 7.1 says
must be possible since everything in Foo is defined to both v2 and v3.
Note, however, that X.691:1997 clause 24.14 (X.691:1994 Amd.1 clause "11
Changes to SEQUENCE") stipulates that if you are originating an encoding
(i.e., not relaying it) you are required to encode criticalExtension.

> Likewise, are you saying that it would be an error if FooOpt, below,
> were encoded, without the value of criticalExtension present, in place
> of Foo, because the extension addition is mandatory in Foo?
>
>     FooOpt ::= SEQUENCE
>     {
>         bar                 INTEGER (0..127),
>         ...,
>         baz                 INTEGER (0..255) OPTIONAL,
>         integrityCheckValue ICV OPTIONAL,
>         importantExtension  SomeType OPTIONAL,
>         criticalExtension   OtherType OPTIONAL
>     }

This change to the type is transparent to the communicating peer.  Indeed,
unless you go out of your to indicate to the encoder whether you are
originating and encoding it is impossible in ASN.1:1994 for an encoder to
know whether the absence of criticalExtension is an error.  In ASN.1:1997
this imprecision is resolved by the use of version brackets.  For example,
if you wrote:

     Foo ::= SEQUENCE
     {
         bar                 INTEGER (0..127),
         ...,
         [[,
           baz                 INTEGER (0..255) OPTIONAL,
           integrityCheckValue ICV OPTIONAL,
           importantExtension  SomeType OPTIONAL,
           criticalExtension   OtherType,
         ]]
     }

it would be clear that baz - criticalExtension were all added in the same
version, so if any of the optional items are present then
criticalExtension must also be present.  Contrast this with, for example:

     Foo ::= SEQUENCE
     {
         bar                 INTEGER (0..127),
         ...,
         [[
           baz                 INTEGER (0..255) OPTIONAL,
           integrityCheckValue ICV OPTIONAL
         ]],
         [[
           importantExtension  SomeType OPTIONAL,
           criticalExtension   OtherType
         ]]
     }

where the first pair of version brackets indicate the components that were
added in version 2, and the second set of version brackets indicate those
that were added in version 3.  In this case it is clear that baz can be
present and criticalExtension absent.  It is also clear that if
importantExtension is present then criticalExtension must also be present
since knowledge of importantExtension implies knowledge of
criticalExtension, which is mandatory.

BTW, a side effect of the use of version brackets is that all components
within a version bracket pair is encoded as if it were a SEQUENCE type,
which is then encoded as an open type value.  This means that if you have,
say, eight mandatory BOOLEANs within version brackets, you would encode
the eight BOOLEANs together in a single byte, then encode that as an open
type value so that the final encoding takes 2 bytes.  Without the version
brackets the same eight BOOLEANs would have a final encoding of 16 bytes
(extension addition count and bitmap not included in either case).

Notice that a v2 decoder that does not understand version brackets would
treat a v3 encoding whose new extension additions employ version brackets
as if the version bracket encoding were the encoding of a single extension
addition that it not defined to it, so use of version brackets is 100%
backward compatible when used to group components added in newer versions.

> >> Solution 1: Clarification to the PER Encoding Process
> >>
> >>    The text in PER document (X.691, 1994) is somewhat ambiguous how many
> >>    bits should be included in the extension present bitfield of SEQUENCE.
> >>To
> >>    quote verbatim: "Let the number of extension additions in the type being
> >
> >Note that it says the *type* being encoded, not the value.  That's
> >distinct from the value.
> >
> >>    encoded be "n", then a bit-field with "n" bits shall be produced for
> >>    addition to the field-list." (Is the "type being encoded" the abstract
> >>    syntax or an actual value like { bar 1, baz 2 }?)  However, the 0 bits
> >>at
> >>    the end of extension present bitfield can be left out without changing
> >>    the resulting semantics: the corresponding extensions are not present.
> >
> >It is true that they can be left out without changing the semantics, but
> >this is not what PER mandates (It should have mandated what you suggest,
> >but hindsight is 20-20.)  Unless everyone encodes according to PER its
> >canonical nature will be lost.
>
> So are you saying that if an ASN.1 type in a Recommendation contains an
> extension addition, such as criticalExtension in Foo, above, an
> implementation of that Recommendation _must_ represent that extension
> addition in all encodings of that type? IOW, although it may be "easy"
> to encode the type without that extension addition (the
> extension-addition bit-map does not contain a corresponding bit for that
> extension addition, the bit-map length value reflects this shortening,
> and the open type containing the value is not encoded), the encoding
> would be in error?

It is in error only if you are originating the encoding in which
criticalExtension is defined.  ASN.1:1994 does not have syntax that makes
it possible for an encoder to determine whether criticalExtension is
unconditionally mandatory (it would be if all four extension additions
were added in the same version), or if it were added after the other
extension additions (in which case it would be mandatory only if the
sender is originating the message.)

> If so, I assume this would be because, technically,
> another type was being encoded, not the one defined in the
> Recommendation, as in "Let the number of extension additions in _the
> type being encoded_ be 'n'..."

I don't follow what you mean here.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
baos at oss.com                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636



More information about the sg16-avd mailing list