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

From: Padmaja Musti <[email-masked]>
Date: Fri, 12 Oct 2001 11:33:48 +0530

Christian,
If implementation issues are concerned mostly MGCs/MGs are 
architectured in three layers

            Application

            Stack

   ABNF Parser      ASN Parser

If the syntax does not provide the tight rules, some body 
either Stack / Application needs to take care of this. 
So I think it is better to make the syntax as specific
as possible.

regards,
Padma

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Friday, October 12, 2001 1:49 AM
To: Christian Groves
Cc: MEGACO list; Linda Woo
Subject: Re: [Megaco] "SEQUENCE OF" for lists of 1 or more

Christian Groves wrote:
> 
> 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. 

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
> 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.

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)

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

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 12 Oct 2001 16:16:33 +1000

I'm confused, doesn't the stack already provide the rules?
Christian