Subject: ASN.1 SET/SEQUENCE

From: "Paul Long" <[email-masked]>
Date: Fri, 27 Apr 2001 18:16:40 -0500

I noticed in the ASN.1 that the SET-OF construct is never used--SEQUENCE-OF
is used exclusively for lists. The problem is that in ASN.1, SEQUENCE-OF has
semantics of an _ordered_ list, but it's used interchangably for both
ordered and unordered lists in the Megaco/H.248 ASN.1 syntax tree. For
example,
    transactions SEQUENCE OF Transaction
should really be
    transactions SET OF Transaction
because 8.3/H.248 says that "There is no order implied" for transactions.

Although the ASN.1 is therefore technically wrong, and it would be a tiny
bit clearer if it were corrected, it probably doesn't matter much because
I'm probably the only person bugged by this. :-) Whatever... Oh, I don't
know about BER, but of it's like PER, we could safely correct this because
SET-OF and SEQUENCE-OF are encoding identically--it's only the semantics
that differ.

Paul Long
ipDialog, Inc.

---

From: Troy Cauble <[email-masked]>
Date: Mon, 30 Apr 2001 12:30:26 -0400

> because 8.3/H.248 says that "There is no order implied" for transactions.

Paul's attention to detail reminds me of some stuff that
bugged me when I first read the ANBF spec.

NOTE: This is way off topic.  This thread will not clarify or change 
any H.248 specs.

The H.248 ABNF is full of heterogeneous lists like this:

   localControlDescriptor = LocalControlToken LBRKT localParm
                            *(COMMA localParm) RBRKT
                          
   ; at-most-once per item except for propertyParm
   localParm            = ( streamMode / propertyParm /
   				reservedValueMode / reservedGroupMode ) 

It always bugged me that things other than propertyParms could be
in between propertyParms.  Also, IMHO, the comment carries critical 
specifications because the line above was too loose.  IMHO, if you
need comments like this, your structure is wrong or your specification
language too weak.

Since there is no significance to the order of item TYPES in the list,
that is, no reason to vary the order, I would want to IMPOSE ONE to 
make parsing easier.  (This might be the opposite of Paul's original 
point.)  I'd want something more like this:

   localControlDescriptor = LocalControlToken LBRKT [streamMode] 
				[reservedValueMode] [reservedGroupMode]
				[propertyParm *(COMMA propertyParm)] RBRKT

This version has two problems though.  It has lost the COMMAs between
some items and it allows an empty LCD.  And I can't think of a nice, compact
way to fix these problems.  (The top level of the SDP spec is an ordered
list of optional items, but they use CRLF as a delimiter and it doesn't
look stupid after the last list item.)

So I'm curious.  I don't know if whoever was initially involved with the 
ABNF spec (Brian?, Tom?) are on this list.  But I wonder:

Are heterogeneous lists considered a feature?  Or just a way to get it done
in ABNF?  Did you ever feel that ABNF was forcing you away from the structure
you really wanted?  Do we need an alternative to ABNF?

Just curious.

-troy

---

From: "Paul Long" <[email-masked]>
Date: Mon, 30 Apr 2001 12:03:31 -0500

Troy,

Heterogeneous lists don't bug me, and I believe they are just a natural
result of keyword/value syntaxes. I mean, the keyword identifies the
parameter so there is no need to impose a further constraint regarding
order. Also, depending on how the parser is built, there may not be any
benefit in imposing an order.

BTW, the following fixes the two problems with your solution, but it is
admittedly not "nice, compact." However, it is unambiguous and does not
require annotations to explain the finer points.

localControlDescriptor = LocalControlToken LBRKT
	( streamMode [COMMA reservedValueMode] [COMMA reservedGroupMode] *(COMMA
propertyParm) ) /
	( [streamMode COMMA] reservedValueMode [COMMA reservedGroupMode] *(COMMA
propertyParm) ) /
	( [streamMode COMMA] [reservedValueMode COMMA] reservedGroupMode *(COMMA
propertyParm) ) /
	( [streamMode COMMA] [reservedValueMode COMMA] [reservedGroupMode COMMA]
propertyParm *(COMMA propertyParm) ) RBRKT

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 30, 2001 11:30 AM
To: Paul Long
Cc: [email-masked]
Subject: OFF TOPIC: The way ANBF shapes specs (was ASN.1 SET/SEQUENCE)

Are heterogeneous lists considered a feature?  Or just a way to get it done
in ABNF?  Did you ever feel that ABNF was forcing you away from the
structure
you really wanted?  Do we need an alternative to ABNF?

Just curious.

-troy