Hi Kevin,
Okie...this is my explanation for the enforcement of the ObjectSet
constraint. The TypeField in class TEST is an open type. As you had
mentioned, for type 'Test', the type of value is determined from the
ObjectSet.
The encoder processes the value of the 'valu' field based on the type
associated with the 'code' field. OpenType encoding is nothing but a
contained above the actual encoding of the Type. We might wonder why not
just use the actuallal encoding. The reason this is done can be explained as
follows. If @ the decoder the code is not recognized, then it would not be
possible to skip the 'valu' field unless its size is known. Hence the
OpenType wrapper is found.
While decoding, the value of 'code' is used to determine the type associated
with 'value'. And IF a matching type is known, the stream embedded in the
OpenType is decoded accordingly.
Verification of types cannot be asserted in PER. Lets say that value of
Type-A is being decoded as though it were Type-B. There is no was to
graefully handle this. This is the same reason, why the type of the embedded
open field cannot be verified assertively (thought it can be done to a
certain extent in BER).
If you do device a means to identify decoding using the wrong type, then the
same is applicable here. Remember that OpenType again encode's PDU and hence
no different, excepting for that they are embedded withing an ASN.1 stream
itself. Hope I did address your question here ;).
I have not idea bout ECN so ill leave that wkith the pros.
Well bout the default type, lets not ponder over a fancy solution. Lets just
keep things simple. You seem to have just 3 possibilities. So would it not
suffice to have 0 -> OCTET STRING (DEFAULT), 1 -> BOOLEAN and 2 -> INTEGER.
You could modify the Test as follows.
Test ::= SEQUENCE {
code TEST.&code({Tests}) DEFAULT 0, -- UNIQUE kwd in class TEST Needs to
be removed.
valu TEST.&Type([EMAIL PROTECTED])
}
Unless you have a stronger requirement for needing the DEFAULT type stuff
that you had ask for this could work.
Regards
Ramaswamy
-----Original Message-----
From: Kevin Mitchell [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 09, 2004 9:24 PM
To: [EMAIL PROTECTED]
Subject: [ASN1] Handling of information objects/dependent types
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
DISCLAIMER
This message and any attachment(s) contained here are information that is
confidential, proprietary to HCL Technologies
and its customers. Contents may be privileged or otherwise protected by law.
The information is solely intended for the
individual or the entity it is addressed to. If you are not the intended
recipient of this message, you are not authorized to
read, forward, print, retain, copy or disseminate this message or any part of
it. If you have received this e-mail in error,
please notify the sender immediately by return e-mail and delete it from your
computer
_______________________________________________
ASN1 mailing list
[EMAIL PROTECTED]
http://lists.asn1.org/mailman/listinfo/asn1
