guest@shl.com (Guest csh account (should be sh)) (02/01/91)
ASN.1 geniuses out there:
An ASN.1 definition is (it seems to me) a specification of a grammar.
Though the ASN.1 rules seem to make only context free grammars
specifiable, there seems to be no other rules about this grammar.
(It seems to me that) The easiest type of grammar for the Responder to
parse will be LL(1) so the responder may be a simple recursive descent
parser. Unfortunately, it is possible to write grammars in perfectly
legal ASN.1 notation which are not LL(k) for any fixed k.
Is there an unwritten rule in X.208/X.209 that `one shall specify only
grammars which are *EASY* to parse'?
I have an ASN.1 specification from a nameless client which falls (I
think) into the LL(k) where k > 1 category. The gist of this
definition is:
Choice1 ::= CHOICE {
[0] type1,
[1] type2,
[2] type3
}
Choice2 ::= CHOICE {
[1] type4
}
Maintype ::= SEQUENCE {
first Choice1 OPTIONAL,
second Choice2
}
So that the sequence { type2, type4 } is hard to distinguish from the
sequence { type4 }.
In my *particular* instance I have the additional knowlege that `type2'
is primitive and that `type4' is constructed, so I can get around the
conflict but is it in general `fair game' to use the constructor bit as
well as the class and tag-number to distinguish tags? I've always
thought that you weren't supposed to need it. And anyway, what if
`type2' were also constructed? Then what?
Thanks
Gardner Buchanan gardner@shl.com
Systemhouse, Ottawa
(613) 236-6604 x375Markku.Savela@tel.vtt.fi (Markku Savela) (02/01/91)
In article <1991Jan31.165316.616@shl.com> guest@shl.com (Guest csh account (should be sh)) writes: > I have an ASN.1 specification from a nameless client which falls (I > think) into the LL(k) where k > 1 category. The gist of this > definition is: > Choice1 ::= CHOICE { [0] type1, [1] type2, [2] type3 } > Choice2 ::= CHOICE { [1] type4 } > Maintype ::= SEQUENCE { > first Choice1 OPTIONAL, > second Choice2 > } That defition is not valid ASN.1 The tags of the first and second must be distinct: 25: Maintype ::= SEQUENCE { 26: first Choice1 OPTIONAL, 27: second Choice2 ** ERROR on line 27 : Non-distinct tag: [Non-distinct tag: [1] (I think that the syntax defined by ASN.1 is *always* LL(1) or LL(0)). -- Markku Savela (savela@tel.vtt.fi), Technical Research Centre of Finland Telecommunications Laboratory, Otakaari 7 B, SF-02150 ESPOO, Finland
fetter@cos.com (Bob Fetter) (02/04/91)
That is a wonderful example of bad specification. You really should *not* rely on Constructed/Primitive as a clue to determining the class of data. Degenerating the tag down to it's base Universal type should give you the rules for constructed/primitive, but this path is based on manipulating the tag first, *then* worrying about construction. If at all possible, the specification should be reworked to remove this ambiquity. I can only hope that this isn't sprung from some standard, but is based on a local use of ASN.1. As an aside chuckle, isn't Ada (tm) supposed to be *another* language in which it's impossible to make an error, as it's so well specified? :-) But, if not, then that's what NIST OIW and EC EWOS is all about, I guess... -Bob-