Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!shl!guest
From: guest@shl.com (Guest csh account (should be sh))
Newsgroups: comp.protocols.iso
Subject: ASN.1 defn. is a grammar?
Keywords: ASN.1, grammar
Message-ID: <1991Jan31.165316.616@shl.com>
Date: 31 Jan 91 16:53:16 GMT
Reply-To: gardner@shl.com
Organization: SHL Systemhouse Inc.
Lines: 48

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 x375