From: Bancroft Scott[SMTP:baos@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
On Sun, 28 Jun 1998, Paul Long wrote:
From: Bancroft Scott[SMTP:baos@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@oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636
participants (2)
-
Bancroft Scott -
Paul Long