On Fri, 21 Nov 2003 [EMAIL PROTECTED] wrote:
> Thanks for reply,
>
> >
> > Hi,
> > If a SEQUENCE is extended then I understand that
> > implication/impact of the OPTIONAL/DEFAULT keyword is for the
> > encoder only. For that particular spec, the encoder will
> > expect the mandatory elements following the extension
> > (otherwise the specified value may be considered invalid -
> > strictly).
>
> I agree.
>
> > It is possible that the sender complies to the
> > same SEQUENCE but with no elements following the extension
> > marker (the sender having a previous version of the
> > specification). Hence as far as the decoder is concerned, it
> > would have to consider all elements following the extension
> > as OPTIONAL (of course not the individual elements of an
> > extension group, when only the group itself would be
> > optional).
>
> Right. I don't know yet how to deal with this, but that's in the future:-)
>
> > As for whether to decode the tag or not (for
> > trailing elements after the last mandatory element- NOTE that
> > elements following the extensions are considered non
> > mandatory) will depend of the remaining length of the
> > SEQUENCE value after decoding till the last mandatory
> > element.
>
> Yes, I didn't realize this.
>
> > If in the spec an element of the extension addition
> > is mandatory, then the decoder must assume the possibility of
> > the absence of the same (remember that this mandatory nature
> > applied to the encoder only). The remaining length (if kept
> > tab on) will ward off the factor of no. of tags to be
> > considered that was mentioned, or atleast limit it to the
> > SEQUENCE at hand, which is leaves the problem bounded.
>
> Yes, the problem is bounded in the SEQUENCE. But still... Look at the
> example:
>
> If the decoder will have this structures:
> S ::= SEQUENCE {
> a INTEGER,
> b BOOLEAN OPTIONAL, --version 1
> ...
> c C OPTIONAL
> }
>
> C ::= CHOICE {
> ca INTEGER,
> cb OCTET STRING,
> }
>
> Then, when it recieves new version:
> S ::= SEQUENCE {
> a INTEGER,
> b BOOLEAN OPTIONAL,
> ...
> e ENUMERATED -- version2
> ...
> c C OPTIONAL
> }
>
> Then before skipping e, it must check the tag with tags of both - ca and cb.
> And what if C could have extensions too?
>
> C ::= CHOICE {
> ca INTEGER,
> cb OCTET STRING,
> ...
> }
>
> Is this incorrect for Asn1 or is there a way to handle such cases?
> Thanks
>
> Vit Novak
>
ASN.1 does not allow ambiguity like this. Look at X.680 clause 48 to see
why this spec would be invalid if C has an extension marker.
Paul
----------------------------------------------------------------------------
Paul E. Thorpe Toll Free : 1-888-OSS-ASN1
OSS Nokalva International: 1-732-302-0750
Email: [EMAIL PROTECTED] Tech Support : 1-732-302-9669
http://www.oss.com Fax : 1-732-302-0023