Subject: MEGACO: Impl. guide comments/corrections

From: Troy Cauble <[email-masked]>
Date: Tue, 21 Nov 2000 10:55:11 -0500

Hello all,

Section 6.23 of the Implementors Guide discusses the
fact that sigParameter is hard to parse because it's
impossible to tell the sigStream sequence from the
sigOther sequence.

I find this statement confusing:
        "The problem lies in the fact that in the future
         that the introduction of a new Token for a
         signal Parameter may cause overlap with an
         existing package identity."

More to the point is the fact that the opposite problem
exists *NOW*.  Package identities (i.e. signal parameter
names) can be defined such that they conflict with nearby
tokens such as DurationToken, StreamToken, SignalTypeToken,
etc.  These tokens are used in "Token EQUALS X" sequences
that are impossible to distinguish from sigOther.

While the following change to section 12.2:
        "The textual ParameterID of parameters to Events
         and Signals shall not start with "EPA" and "SPA"
         respectively."

guards against conflicts with FUTURE tokens, it does not
guard against conflicts with CURRENT tokens.

There are many other things that these "textual ParameterIDs"
must avoid matching.  A (partial?) list for signal parameter
names is:
        StreamToken
        SignalTypeToken
        DurationToken
        NotifyCompletionToken

A (partial?) list for event parameter names is:
        ModemToken
        StreamToken
        DigitMapToken

The lists are a little longer if you want to make parsing easy.
These are required to make parsing possible.  They should be
listed in the correction to section 12.2.

-troy

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Nov 2000 04:19:31 +1100

Hello Troy,

I'm not sure what the current problem is. Any overlap between properties
and parameters have been resolved. Any new signal / event parameter must
be defined according to the new rule. The other tokens you list do not
overlap with the current signalOther definition.

Christian

---

From: Troy Cauble <[email-masked]>
Date: Tue, 21 Nov 2000 13:40:51 -0500

If I define a package with a signal parameter "dr"
you can't tell it from a DurationToken.

        Signals { foo/bar { dr=100, dr=200 }}

The "new rule" doesn't address this.  It only says
that my signal parameter name cannot start with "SPA".

-troy