Subject: [Megaco] Descriptor grammar issue

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 May 2002 15:11:35 +0300

Hi,

I have an issues related to the text grammar (to my understanding it's
not an issue for ASN.1 encoding):

Assume I want to remove a stream.

According to chapter 7.1.6 I shall send:

So, according to 7.1.6 I should send:

    MODIFY = myRTPTerm {
        Media {
            Stream = 1 {
                LocalControl {
                       ReserveValue = OFF
                       ReserveGroup = OFF
                }
            }
        }
    }

Now, since the default values for ReserveValue and ReserveGroup are
"OFF", I don't have to send them. So, I could send:

   MODIFY = myRTPTerm {
        Media {
            Stream = 1 {
                LocalControl {
                }
            }
        }
    }

However, this is against the grammar, which says that the LocalControl
descriptor MUST contain at least ONE localParm:

        localControlDescriptor = LocalControlToken LBRKT localParm
*(COMMA localParm) RBRKT

        localParm = ( streamMode / propertyParm / reservedValueMode /
reservedGroupMode )

So, now I would have to include the ReserveXxx propertied just to make
the receiving parser happy.

To fix this, the grammar should be:

        localControlDescriptor = LocalControlToken LBRKT *(COMMA
localParm) RBRKT

Of  course, I could leave the LocalControl descriptor, and send:

    MODIFY = myRTPTerm {
        Media {
            Stream = 1 {
                }
            }
        }
    }

However, this would also be against the H.248 grammar, which says that
the Stream descriptor MUST at least contain one streamParm (Local-,
Remote- or LocalControl descriptor):

    streamDescriptor  =  StreamToken EQUAL StreamID LBRKT streamParm
*(COMMA streamParm) RBRKT

    streamParm = ( localDescriptor / remoteDescriptor /
localControlDescriptor )

To fix this, the grammar should be:

    streamDescriptor  =  StreamToken EQUAL StreamID LBRKT *(COMMA
streamParm) RBRKT

Comments?

Regards,

Christer Holmberg
Ericsson Finland

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

---

From: "David Stonehouse" <[email-masked]>
Date: Thu, 30 May 2002 08:38:42 -0400

Could you not get around this by including Mode=inactive as a parameter in
LocalControl?  

Dave
Nortel Networks

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, May 30, 2002 8:12 AM
> To: [email-masked]
> Subject: [Megaco] Descriptor grammar issue
> 
> 
> 
> Hi,
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 30 May 2002 12:40:00 -0400

The original discussion went astray on the question of what requestID to use
for an empty Events descriptor.  It seems to me that this is not terribly
important, since such a descriptor will generate no notifications, so we
could simply say that the requestID SHOULD be 1 but MUST be ignored by the
MG.

It is indeed time we cleaned this up.  Proposal: 
 (a) ensure that empty descriptors can be presented in all cases where this
is appropriate;
 (b) an empty descriptor in all cases is represented using empty braces e.g.
Events=1{}.

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Thursday, May 30, 2002 11:04 AM
To: Christer Holmberg; [email-masked]
Subject: Re: [Megaco] Descriptor grammar issue

Hi,

         Or (for consistency) it could follow digitMapDescriptor (and 
eventsDescriptor) approach.
That is do not include {} at all:

streamDescriptor = StreamToken EQUAL StreamID [ LBRKT streamParm *(COMMA 
streamParm) RBRKT ]

Which will result in:

MODIFY = myRTPTerm {
     Media {
         Stream = 1
         }
     }
}

BTW I'm not sure if  "Events could be an empty eventsDescriptor OR an 
auditItem" problem
was ever followed through. If not, than it might be a good time to do it as 
was suggested before
by Troy Cauble to make it right.

Thanks
         Aleks

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 30 May 2002 12:40:00 -0400

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Thursday, May 30, 2002 11:04 AM
To: Christer Holmberg; [email-masked]
Subject: Re: [Megaco] Descriptor grammar issue

Hi,

Which will result in:

MODIFY = myRTPTerm {
     Media {
         Stream = 1
         }
     }
}

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 30 May 2002 13:08:54 -0400

