Subject: Re: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF

From: Christian Groves <[email-masked]>
Date: Thu, 07 Aug 2003 15:26:07 +1000

G'Day Micael, all,

Back from holiday and I'm the guy who concocted this syntax. I certainly didn't 
mean to introduce this ambiguity into the ABNF (its why I dislike ABNF) but it 
did slip past everyone else until now.

So as has been mentioned by Tom we need to fix this. So how about we delete 
audititem from? It removes the ambiguity.
auditReturnParameter = (mediaDescriptor / modemDescriptor /
                         muxDescriptor / eventsDescriptor /
                         signalsDescriptor / digitMapDescriptor /
                       observedEventsDescriptor / eventBufferDescriptor /
                         statisticsDescriptor / packagesDescriptor /
                          errorDescriptor / auditItem)

and restore this to v1. The individual auditing mechanism was only meant to 
change the request mechanisn not what was returned as the "usual" audit reply 
should have been enough to send the data back that you need. Does this solve the 
problem. If not, Micael as you need unambiguous syntax can you propose a simple 
ABNF fix that would solve your problem/s?

Regards, Christian

Micael Karlberg wrote:
> So, now we have yet another parse conflict regarding 'EventBufferToken'?
> 
> We three rules:
> 
> 1) auditItem                   -> 'EventBufferToken'
> 2) eventBufferDescriptor       -> 'EventBufferToken' 
>                                   [ LBRKT eventSpec *(COMMA eventSpec) RBRKT ]
> 3) indAudeventBufferDescriptor -> 'EventBufferToken' 
>                                   LBRKT indAudeventSpec RBRKT
> 
> One conflict between rule 1) and 2) and now another conflict
> between rule 2) and 3)
> 
> So, depending on the number of tokens after the 'EventBufferToken', we get:
>  - Zero        -> auditItem
>  - One         -> indAudeventBufferDescriptor
>  - Two or more -> eventBufferDescriptor
> 
> Is this correct?
> 
> Regards,
> 	/BMK
> 
> Anil Jangam writes:
>  > This particular question has been repeated for a number of times so far.
>  > Even I had the same doubt for which Tom has replied as follows: (Marked with
>  > ####>).
>  > I think we need to fix this now.
>  > 
>  > ####> STARTS
>  > ----- Original Message -----
>  > From: Tom-PT Taylor
>  > To: 'Anil Jangam' ; Kevin Boyle
>  > Sent: Wednesday, January 22, 2003 10:40 PM
>  > Subject: RE: [Megaco] auditReturnParameter in AmmsReply
>  > 
>  > 
>  > I suppose as the guy who concocted this syntax I should answer the question.
>  > You return the auditItem.  That was my shortcut for returning descriptor
>  > name only.
>  > 
>  > Apparently there is a parsing problem with this syntax, but we never seem to
>  > have taken the step of resolving it.
>  > ####> ENDS
>  > 
>  > ----- Original Message -----
>  > From: "Micael Karlberg" <[email-masked]>
>  > To: <[email-masked]>
>  > Sent: Thursday, July 17, 2003 3:16 PM
>  > Subject: [Megaco] Ambiguous definition of auditReturnParameter in v2 ABNF
>  > 
>  > 
>  > > Hi,
>  > >
>  > > The 'auditReturnParameter' appears to be ambiguously defined in version 2
>  > > of the ABNF.
>  > >
>  > > An example. If the 'auditReturnParameter' contains the following
>  > > sequence of tokens:
>  > >
>  > >    "EB { hobbes }"
>  > >
>  > > i.e.
>  > >
>  > >     EventBufferToken LBRKT pkgdName RBRKT
>  > >
>  > > then it may be an 'auditItem' (see 'indAudeventBufferDescriptor') or an
>  > > 'eventBufferDescriptor'
>  > >
>  > > What is the intention here? Should this sequence of tokens be
>  > > interpreted as an 'auditItem' or an 'eventBufferDescriptor?
>  > >
>  > > As a parser implementor I need a well defined, unambiguous grammar to
>  > > rely on.
>  > >
>  > > The grammar looks like this (a little bit simplified):
>  > >
>  > >   auditReturnParameter        = eventBufferDescriptor / auditItem
>  > >
>  > >   eventBufferDescriptor       = EventBufferToken
>  > >                                 [ LBRKT eventSpec *(COMMA eventSpec)
>  > RBRKT]
>  > >
>  > >   eventSpec                   = pkgdName
>  > >                                 [ LBRKT eventSpecParameter
>  > >                                         *(COMMA eventSpecParameter) RBRKT]
>  > >
>  > >   auditItem                   = indAudterminationAudit
>  > >
>  > >   indAudterminationAudit      = indAudauditReturnParameter
>  > >                                 *(COMMA insAudauditReturnParameter)
>  > >
>  > >   indAudauditReturnParameter  = indAudeventBufferDescriptor
>  > >
>  > >   indAudeventBufferDescriptor = EventBufferToken LBRKT indAudeventSpec
>  > RBRKT
>  > >
>  > >   indAudeventSpec             = pkgdName
>  > >                                 [ LBRKT indAudeventSpecParameter RBRKT ]
>  > >
>  > >
>  > > Regards,
>  > > /BMK
>  > >
>  > > _______________________________________________
>  > > Megaco mailing list
>  > > [email-masked]
>  > > https://www1.ietf.org/mailman/listinfo/megaco
>  > >
> 

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 07 Aug 2003 15:26:07 +1000

G'Day Micael, all,

Regards, Christian

---

From: Micael Karlberg <[email-masked]>
Date: Thu, 7 Aug 2003 11:31:58 +0200

Hi,

Christian Groves writes:
 > G'Day Micael, all,
 > 
 > Back from holiday and I'm the guy who concocted this syntax. I certainly 
 > didn't mean to introduce this ambiguity into the ABNF (its why I dislike 
 > ABNF) but it did slip past everyone else until now.

