Subject: Re: ASN.1 - Values in Event and Signal Parameter

From: Sandeep Gautam <[email-masked]>
Date: Mon, 15 Jan 2001 12:42:25 +0530

Hi Christian,

In that case, when the MGC does an audit capability of Events/Signal Descriptor,
how is the MG supposed to return the range/ multiple values of paramters
supported in the audit reply? Should multiple events (with same event id) be
sent in the ED, or should multiple ED be sent in the audit reply?

Also, the text doesnt explicitly prohibit choosing of events and signal
paramters. Why should the parameter value behaviour be different from the
property value behaviour?

Thanks in advance,

Regards,
Sandeep Gauatm

Christian Groves <[email-masked]> on 15/01/2001 10:54:58

Please respond to Christian Groves <[email-masked]>

To:   [email-masked]
cc:    (bcc: Sandeep Gautam/HSS)

Subject:  Re: ASN.1 - Values in Event and Signal Parameter

Hello Shiv,

I don't believe that the protocol allows for ranges and alternatives for
signal values. Its certainly not described in the procedural part of the
protocol. The MG plays what ever it is told by the MGC it can't choose
this. Therefore I don't think we need to add a field.

Cheers, Christian

Shiv Kumar wrote:
>
> Hi List,
>
> The following structures descrbe the ASN.1 notation for Event and Signal
> Parameters.
>
>        EventParameter ::= SEQUENCE    {
>          eventParameterName              Name,
>          value                           Value    }
>
>        SigParameter ::= SEQUENCE    {
>          sigParameterName                Name,
>          value                           Value    }
>
> How  does one specify the Range/relation/Sub-list/Alternatives information
for
> the Value list ?
> I think we need one more field similar to the 'ExtraInfo' field in
PropertyParm.
> Regards
> Shiv

---

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

G'Day Sandeep,

I only referred to ranges and alternatives which is the extra info field
which I still don't think we need. I do think that multiple values in
the case of audit and for sub-list types is needed. But I see that the
ABNF allows this whilst the protocol procedures don't talk about its
use. So you are probably correct that we should align the 2. I think
Troy also touched it in one of his emails that it should also be a
SEQUENCE OF. We should also align the eventParameterValue field as well.

So I suggest:
1.5 Ranges and Multiple Values for Signal and Event Parameter Values

Description:     The ABNF specification allows the specification of
multiples values and ranges for a signal and event parameter value. The
ASN.1 currently does not and needs to be aligned.
Reference:      Subject:  Re: ASN.1 - Values in Event and Signal Parameter
Date: Mon, 15 Jan 2001 12:42:25 +0530
From: Sandeep Gautam <[email-masked]>
To: [email-masked]
 [Begin Correction]
…
EventParameter ::= SEQUENCE
{
        eventParameterName      Name,
        value                           SEQUENCE OF Value,
-- For use of extraInfo see the comment related to PropertyParm
        extraInfo CHOICE
        {
                relation        Relation,
                range           BOOLEAN,
                sublist BOOLEAN
        } OPTIONAL,
        ...
}
…

SigParameter ::= SEQUENCE
{
        sigParameterName                Name,
        value                           SEQUENCE OF Value,
-- For use of extraInfo see the comment related to PropertyParm
        extraInfo CHOICE
        {
                relation        Relation,
                range           BOOLEAN,
                sublist BOOLEAN
        } OPTIONAL,
        ...
}
…
 [End Correction]

Any comments?

Cheers, Christian

---

From: Dan Linton <[email-masked]>
Date: Thu, 18 Jan 2001 20:01:26 -0500

Christian,

I agree with the proposed change to align the ASN and ABNF
notations.

I'm interested in why you don't think we need ranges and alternatives.
Is it implied somewhere that parameters such as the inter signal
duration (ind) parm in the tonegen package cannot be specified as
a range of values? The example I've chosen may not make sense, but
what precludes an MGC from sending it as a range of values to an
MG? Is it because ranges are not explicitly discussed in the
procedures associated with this particular parameter?

Thanks,
Dan

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Jan 2001 15:48:57 +1100

G'Day Dan,

I didn't think we needed ranges or alternatives because I don't think we
ever discussed them in the protocol development. The example you give
shows that there are interactions that we haven't thought of or
documented. Alternatives really don't think should be presented as we
haven't defined the behaviour for this. ie. I don't think we have a
mechanism for the MG to present exactly what it did. Alternatives
quickly lead to the CHOOSE wildcard and again I don't see where this is
defined either. Signal behaviour is different to property behaviour in
that you set it, it plays and is gone.

Cheers, Christian

---

From: Troy Cauble <[email-masked]>
Date: Fri, 19 Jan 2001 11:19:31 -0500

Dan Linton wrote:
> > use. So you are probably correct that we should align the 2.

As one of the contributors to this subject, let me say
that I don't know that we need these capabilities either.

I was just trying to align the ASN.1 and text.  If someone
thinks we should consider aligning them by restricting the
text instead of expanding the ASN.1, that's OK by me.

-troy