Subject: Re: [Megaco] new Implementors Guide

From: Terry L Anderson <[email-masked]>
Date: Thu, 01 Aug 2002 13:14:30 -0400

I'm trying to clean up some of the issues for the IG that have been 
discussed on the list.  This one got only the single response below.  On 
the issue of the change (in the current IG draft) to fix a parsing 
problem pointed out by Troy.  I believe that Aleksandr is correct that, 
while this fixes a parsing issue with Events, it only adds some 
consistency for Signals (eliminating the empty {} was important for 
Events to avoid the need for useless requestID).  Since we have other 
cases of empty '{}' that remain, it is probably not worth breaking 
compatibility for the Signals case.

We have three choice:
1) leave IG as current (changing spec for both Signals and Events)
2) do as Aleksandr is suggesting, keeping the change to Events as in the 
IG but removing the change for Signals
3) remove the entire item from the IG, arguing as I did in my original 
mail that the parsing ambiguity is not a problem.

I would probably suggest #2 although I still believe that #3 is a 
possibility.

Aleksandr Ryabin wrote:

> Hi,
>
>         I have a comment on 6.3 "Empty Descriptor Syntax".
> I'd like to point out that changing syntax for SignalsDescriptor
> was proposed by Troy to fix
>
> > 1) In the text encoding, some empty descriptors have the form
> > "Signals {}" while others have "Events".
>
> and not ambiguity that IG is talking about, that is
>
> > 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.
>
> I think that changing SignalsDescriptor syntax proposal was more
> for consistency reasons rather then to solve any technical issue and thus
> we might want to leave SignalsDescriptor as is, since it will potentially
> introduce backward compatibility issues.
>
> Thus I'd like to propose to modify IG 6.3 to delete changes to 
> SignalsDescriptor
> and to move SignalsToken from auditItem to auditReturnItem, that is to 
> have
> changes as follows:
>
> auditReturnParameter = (mediaDescriptor / modemDescriptor /
>         muxDescriptor / eventsDescriptor /
>         signalsDescriptor / digitMapDescriptor /
>         observedEventsDescriptor / eventBufferDescriptor /
>         statisticsDescriptor / packagesDescriptor /
>         errorDescriptor / auditReturnItem )
>
> auditReturnItem = ( MuxToken / ModemToken / MediaToken /
>         SignalsToken / DigitMapToken / StatsToken /
>         ObservedEventsToken / PackagesToken )
>
> auditItem = ( auditReturnItem / SignalsToken /
>         EventBufferToken / EventsToken )
>
>
> Thanks
>         Aleks
>
> At 09:30 PM 6/30/2002, Terry L Anderson wrote:
>
>> I sent this earlier  but it apparently was not forwarded by the 
>> reflector since it was sent from my alternate email account.  I am 
>> sending it again.  I apologize if you get it twice.
>>
>> A new version of the H.248 Implementors Guide was discussed here at the
>> Bruges, Belgium ITU SG16 WP2 Rapporteurs meeting.  It contains 7 new
>> items applying to both H.248.1 V1 and V2.  (Recall that the base
>> recommendation containing the main body and Annexes A-E and Appendix A
>> were renumbered after Feb 2002 as H.248.1 with other Annexes as H.248.x).
>>
>> It can be accessed by anonymous ftp at
>>    ftp://standard.pictel.com/avc-site/0206_Bru/TD-36.zip
>> although if you look soon it may still be in:
>>    ftp://standard.pictel.com/avc-site/incoming/TD-36.zip
>>
>> Note that there are two issues that readers should particularly note:
>>
>> IG 6.6 changes the recommendation for documenting packages, that
>> statistics should be specified as they actually have been in Annex E and
>> include a specification of the type.  The item suggests that all the
>> same types available for parameters be allowed.  The non-numeric types
>> may not seem reasonable for "statistics" but if one considers that
>> statistics are simply a way to query about the value of some readonly
>> parameter (already available with audit) but one that is automatically
>> reported on a Subtract.  Then non-numeric values may be quite useful
>> (eg, the contents remaining in a dial string buffer, DMTF digits, value
>> of some enumeration used by the package, etc.)  If the experts conclude
>> that these non-numeric values are not useful we can remove them before
>> final approval of the IG at the next Study Group meeting in Oct.
>>
>> IG 6.3 resolves an issue raised some time ago on the list by Troy Cauble
>> about a parsing conflict introduced by previous changes to allow empty
>> Events lists.  He proposed this solution nearly a year ago but the
>> thread ran out with no comments.  The issue was raised again recently
>> and someone pointed out this solution.  We put the solution into the IG
>> but on further discussion I am not convinced that the "conflict" needs
>> to be fixed.  Let's discuss this and decide whether to keep the change.
>>
>> Troy's point was an parsing ambiguity between an empty eventsDescriptor
>> and  auditItem since in the location he illustrates either could be
>> simply "Events".
>>
>> Troy wrote:
>> 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 
>>        }
>>    }
>> }
>>
>> It is absolutely true that this ambiguity exists now, but the question
>> is whether it is a problem. I would assert that both mean the same 
>> thing.  It could be a reply to an
>> Add with an empty Events Descriptor (This would be more likely in a
>> Modify, but the same issue exists there).  Or it could be a reply to an
>> Add including a AuditValue{Events} when the event list is empty.  But
>> the meaning is the same (that the events descriptor is empty).  I
>> suppose strictly speaking one could send an Add (or Modify) with an
>> empty Events descriptor and also request Audit{Events} in which case one
>> could get Events, Events in the response, but it is a little pointless
>> for an MGC to do this unless it is simply testing the MG for complience
>> (if it sets it to empty the Audit should always return empty).  So it
>> certainly leads the parser down two choices and any automatic parser
>> generator is likely to return an error, but since both mean the same
>> thing it is no really an operational problem.
>> The question is: do we want to fix it as specified here or leave the
>> syntax unchanged and keep the ambiguity?  The item will remain in the
>> IG, changing the syntax (after IG is approved), unless I get sufficient
>> responses saying we'd rather leave it.
>>
>> -- 
>>
>> ------------------------------------------------------------
>> Terry L Anderson              mailto:[email-masked]
>> Tel:732.949.5628   Fax:732.949.7016
>> Lucent Technologies/INS/Voice Over IP Access Networks
>> Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
>> http://its.lucent.com/~tla <http://its.lucent.com/%7Etla> (Lucent 
>> internal) http://www.gti.net/tla
>>
>>
>>
>>
>> _______________________________________________
>> Megaco mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/megaco
>

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

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

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 01 Aug 2002 13:14:30 -0400

We have three choice:

--

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Aug 2002 11:12:22 +1000

G'Day Terry,

At this stage in with H.248 I'm largely against making changes to syntax for
inconsistency reasons. This is because of the large number of implementations
that have been developed. I'm supportive of 3) but if people have an
overwhelming need for the event change then 2) may be an option.

Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Aug 2002 11:12:22 +1000

G'Day Terry,

Christian