I really which there was some tool to check ABNF easilly, then 
these kind of problems would occure with much less frequency. 
For ASN.1 you just feed it to your ASN.1 compiler and your done.
Same goes for MIBs.

 > and restore this to v1. 

Delete auditItem from auditReturnParameter? But auditItem was part of 
auditReturnParameter even in v1. 

 > The individual auditing mechanism was only meant to change the request 
 > mechanisn not what was returned as the "usual" audit reply 
 > should have been enough to send the data back that you need. Does this 
 > solve the problem. If not, Micael as you need unambiguous syntax can you 
 > propose a simple ABNF fix that would solve your problem/s?

I really hope that I am not the only one who is writing a version 2
parser, or else I am wasting my time (or are about to strike gold :)

As for a solution, how about adding a token and changing the 
definition of indAudterminationAudit to:

indAudterminationAudit = IndAudTerminationAuditToken 
                         indAudauditReturnParameter  
                         *(COMMA indAudauditReturnParameter)  
       
Not pretty, but it should do the trick. I have not tested it
with real messages, but atleast my parser generator did not 
complain anymore.

Regards,
	/BMK

 > > We have three rules:

---

From: Micael Karlberg <[email-masked]>
Date: Thu, 7 Aug 2003 11:31:58 +0200

Hi,

       

Regards,
	/BMK

---

From: Troy Cauble <[email-masked]>
Date: Thu, 07 Aug 2003 10:25:17 -0400

Is there something here that isn't already handled by
6.3 in the IG?

http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf

-troy

Christian Groves wrote:
> So as has been mentioned by Tom we need to fix this. So how about we 
> delete audititem from? It removes the ambiguity.
> and restore this to v1. The individual auditing mechanism was only meant 
> to change the request mechanisn not what was returned as the "usual" 
> audit reply should have been enough to send the data back that you need. 
> Does this solve the problem. If not, Micael as you need unambiguous 
> syntax can you propose a simple ABNF fix that would solve your problem/s?
> 
> Regards, Christian
> 
> 
> Micael Karlberg wrote:
> 
>> RBRKT ]

---

From: Troy Cauble <[email-masked]>
Date: Thu, 07 Aug 2003 10:25:17 -0400

-troy

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Aug 2003 15:06:24 +1000

G'Day Micael,

Please see comments below.

Regards, Christian

> For ASN.1 you just feed it to your ASN.1 compiler and your done.

[CHG] Won't hear any complaints from me :).

> auditReturnParameter even in v1. 

[CHG] Yes, must have been looking at an old version of v1.

> with real messages, but atleast my parser generator did not 

