Subject: RE: OFF TOPIC: The way ANBF shapes specs (was ASN.1 SET/SEQUENCE)

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 30 Apr 2001 17:37:34 -0400

I'm responsible for a good bit of the ABNF.  
Yes, ABNF cannot do everything you would like it to do without making
  the productions hopelessly complex
Yes, we searched (and experimented with) better ways to represent
 unordered lists without needing things like "at most once" comments.
It was judged that imposing order was not warranted, and we uniformly
implemented the protocol that way.

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 12:30 PM
> To: Paul Long
> Cc: [email-masked]
> Subject: OFF TOPIC: The way ANBF shapes specs (was ASN.1 SET/SEQUENCE)
> 
> 
> Paul Long wrote:
> > 
> > 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.
> 
> 
> 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: "Tulpule, Naren" <[email-masked]>
Date: Mon, 30 Apr 2001 14:56:34 -0700

Hi Brian, Troy, list,
  I'd have thunk (taking Troy's example)
LocalControlDescriptor = LocalControlToken LBRKT [streamMode COMMA]
[reservedValueMode COMMA] [reservedGroupMode COMMA] *(PropertyParm COMMA)
RBRKT
would have been perfectly OK (sort of like C enums where a last comma is
allowed). Tolerant parsers would have ignored absense of the last comma. Yes
this would allow an empty descriptor, but its semantics can always be fixed.
(eg empty SignalsDesc has a meaning but empty LocalControlDesc doesn't do
anything).
Perhaps for v2, if enough people (who matter :-) want to enforce
at-most-once type things in syntax itself. 

These views are mine alone, not those of Intel or Trillium.
-- Naren
Narendra C. Tulpule         310-442-9222
SMTS, Trillium (an Intel company)
12100 Wilshire Bl #1800 Los Angeles CA 90025
It IS as bad as you think, and THEY are out to get you.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, April 30, 2001 2:38 PM
To: 'Troy Cauble'; Paul Long
Cc: [email-masked]
Subject: RE: OFF TOPIC: The way ANBF shapes specs (was ASN.1
SET/SEQUENCE)

Brian