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

Reply via email to