Subject: [Megaco] "SEQUENCE OF" for lists of 1 or more

From: Troy Cauble <[email-masked]>
Date: Tue, 09 Oct 2001 18:53:51 -0400

Greetings,

The ABNF spec frequently uses the following forms
(usually with LBRKT and RBRKT).

        x *(COMMA x)            ; list of 1 or more.
        [ x *(COMMA x) ]        ; list of 0 or more.

The corresponding ASN.1 specs are uniformly written

        SEQUENCE OF x

This is a list of 0 or more.

A more precise form for a list of 1 or more would be

        SEQUENCE (SIZE (1..MAX)) OF x
        -- MAX is an implementation defined maximum

or possibly

        SEQUENCE (SIZE (ALL EXCEPT 0)) OF x

The former is in common use.  I've never seen the latter
used, but I have a book that says it's valid :)

"SEQUENCE OF" is used 33 times in the current ASN.1 spec.
I think it is important to correct the usage for lists
that should not be 0 length.

For example, the following says you can have a message with
no Transactions and no ErrorDescriptor.  Judging from the
ABNF, this is not as desired.

   Message ::= SEQUENCE
   {    version         INTEGER(0..99),
        -- The version of the protocol defined here is equal to 1.
        mId             MId,    -- Name/address of message originator
        messageBody             CHOICE
        {
                messageError    ErrorDescriptor,
                transactions    SEQUENCE OF Transaction
        },
        ...
   }

Comparing the ASN.1 to the ABNF, I estimate that 16 of the 33
uses of "SEQUENCE OF" should be "SEQUENCE (SIZE (1..MAX)) OF".

If there is a consensus on the approach, I will document the
changes.

-troy

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Wed, 10 Oct 2001 11:17:19 +1000

What extra does this give us? If the current specification is not
erroneous, O or more allows 1 or more also, why make the update?

Cheers, Christian

---

From: Troy Cauble <[email-masked]>
Date: Wed, 10 Oct 2001 10:31:21 -0400

As I said, the current form allows many things that
shouldn't be allowed.  

Consider the example below.  Reading the ASN.1 without
knowledge of the ABNF would lead one to believe it's
valid to send a message with NO transactions and NO
ErrorDescriptor (by using CHOICE transactions, and a
0 length SEQUENCE OF).

This is just one example of many.

I think it should be "tight".  Saying "0 or more allows 1 or more"
and that's close enough is like replacing Annex B with
"Just use some ASN.1, it should be obvious from the text."

-troy

---

From: Christian Groves <[email-masked]>
Date: Thu, 11 Oct 2001 10:47:40 +1000

G'Day Troy,

I do agree that tight syntax is good but the specification must read in
a complete manner. The syntax won't give you all the rules. The
procedures contained in the document is the real protocol and its these
procedures which dictate how the syntax works ie. sect 8, "Transactions
consist of one or more Actions."

Can you send a list of the changes, that you propose? I would agree we
would need to change if they are not covered by any procedural text.

Cheers, Christian

---

From: Troy Cauble <[email-masked]>
Date: Thu, 11 Oct 2001 16:18:45 -0400

Christian Groves wrote:
> a complete manner. The syntax won't give you all the rules. 

Christian,

I agree.  But this is no excuse to not be as tight as possible
using the given syntax.

Please answer this:
Would you be satisfied with the ABNF if all of the uses of
"x *(COMMA x)" were written "[ x *(COMMA x) ]" and you had
to read the spec to understand which lists could really be
empty?

Unfortunately there are many other places where the ASN.1
spec is unnecessarily loose.  I'm not going to propose
changes for them, the changes would be too large.

I think that the changes I am proposing, while numerous,
should be virtually no impact to implementations.  They 
just clarify the document.

> The

Below is a breakdown.  For the most part I generated this from 
comparisons to the ABNF, not the text.  The ABNF is fundamentally
tighter than the ASN.1.

-troy

