Subject: RE: g/sc SigID list

From: "Tulpule, Naren" <[email-masked]>
Date: Wed, 13 Jun 2001 10:40:55 -0700

Hi Troy,
  I think the g/sc way to report signal completion creates more problems
than it solves. For example, if a new package with a new signal is defined,
does it mean the "g"(generic) package is automatically extended to include
that sigID as a possible parameter for g/sc?
  I hope future package creators include a "signal completion" event in the
package itself for every signal, if the package has signals. Event
parameters will be "Meth" and signal list ID if any. Event name can be
signal name (if that's not too confusing) or sc_<signal name> or some such.
Then we don't need to keep on extending g/sc.

These views are mine alone, not those of Intel or Trillium.
-- Naren
Narendra C. Tulpule         310-442-9222
SMTS, Trillium (an Intel company)
12100 Wilshire Bl #1800 Los Angeles CA 90025
I get enough exercise just pushing my luck.

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 8:05 AM
To: MEGACO list
Subject: Re: g/sc SigID list

BTW, here are some uses that I think are consistent with 
the syntax description in E.1.2.  Anyone care to comment?
This is vague enough in E.1.2 that it should be clarified
with some examples.

Note that a sublist uses [] not {} according to the ABNF
for alternativeValue.

1.Reporting a signal outside of sequential signal list:
SigID="pkg1/sig1"

2.Reporting a  signal inside a sequential signal list:
SigID="SignalList = 1 {pkg1/sig1}"

3.Reporting a  list of signals outside of sequential signal list:
SigID=[ "pkg1/sig1" , "pkg2/sig2" ]

4.Reporting a  list of signals inside a sequential signal list:
SigID=[ "SignalList = 1 {pkg1/sig1}", "SignalList = 2 {pkg2/sig2}" ]

5.Reporting a list of both signals and sequential signal lists:
SigID=[ "pkg1/sig1" , "pkg2/sig2", "SignalList = 1 {pkg3/sig3}", 
"SignalList = 2 {pkg4/sig4}" ]

-troy

Troy Cauble wrote:
> 
> Proposal:
> 
> Change the Type of the g/sc SigId parameter in E.1.2
> from "list" to "string".
> 
> Argument:
> 
> Sections 12.1.2 and 12.2 define allowable types
> for Properties and Parameters, including "String"
> and "Sub-list".
> 
> Annex E.1.2 (g/sc) defines parameter SigID as
> being a "list" and references a complex syntax for
> that "list" which includes nested braces.
> 
> This specific syntax conflicts with the established
> syntax for a list.
> 
>    parmValue            = (EQUAL alternativeValue/ INEQUAL VALUE)
>    alternativeValue     = ( VALUE
>                           / LSBRKT VALUE *(COMMA VALUE) RSBRKT
>                             ; sublist (i.e. A AND B AND ...)
>                           / LBRKT VALUE *(COMMA VALUE) RBRKT
>                             ; alternatives (i.e. A OR B OR ...)
>                           / LSBRKT VALUE COLON VALUE RSBRKT )
>                             ; range
> 
> If the type is redefined as "String", double quotes
> will be required (IG 6.80).  Within that quotedString,
> the syntax could stay as defined.
> 
> Besides the fact that this syntax is in direct conflict
> of the ABNF specification,  I think it is unreasonable
> to allow a package to define a complex syntax to be
> embedded directly in a VALUE without quoting.  Parsers
> should be able to parse the message down to the VALUE
> level without package knowledge.
> 
> Comments?
> 
> -troy