[CHG] I think the point is that the MGC shouldn't be concerned whether the 
audited parameter is from a descriptor audit or an individual audit. The syntax 
provided for a descriptor audit is enough to return an individual audit. The 
problem lies that AuditItem is used both in the command request and reply ABNF. 
I was thinking about a token yesterday myself but when I had a look at the ASN1 
and saw that it used existing AuditDescriptor reply syntax I thought we 
shouldn't allow using the IndAudRep.
Would a rule that,

; For audit replys the indAudterminationAudit SHALL not be used.
auditItem            = ( MuxToken / ModemToken / MediaToken /
                         SignalsToken / EventBufferToken /
                         DigitMapToken / StatsToken / EventsToken /
                         ObservedEventsToken / PackagesToken ) /
                         indAudterminationAudit)

Be a solution?

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Aug 2003 15:06:24 +1000

G'Day Micael,

Regards, Christian

Be a solution?

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Aug 2003 14:23:58 +1000

Hello Troy,

I don't think so. As this problem occurs when the returned properties are not 
empty. If I understand the problem correctly the issues is how does a decoder 
know that the returned audited parameters belong to a descriptor audit or to an 
individual audit.

Regards, Christian

Troy Cauble wrote:
>> Back from holiday and I'm the guy who concocted this syntax. I 
>> certainly didn't mean to introduce this ambiguity into the ABNF (its 
>> why I dislike ABNF) but it did slip past everyone else until now.
>>
>> and restore this to v1. The individual auditing mechanism was only 
>> meant to change the request mechanisn not what was returned as the 
>> "usual" audit reply should have been enough to send the data back that 
>> you need. Does this solve the problem. If not, Micael as you need 
>> unambiguous syntax can you propose a simple ABNF fix that would solve 
>> your problem/s?
>>
>> Regards, Christian
>>
>>
>> Micael Karlberg wrote:
>>

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Aug 2003 14:23:58 +1000

Hello Troy,

Regards, Christian

---

From: Troy Cauble <[email-masked]>
Date: Fri, 08 Aug 2003 10:51:15 -0400

Christian Groves wrote:

>>
>>  >  > So as has been mentioned by Tom we need to fix this. So how 
>> about we delete  > audititem from? It removes the ambiguity.
>>  > The individual auditing mechanism was only meant to change the 
>> request  > mechanisn not what was returned as the "usual" audit reply 
>>  > should have been enough to send the data back that you need. Does 
>> this  > solve the problem. If not, Micael as you need unambiguous 
>> syntax can you  > propose a simple ABNF fix that would solve your 
>> problem/s?
>>
>>
>> with real messages, but atleast my parser generator did not complain 
>> anymore.
> 
> 
> [CHG] I think the point is that the MGC shouldn't be concerned whether 
> the audited parameter is from a descriptor audit or an individual audit. 
> The syntax provided for a descriptor audit is enough to return an 
> individual audit. The problem lies that AuditItem is used both in the 
> command request and reply ABNF. I was thinking about a token yesterday 
> myself but when I had a look at the ASN1 and saw that it used existing 
> AuditDescriptor reply syntax I thought we shouldn't allow using the 
> IndAudRep.
> Would a rule that,
> 

IG item 6.3 fixed the related conflicts for V1.  It's not clear if being
in the IG means it applies to V2 as well.

I think 6.3 should be explicitly applied to V2 because
1) it makes the two versions more alike, and
2) it fixes the conflicts.

IG item #6.3 (http://www.itu.int/itudoc/itu-t/com16/implgd/h248s-ig.pdf)

   auditReturnParameter = (mediaDescriptor / modemDescriptor /
			muxDescriptor / eventsDescriptor /
			signalsDescriptor / digitMapDescriptor /
			observedEventsDescriptor /
			eventBufferDescriptor /
			statisticsDescriptor / packagesDescriptor /
			errorDescriptor / auditReturnItem)

   auditReturnItem = (MuxToken / ModemToken / MediaToken /
			DigitMapToken / StatsToken /
			ObservedEventsToken / PackagesToken )

   ;at-most-once, and DigitMapToken and PackagesToken are not allowed
   ;in AuditCapabilities command
   auditItem = ( auditReturnItem / SignalsToken /
			EventBufferToken / EventsToken )

Note that indAudterminationAudit was not in V1.  It must be added to
auditItem.  I think Christian is arguing that those resulting token
conflicts are not critical, because the indAud variations are always
followed by "{" or "=", which can distinguish them from the individual
tokens of an auditItem.  So no other changes are necessary.

