Subject: Re: MEGACO: Impl. guide comments/corrections

From: Christian Groves <[email-masked]>
Date: Tue, 16 Jan 2001 16:40:32 +1100

G'Day Troy,

Yes you are correct I would propose the following addition to solve
this:

[Begin Correction]
12.2 Guidelines to defining Properties, Statistics and Parameters to
Events and Signals
Parameter Name: only descriptive
ParameterID: Is an identifier. The textual ParameterID of parameters to
Events and Signals shall not start with "EPA" and "SPA", respectively.
The textual ParameterID shall also not be "ST", "Stream", "SY",
"SignalType", "DR", "Duration", "NC", "NotifyCompletion", "KA",
"Keepactive", "EB", "Embed", "DM" or "DigitMap".
[End Correction]

Hopefully that covers the other parameters.

Cheers, Christian

Troy Cauble wrote:
>
> 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
>
> Christian Groves wrote:
> >
> > 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
> >
> > Troy Cauble wrote:
> > >
> > > 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 ideX-Mozilla-Status: 0009More 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