For the following structure/element pairs a list of size zero
does NOT make sense (and is not allowed in the analogous ABNF).  
"SEQUENCE OF" should be changed to "SEQUENCE (SIZE (1..MAX)) OF"
for these.

        Message                         transactions
        TransactionRequest              actions
        TransactionReply                actionReplies
        TransactionResponseAck          (whole)
        ActionRequest                   commandRequests
        ActionReply                     commandReply
        ObservedEventsDescriptor        observedEventLst
        MediaDescriptor                 multiStream
        LocalRemoteDescriptor           propGrps
        PropertyGroup                   (whole)
        MuxDescriptor                   termList
        SecondEventsDescriptor          eventList
        SignalsDescriptor               (whole)
        SeqSigList                      signalList
        ModemType                       mtl

For the following structure/element pairs a list of size zero
DOES make sense.  They should not be changed.

        AmmRequest                      descriptors
        LocalControlDescriptor          propertyParms
        ObservedEvent                   eventParList
        TerminationStateDescriptor      propertyParms
        RequestedEvent                  evParList
        SecondRequestedEvent            evParList
        EventSpec                       eventParList
        Signal                          sigParList
        ModemType                       mpl
        TerminationID                   wildcard
        TerminationIdList		(whole)
                (For the signle, non-special case contextAuditResult.  
		 Why does the ASN.1 use TerminationIDList everywhere
                 when the ABNF does not?)

Given the pattern established above of using an empty list to signify
a non existant list, we should remove the "OPTIONAL" tag associated
with these.

        ContextRequest                  topologyReq
        AmmsReply                       terminationAudit

Catagorizing these depends on the solution to a conflict in
AuditReturnParameter.  For each of these, the empty list form
could be useful ONLY as an empty descriptor in AuditReturnParameter.
but AuditReturnParameter/emptyDescriptors exists for that.

The ABNF equivalent of this problem is currently being discussed
in another thread.

        PackagesDescriptor              (whole)
        StatisticsDescriptor            (whole)
        EventsDescriptor                eventList
        EventBufferDescriptor           (whole)
        SignalsDescriptor               (whole)

I'm not sure.  This one hurts my brain.

        Value                           (whole)

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Oct 2001 15:29:37 +1000

G'Day Troy,

Well I don't feel too strongly about the issue so if the consensus is to
change OK. I've made comments to the individual changes below.

Cheers, Christian

> "SEQUENCE OF" should be changed to "SEQUENCE (SIZE (1..MAX)) OF"
[CHG] OK
>         TransactionRequest              actions
[CHG] OK
>         TransactionReply                actionReplies
[CHG] OK
>         TransactionResponseAck          (whole)
[CHG] OK
>         ActionRequest                   commandRequests
[CHG] I disagree an actionRequest doesn't need to have a command.
>         ActionReply                     commandReply
[CHG] See above comment
>         ObservedEventsDescriptor        observedEventLst
[CHG] I don't think the ObservedEventLst need to be in the
ObservedEventsDescriptor, in case the NotifyRequest sends an
errorDescriptor, although this is also the case in ANBF spec.
>         MediaDescriptor                 multiStream
[CHG] OK
>         LocalRemoteDescriptor           propGrps
[CHG] Disagree - can't you have an empty descriptor?
>         PropertyGroup                   (whole)
[CHG] Disagree - can't you have multiple groups? one of which is empty?
>         MuxDescriptor                   termList
[CHG] Diagree - you could just have one controlling termination and thus
the list would be empty.
>         SecondEventsDescriptor          eventList
[CHG] OK
>         SignalsDescriptor               (whole)
[CHG] Can't we have an empty signal descriptor?
>         SeqSigList                      signalList
[CHG] Disagree - this isn't a "sequence of" Do you mean "signalList
SEQUENCE OF Signal"? Can't we empty a signal list?
>         ModemType                       mtl
[CHG] OK.

>         AmmsReply                       terminationAudit
[CHG] I'd prefer to leave the OPTIONAL tag.

>         SignalsDescriptor               (whole)
[CHG] I'm not sure I understand the problem for the last 3 descriptors
above. These can be also sent down to the MG.

> I'm not sure.  This one hurts my brain.
[CHG] Shouldn't this remain? ie. empty = choose