-troy

---

From: Troy Cauble <[email-masked]>
Date: Fri, 08 Aug 2003 10:51:15 -0400

-troy

---

From: Micael Karlberg <[email-masked]>
Date: Fri, 8 Aug 2003 18:54:47 +0200

Hi,

Regards,

	/BMK

 > Please see comments below.

<--- snip --->

 > audited parameter is from a descriptor audit or an individual audit. 
 > The syntax provided for a descriptor audit is enough to return an individual
 > audit. The problem lies that AuditItem is used both in the command request 
 > and reply ABNF. 
 > I was thinking about a token yesterday myself but when I had a look at the 
 > ASN1 and saw that it used existing AuditDescriptor reply syntax I thought 
 > we shouldn't allow using the IndAudRep.
 > Would a rule that,
 > 

[BMK] That clears up the intention but I don't think it will make
the ABNF less ambiguous for a parser generator (e.g. bison). 

Regards,
	/BMK

-- 
Micael Karlberg          Ericsson AB, Älvsjö Sweden
Tel:  +46 8 727 5668     EAB/UHK/KD - OTP Product Development
ECN:  851 5668           Mail: [email-masked]
Fax:  +46 8 727 5775

---

From: Micael Karlberg <[email-masked]>
Date: Fri, 8 Aug 2003 18:54:47 +0200

Hi,

Regards,

	/BMK

<--- snip --->

Regards,
	/BMK

---

From: Micael Karlberg <[email-masked]>
Date: Fri, 8 Aug 2003 21:16:38 +0200

Hi,

I made the changes described by Troy:

    auditReturnParameter = ( mediaDescriptor / modemDescriptor /
 
    auditReturnItem = ( MuxToken / ModemToken / MediaToken /
                        DigitMapToken / StatsToken /
                        ObservedEventsToken / PackagesToken )

    auditItem = ( auditReturnItem / SignalsToken /
                  EventBufferToken / EventsToken /
                  indAudterminationAudit )

This seems to work just fine, and since it is the way it's done
in the IG (h248s-ig) why not use this construction in version 2?

By the way. I have been using the draft-ietf-megaco-3015corr-03.txt
document assuming it to be up-to-date with the latest IG. It was only 
when Troy pointed out the auditReturnItem that I realized that something
was not right. h248s-ig.pdf is dated 25 October 2002 and 
draft-ietf-megaco-3015corr-03.txt is dated December 2002 (i.e. later). 
Is there a later version of the draft-ietf-megaco-3015corr document
or is it dead (it did expire June 2003)?

Regards,
	/BMK

---

From: Tom Taylor <[email-masked]>
Date: Fri, 08 Aug 2003 15:33:28 -0400

You should now be using RFC 3525 as the equivalent to H.248.1 version 1.

---

From: Micael Karlberg <[email-masked]>
Date: Fri, 8 Aug 2003 21:16:38 +0200

Hi,

 

Regards,
	/BMK

---

From: Tom Taylor <[email-masked]>
Date: Fri, 08 Aug 2003 15:33:28 -0400

---

From: Tom Taylor <[email-masked]>
Date: Fri, 08 Aug 2003 15:36:22 -0400

It just occurred to me: you won't see any improvement.  RFC 3525 only provides the 
state as of February 2002.

> You should now be using RFC 3525 as the equivalent to H.248.1 version 1.
[snip]

---

From: Tom Taylor <[email-masked]>
Date: Fri, 08 Aug 2003 15:36:22 -0400

[snip]

---

From: Christian Groves <[email-masked]>
Date: Mon, 11 Aug 2003 11:54:00 +1000

Hello Troy and Micael,

I agree with Troy 6.3 the syntax does fix the problem in both empty and 
non-empty cases. We want to change the heading to make this clear.

The other problem which has be highlighted now by several people to me is the 
fact the IG seems to be for H.248.1v1 only. This is NOT the case. It is for both 
V1 and V2. If a change is for V1 or V2 only then this is mentioned (see 6.9 & 
6.10). I've already prepared a contribution for the September SG16 meeting to 
clear this confusion up.

The IETF draft/RFC do not contain any IG additions nor do the published ITU 
documents.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 11 Aug 2003 11:54:00 +1000

Hello Troy and Micael,

Regards, Christian