ASN.1 defn. is a grammar?

Thread View: comp.protocols.iso

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Guest csh account (should be sh) Thu, 31 Jan 1991 16:53

#1083

Author: Guest csh account (should be sh)
Date: Thu, 31 Jan 1991 16:53

48 lines
1990 bytes

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

Re: ASN.1 defn. is a grammar?

#1087

Author: Markku Savela
Date: Fri, 01 Feb 1991 07:34

25 lines
1575 bytes

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

Re: ASN.1 defn. is a grammar?

#1098

Author: Bob Fetter
Date: Mon, 04 Feb 1991 04:55

21 lines
1262 bytes

  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-

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads