Hello,
I'm a novice user of ASN.1 and have some questions about how ASN.1 compilers
handle information objects and their use in building dependent types. Suppose
I have a simple example like the following:
Test DEFINITIONS AUTOMATIC TAGS ::= BEGIN
TEST ::= CLASS {
&code INTEGER (0..65535) UNIQUE,
&Type
}
test1 TEST ::= { &code 0, &Type BOOLEAN }
test2 TEST ::= { &code 1, &Type INTEGER }
Tests TEST ::= { test1 | test2 }
Test ::= SEQUENCE {
code TEST.&code({Tests}),
valu TEST.&Type([EMAIL PROTECTED])
}
END
>From a type-theoretic viewpoint I suppose you could view Test as a dependent
>type, with the type of the second component depending on the value of the
>first component. One natural representation of such a type in C++ might be as
>an abstract type, with subtypes for each of the possible types of valu, as
>determined by the rows in the information object set. This would have the
>advantage that the type of valu and the value of the code field would always
>respect the constraints of Tests, as there would be one subclass for each row
>of this object set. A brief look at the way such an example is encoded in
>real ASN.1 compilers suggests this isn't the approach adopted, presumably
>because of concerns about the potential number of subclasses, dynamically
>extensible sets etc. Instead valu appears to be treated as a completely open
>type. With that approach when do the constraints implied by the object set
>typically get enforced? Do the "setter" methods for code and valu check the n
ew configuration corresponds to a row in the object set? Or is this just done
at encode time? Or not at all? And similarly when decoding does the runtime
use the code value to drive the decode of the valu field? At first glance it
looks like the user application has to replicate the dependent type information
implied by the object set to completely decode the PDU, but perhaps I'm missing
something here?
When encoding values like these I believe, perhaps incorrectly, that the valu
field, as an open type, will be prefixed by its length in PER. In some cases,
depending on the allowed types of valu, the length will presumably be
inferrable from the type of the valu field, which in turn is determined by the
value of the code field in conjunction with the information set. Is ECN
expressive enough to be able to make use of the information sets to avoid the
overhead of this length field?
Finally, suppose I wanted to partially specify the map from code to type, for
example 0 -> BOOLEAN, 1 -> INTEGER etc, but wanted to associate a default type,
e.g. OCTET STRING, to everything else. I.e. if I received an encoded value
where the code field had a value that wasn't in the object set then treat the
valu field as an OCTET STRING. Now I could obviously add (a large number of)
rows to the object set to achieve this behaviour. But is there a neater way of
expressing such defaults?
I hope the questions don't illustrate my current ignorance of ASN.1 too much,
and thanks, in advance, for any help.
Kevin
--
XS2Mail: Check your mail anywhere http://www.xs2mail.com/
_______________________________________________
ASN1 mailing list
[EMAIL PROTECTED]
http://lists.asn1.org/mailman/listinfo/asn1
