ASN.1 across revisions

Paul Long Plong at SMITHMICRO.COM
Sun Jun 28 20:12:14 EDT 1998


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

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
    }
>
>> 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? 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'..."
>
Paul Long



More information about the sg16-avd mailing list