Subject: Re: Add *

From: Fernando Cuervo <[email-masked]>
Date: Thu, 2 Sep 1999 11:58:28 -0400

Well, even in certain cases where you "succeed"  the interpretation the
scope of the wildcard will be different in the MGC and the MG, you will end
up doing an audit anyhow. As we can see from the discussion, the concept of
transaction success/ failure is surely drifting away from the classical
definition of a "flat" transaction, certainly some of the discussion on the
topic shows glimpses of the nested and chained transactions that have been
used for many years.  I'm not advocating the generalisation of Megaco to do
all these things, but I believe that transactions with o- optional commands
is  a small increment that complements well the original flat transaction
model that we wanted to adopt. As far as the success/failure stuff, we could
use a single term: "response", there is no need to differentiate between one
and the other since the syntax is the same and the processing is the same:
for a "success" you still have to go and collect for each command in each
action the returned parameters, in a "failure" you find an error code!. So
the proposal is:
1-keep the transaction flat with o- type commands
2-unify reject/accept into "response"

Fernando Cuervo
> ----------
> From:         Lehecka, Gary R (SAIC)[SMTP:[email-masked]]
> Sent:         September 1, 1999 8:48 PM
> To:   [email-masked]
> Subject:      Re: Add *
>
> Hi,
>
> Success means that I do not have to do anying else,
> my command succeeded,
> and I can go on to what I was going to do next
> without checking status or doing anything else.
>
> "Failure" means that I still need to do something,
> i.e. check what the actual status and reason was,
> and decide what to do next.
> not necessarily that my command "failed".
>
> Thanks,
> Gary Lehecka
> [email-masked]
> BP  250 - 3671
> US  ( 216 )  586 - 3671
> > ----------
> > From:         Fernando Cuervo[SMTP:[email-masked]]
> > Reply To:     Fernando Cuervo
> > Sent:         Wednesday, September 01, 1999 1:52 PM
> > To:   [email-masked]
> > Subject:      Re: Add *
> >
> > the proposal is a "reasonable definition of success"  for situations
> where
> > the MGC does not know or cannot infer the set of terminations that the *
> > covers. Just think about resetting a large set of terminations of a
> class
> > to
> > a given state, the semantics of failure are definitely not appropriate
> > when
> > all but one termination succeded in changing state.
> >
> > Fernando Cuervo
> >
> > > ----------
> > > From:         Brian Rosen[SMTP:[email-masked]]
> > > Sent:         September 1, 1999 7:57 AM
> > > To:   [email-masked]
> > > Subject:      Re: Add *
> > >
> > > I agree with Tom's analysis.  If MyTerm* matches
> > > MyTerm1, MyTerm2 and MyTerm3, and I do Add=MyTerm*{...,
> > > then unless all three Terminations are added, the command fails.
> > >
> > > Bria
> > >
> > > > -----Original Message-----
> > > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > > Sent: Tuesday, August 31, 1999 9:24 PM
> > > > To: [email-masked]
> > > > Subject: Re: Add *
> > > >
> > > >
> > > > You raise interesting possibilities in my mind.  Remember
> > > > that we have two
> > > > wildcards: "choose" and "all".  I assume you are talking
> > > > about "all", and
> > > > this "all" is constrained by a preceding partial
> > > > terminationID so that it
> > > > doesn't include every trunk in the office.  I could visualize
> > > > such a case if
> > > > you were trying to set up the equivalent of a wideband
> > > > connection (e.g. at
> > > > the T-1 or E-1 level).
> > > >
> > > > That said, I can't see your proposal as being a reasonable
> > > > definition of
> > > > success: if there's a failure along the line, I don't get the
> > > > full wideband
> > > > connection I was asking for.
> > > >
> > > > > -----Original Message-----
> > > > > From: Greene, Nancy-M [CAR:5N10:EXCH]
> > > > > Sent: Tuesday, August 31, 1999 9:46 AM
> > > > > To:   [email-masked]
> > > > > Subject:      Add *
> > > > >
> > > > > The text in section 6.3.3.1 Add, needs the following sentence:
> > > > >
> > > > > If an Add with a wildcarded TerminationId is used, the
> > > > command succeeds if
> > > > > at least one termination is added.
> > > > >
> > > > > Nancy
> > > > >
> > > > >
> > > > --------------------------------------------------------------
> > > > ------------
> > > > > Nancy M. Greene
> > > > > Internet & Service Provider Networks, Nortel Networks
> > > > > T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
> > > >
> > >
> >
>