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 }
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:
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.
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.
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.)
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