Subject: [Megaco] RE: Ambiguity in MEGACO textual grammar ?

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 13 Oct 2004 13:19:38 -0400

After having another look through the grammar and the text of the spec, I
see that the contextTerminationAudit construct would produce something like
this:

!/1 [12.34.56.78]:2944 P=123{C=1{AV=C{term1,term2,term3}}}

I don't see the great advantage of that over, say:

!/1 [12.34.56.78]:2944 P=123{C=1{AV=term1,AV=term2,AV=term3}}

Further, the latter is better aligned with the rest of the protocol
construction.

I could find no reference to this particular construct anywhere but in the
grammar.  I do not have any particular recollection of why this would have
been built this way.  Does anyone remember that far back to know why this
was designed in this fashion?

Kevin

-----Original Message-----
From: Angelo Contardi [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2004 12:51 PM
To: Megaco - IETF 
Subject: Ambiguity in MEGACO textual grammar ?

Hello Megaco - IETF Team,

during my study about MEGACO V2 Textual syntax (Annex B) i have probably
discover TWO (similar) ambiguties in "auditReply" productions. In fact,

auditReply = (AuditValueToken / AuditCapToken ) ( contextTerminationAudit  /
auditOther)

and may be "rewritten" as:

auditReply =  AuditValueToken  contextTerminationAudit /    (1)
              AuditValueToken  auditOther              /    (2)
              AuditCapToken    contextTerminationAudit /    (3) 
              AuditCapToken    auditOther                   (4)
                                                                    
Let me consider the First two productions (1) and (2) (but what i will say
is valid for the last couple too, (3) and (4)).

auditOther              = EQUAL TerminationID [LBRKT terminationAudit RBRKT]
contextTerminationAudit = EQUAL CtxToken LBRKT errorDescriptor RBRKT / ...
terminationAudit        = auditReturnParameter *(COMMA auditReturnParameter)
auditReturnParameter    = ... / ... / errorDescriptor

So, production   (1) may genarate a "string" (sentencial form) of this kind:

		AuditValueToken EQUAL CtxToken      LBRKT errorDescriptor
RBRKT

While production (2) may generate a "string" (sentencial form) of this kind:

        AuditValueToken EQUAL TerminationID LBRKT errorDescriptor RBRKT

Well, if i choose a TerminationID in pathNAME form, that simulate the
CtxToken value, "c" or "context", the two production are the same and it's
not possible to distinguish between them.
Changing AuditValueToken with AuditCapToken, demostrate that production
(3) and (4) may generate the same sequence (are ambiguous, in some cases).

I know NOBODY probably choose TerminationID value = CtxToken value, but
theorically this choice is allowed.

Best regards

Angelo Contardi
[email-masked]
2004-10-13

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 14 Oct 2004 11:54:34 +1000

Hello Kevin and Angelo,

contextTerminationAudit was/is a short form to be able to get back a compact 
list of termination IDs. This is mentioned in H.248.1v1: "Annexes A and B 
provide a special syntax for presenting such a list in condensed form, such that 
the AuditValue command tag does not have to be repeated for each TerminationID."

Regards, Christian