>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