Hi,

         I believe Troy's idea expressed in his original mail I have attached
at the end of this mail is the cleanest one (I marked relevant piece red).
That is to modify ABNF to remove ambiguity, here is an excerpt:

>PROPOSED CHANGES that fix #1, #2 (text) and #4 below
>
>    signalsDescriptor    = SignalsToken [ LBRKT signalParm
>                           *(COMMA signalParm) RBRKT ]
>
>    auditReturnParameter = (mediaDescriptor / modemDescriptor /
>                            muxDescriptor / eventsDescriptor /
>                            signalsDescriptor / digitMapDescriptor /
>                      observedEventsDescriptor / eventBufferDescriptor /
>                            statisticsDescriptor / packagesDescriptor /
>                             errorDescriptor / auditReturnItem )
>
>    auditReturnItem      = ( MuxToken / ModemToken / MediaToken /
>                            DigitMapToken / StatsToken /
>                            ObservedEventsToken / PackagesToken )
>
>    auditItem            = ( auditReturnItem / SignalsToken /
>                            EventBufferToken / EventsToken )

Thanks
         Aleks

At 12:40 PM 5/30/2002, Tom-PT Taylor wrote:

>The original discussion went astray on the question of what requestID to 
>use for an empty Events descriptor.  It seems to me that this is not 
>terribly important, since such a descriptor will generate no 
>notifications, so we could simply say that the requestID SHOULD be 1 but 
>MUST be ignored by the MG.
>
>  (a) ensure that empty descriptors can be presented in all cases where 
> this is appropriate;
>  (b) an empty descriptor in all cases is represented using empty braces 
> e.g. Events=1{}.
>
>From: Aleksandr Ryabin 
>[<mailto:[email-masked]>mailto:[email-masked]]
> ><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mail 
> man/listinfo/megaco
>
><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>

