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

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jan 2001 16:24:58 +1100

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: Shiv Kumar <[email-masked]>
Date: Tue, 16 Jan 2001 22:33:27 +0530

Hi,

 In  Implementation Guide V7, Section 6.44,  you have already taken care of
multiple values;
by changing the type of 'Value' to 'SEQUENCE OF'.
 So one of the two needs to be corrected.

 I guess, 'SEQUENCE OF Value' makes more sense than the former.

Regards
Shiv

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

Sandeep Gautam wrote:
>
> 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,
>

---

From: Sandeep Gautam <[email-masked]>
Date: Fri, 19 Jan 2001 13:20:49 +0530

G' Day Christian,

I think Event paramter behaviour persists until the ED is replacedthere might be
some justification for specifying alternatives for that. As for the reporting
mechanism,  the MG can send the ED back in reply in ammsreply field ( rather
than termination audit field) and thus the MGC can know which values were
chosen. I'm not sure whether the MG is supposed to send the ED back in reply if
soem paramter values were unspecified( i'e paramter wa not present). I guess it
should send all the paramters back to MGC, in case soem were unspecified, if it
will use those paramter values for detecting the event.
An example is al/off --- If this event is sent without parametrs, MG should send
the ED back in reply with the parameter value of (strict transition' that is
configured as default. Of course, the MGC should not depend on it;-)
(its not mentioned in the packages as to which parametrs are mandatory and which
optional)
Regards,
Sandy G

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

Dan Linton wrote:
>
> 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
>
> Christian Groves wrote:
>
> > G'Day Sandeep,
> >

à

à

à
Descriptor,
> > > > How  does one specify the Range/relation/Sub-list/Alternatives
information
> > > for