From: Bancroft Scott[SMTP:baos@OSS.COM] On Sun, 28 Jun 1998, Paul Long wrote:

...

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 }

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.

Right, that's what I meant. I should have said, "Are you saying that--if originating the encoding--it would be an error if FooGone were encoded where Foo was called for?" With this qualification, your answer would apparently be, "Yes, it would be an error."

...

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.

Hey, I just realized something. When you say, "encoder," you are referring strictly to the ASN.1 encoder, right? I often think of the encoder as the larger, "encoding entity," such as an H.323 endpoint, which usually knows more than the encoder. I think you call this the "sender."

So if the encoder, using your definition, is presented with FooOpt, above, and a value is not provided to the encoder for criticalExtension, the encoder does not, of course, know that this is an error. What I'm saying is that if the sender, or encoding entity, uses FooOpt in place of Foo, and the value for criticalExtension is not present, the encoder is not at fault for producing an encoding, but the sender is at fault, because it is not using the prescribed definition of Foo for the version of the Recommendation of which it is an implementaion and which is identified in the protocolIdentifier field(s). To look at it from the other direction, the receiver, or decoding entity, doesn't care whether the encoder or the sender is at fault--it just knows that the sender is producing an incorrect 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.

Can't the same thing be done in ASN.1:1994 by encapsulating the extension additions of a particular version within a SEQUENCE like this?

FooEncap2 ::= SEQUENCE { bar INTEGER (0..127), ..., SEQUENCE { baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, criticalExtension OtherType } }

and this?

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

Seems like this would allow one to produce the same encoding with ASN.1:1994 as what would be produced by the version brackets in ASN.1:1997, or am I missing something? Perhaps this is how we should extend ASN.1 types in the future.

...

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?

It is in error only if you are originating the encoding in which criticalExtension is defined.

Okay, yes, I meant that one is originating the encoding. That's really the only way I think about encoding. Again, with this qualification, your answer would be, "Yes, it would be an error."

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'm saying that all four are defined in the same version of ASN.1 syntax and that 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.

Sorry. I meant that this citation from 18.7/X.691:1994 indicates to me that, for an originator, all extension additions defined for a type must be represented--one cannot simply leave off one or more trailing extension additions from a type that is defined in the version of the Recommendation that the sender has implemented, as would be the case if FooGone were used in place of Foo, for example. Likewise, for an originator, Foo is "the type being encoded," and an invalid encoding would be produced if FooOpt was used in place of Foo, and a value was not provided for criticalExtension.

Paul Long