Original thread:
>Cc: [email-masked]
>Date: Thu, 11 Apr 2002 15:19:37 -0400
>From: Troy Cauble <[email-masked]>
>To: Terry L Anderson <[email-masked]>
>Subject: Re: [Megaco] FW: Disabling all Events
>
>Terry L Anderson wrote:
> >
> > This was discussed and the syntax was changed through the implementors 
> guide to
> > this form rather than an empty {}.  The issue was avoiding the need for a
> > RequestID when no real event is being specified.  The alternative would 
> have
> > been
> >     Events = 1234 {}
> > But since there would be no event to tigger a notify it seems pointless to
> > allocate the id.  Allowing
> >     Event {}
> > with no '=' would be too much of a deviation in form
>
>
>Terry,
>
>This reminds me...
>Last June I pointed out that the change to which you are
>referring (IG 6.79) broke the ABNF in a fairly serious way.
>
>Here's an example.  The EventsToken below could be
>one of two things.
>
>MEGACO/1 [135.114.123.123]:1234
>Reply = 5000 {
>   Context = 1 {
>     Add = t1 {
>       Events    ; this could be an empty eventsDescriptor
>                 ; OR an auditItem
>     }
>   }
>}
>
>
>Last October, at your suggestion, I tried to revive the
>thread, but no one responded.  Below I am attaching the
>last post on the subject.
>
>-troy
>Message-ID: <[email-masked]>
>Date: Tue, 09 Oct 2001 12:40:27 -0400
>From: Troy Cauble <[email-masked]>
>Reply-To: Troy Cauble <[email-masked]>
>X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
>X-Accept-Language: en
>MIME-Version: 1.0
>To: "Rosen, Brian" <[email-masked]>,
>         Tom-PT Taylor <[email-masked]>,
>         "[email-masked]'" <[email-masked]>, MEGACO list <[email-masked]>
>Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF
>References: 
><[email-masked]> 
><[email-masked]>
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>
>Greetings,
>
>This old thread had some fairly serious problems that were never
>resolved.  I am proposing changes for the problems in the text
>encoding.  There is a larger issue to the ASN.1 problems -- I
>will start another thread for that.
>
>
>BACKGROUND
>
>I'm told that auditItem's use in auditReturnParameter is to
>represent empty descriptors.
>
>    auditReturnParameter = (mediaDescriptor / modemDescriptor /
>                            muxDescriptor / eventsDescriptor /
>                            signalsDescriptor / digitMapDescriptor /
>                      observedEventsDescriptor / eventBufferDescriptor /
>                            statisticsDescriptor / packagesDescriptor /
>                             errorDescriptor / auditItem )
>
>    auditItem            = ( MuxToken / ModemToken / MediaToken /
>                            SignalsToken / EventBufferToken /
>                            DigitMapToken / StatsToken / EventsToken /
>                            ObservedEventsToken / PackagesToken )
>
>But some of the descriptors in auditReturnParameter already have
>empty forms.  This is the crux of problems #1, #2 (text) and #4 below.
>
>
>PROPOSED CHANGES that fix #1, #2 (text) and #4 below
>
>    signalsDescriptor    = SignalsToken [ LBRKT signalParm
>                           *(COMMA signalParm) RBRKT ]
>
>    auditReturnParameter = (mediaDescriptor / modemDescriptor /
>                            muxDescriptor / eventsDescriptor /
>                            signalsDescriptor / digitMapDescriptor /
>                      observedEventsDescriptor / eventBufferDescriptor /
>                            statisticsDescriptor / packagesDescriptor /
>                             errorDescriptor / auditReturnItem )
>
>    auditReturnItem      = ( MuxToken / ModemToken / MediaToken /
>                            DigitMapToken / StatsToken /
>                            ObservedEventsToken / PackagesToken )
>
>    auditItem            = ( auditReturnItem / SignalsToken /
>                            EventBufferToken / EventsToken )
>
>
>An alternative approach would be to create empty forms for
>the other 7 descriptors represented by auditItem and remove
>the auditItem from auditReturnParameter.  But then those
>empty forms could be used elsewhere (ammParameter, notifyRequest)
>where they're apparantly not needed.
>
>-troy
>
>
>
>Troy Cauble wrote:
> >
> > A summary of the problems discussed in this thread.
> >
> > 1) In the text encoding, some empty descriptors have the form
> >    "Signals {}" while others have "Events".
> >
> > In a Termination Audit:
> >
> > 2) There are two line encodings for an empty Signals descriptor
> >    (text and ASN.1).
> >
> > 3) There are two line encodings each for an empty Events descriptor
> >    or Event Buffer descriptor (ASN.1 only).
> >
> > 4) In the text encoding, EventsToken and EventBufferToken each
> >    have reduce/reduce conflicts because they can represent either
> >    an auditItem token or an empty descriptor in the auditReturnParameter.
> >
> > -troy
> >
> >
> >
> > "Rosen, Brian" wrote:
> > >
> > > I agree with Tom; we did a pass over the ABNF to try to make
> > > all of the empty forms not have braces.  The choice was
> > > completely arbitrary, and as I recall, we decided since it
> > > didn't make any real difference, shorter was better.
> > > If we missed one, we goofed.
> > >
> > > Tom, the problem here seems to be real.  As Troy says, you will get
> > > a reduce conflict in a rules-based parser with this ambiguity.
> > > I'm pretty sure you can ignore the problem, but it's poor design
> > > practice.  You will recall all of the effort Abdallah and Nancy
> > > went through to test out these kinds of things as we developed
> > > the ABNF.  The IG change wasn't verified in the same way, thus
> > > we have this problem.  We need to decide what to do.
> > >
> > > Brian
> > >
> > > > > Tom-PT Taylor wrote:
> > > > >
> > > > > I'm the one responsible for all this.  I suppose I should
> > > > dig up the thread.
> > > > > Anyway, the intention was definitiely to provide a way of
> > > > signalling empty
> > > > > descriptors.  I think we chose rather arbitrarily between
> > > > the desc{} and desc
> > > > > form, opting for the latter.
> > > >

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 30 May 2002 13:08:54 -0400

Hi,

Thanks
         Aleks