Subject: [Megaco] lookahead overhead for indAudauditReturnParameter

From: "Milton" <[email-masked]>
Date: Wed, 17 Nov 2004 15:57:47 +0530

Hi,

In The Megaco/H.248 Gateway Control Protocol, version 2, in annexure B,
rules for auditItem are as following: 

auditItem   = ( MuxToken / ModemToken / MediaToken /  

                      SignalsToken / EventBufferToken / 

                      DigitMapToken / StatsToken / EventsToken / 

                      ObservedEventsToken / PackagesToken ) / 

                      indAudterminationAudit)

indAudterminationAudit   = indAudauditReturnParameter  

                              *(COMMA indAudauditReturnParameter)  

      indAudauditReturnParameter = (indAudmediaDescriptor / /   

                     indAudeventsDescriptor /  

                     indAudsignalsDescriptor /  

                     indAuddigitMapDescriptor /  

                     indAudeventBufferDescriptor / 

                     indAudstatisticsDescriptor /  

                     indAudpackagesDescriptor)

indAudmediaDescriptor   = MediaToken LBRKT indAudmediaParm RBRKT

.

indAudeventBufferDescriptor= EventBufferToken  

                        LBRKT indAudeventSpec RBRKT

indAudeventsDescriptor     = EventsToken EQUAL RequestID  

                        LBRKT indAudrequestedEvent RBRKT

indAudsignalsDescriptor    = SignalsToken  

                        LBRKT [ indAudsignalParm ] RBRKT  .. Etc.

As we can see indAudterminationAudit ends up with a rule that would start
with one of the tokens - and hence there is a minor ambiguity decoding
auditItem, to illustrate it, both of the following strings would conform to
the rule of auditItem:

.Audit {

                        Events

            }

 And 

  .Audit{

                        Events = 111{al/on}

            }

As we can see we cannot distinguish between the above two texts on the basis
of the 'token' alone. To solve this problem we have to look ahead to check
the character after the tokens - Now ..

1. Looking ahead would reduce the efficiency of the parser somehow and 

2. This would be a slight deviation from normal abnf rules in megaco.

So wouldn't it be better to introduce new tokens for
indAudit<xxx>Descriptors? For example if we rewrite the rule for
inAudeventsDescriptor as:

indAudeventsDescriptor     = AudEventsToken EQUAL RequestID  

                        LBRKT indAudrequestedEvent RBRKT

Where 

AudEventsToken                = ("AuditEvents"                / "AE")

The crux of my argument is : Is not it better to add a set of tokens than to
add to parser's overhead ?

Regards,

Milton

 

 

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 17 Nov 2004 05:46:42 -0500

Megaco is a context-dependent grammar.  The fact that the parser detects the
Events token does not mean that it has fulfilled some portion of the grammar
-- only that it has matched the Events token.  It seems to me that it is
very easy for a parser to tell the difference between the two actually, by
the presence or absence of a '=' following the Events token.
 
Given that there are many places in the ABNF grammar where the parser
actually has to know what the immediately following character is in order to
determine what construct it is in.  This would seem to be just one more
place.
 
Note that syntax changes, such as alteration of tokens is NOT backwards
compatible, and will break many deployed implementations.
 
Kevin

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Milton
Sent: Wednesday, November 17, 2004 5:28 AM
To: [email-masked]
Subject: [Megaco] lookahead overhead for indAudauditReturnParameter

Hi,

                      indAudterminationAudit)

  

                     indAudeventsDescriptor /  

...

                        LBRKT [ indAudsignalParm ] RBRKT  .... Etc.

...Audit {

                        Events

            }

 And 

  ...Audit{

                        Events = 111{al/on}

            }

Where 

 

 

Regards,

Milton