Subject: Re: Subtract Command with wildcard Termination Name

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 24 Jan 2000 22:09:42 -0500

I think this is headed in the wrong direction.  Subtract of wildcarded
contextId was explicitly allowed for,
among other things, the response to a ServiceChange with mass out of service
operations pending.
The MGC must subtract all calls, and do it in a hurry.

It is also useful in a wildcard Audit, with or without W-.

So I think it is allowed, period.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Monday, January 24, 2000 10:06 AM
To: [email-masked]
Subject: Re: Subtract Command with wildcard Termiantion Name

Your question has a couple of wider implications.  My first reaction was to
say this was an error, because in principle the MGC can always know which
context a termination is in, through audits if necessary.  Then I checked
out our audit response syntax and realized that the MGC cannot determine the
current context of a termination if it doesn't know it already.

I think the answer has to be that we change the production auditOther to
include the context ID.

e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
terminationAudit RBRKT

Then the answer to your original question is that it is an error.

        -----Original Message-----
From:   Sachin Mittal [SMTP:[email-masked]]
Sent:   Sunday, January 23, 2000 11:56 PM
To:     [email-masked]
Subject:        Subtract Command with wildcard Termiantion Name

        Hi!
     Here is a small query regarding the case where ContextID is "*" and
Termination Name is fully-specified. Does this implies that MGC intends to
Subtract the specific termination from
"whichever" context it appears in ? Or it is an error because a termination
can
exist only in one context and
ContextID = "*" for a specific termination is an error ?

        Regards
MadhuBabu

---

From: Sachin Mittal <[email-masked]>
Date: Tue, 25 Jan 2000 20:08:04 +0530

OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG that choose
 the context  in which the given Termination exist and subtract the termination.

"Rosen, Brian" <[email-masked]> on 01/25/2000 08:39:42 AM

Please respond to "Rosen, Brian" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Subtract Command with wildcard Termination Name

Brian

        -----Original Message-----
From:   Sachin Mittal [SMTP:[email-masked]]
Sent:   Sunday, January 23, 2000 11:56 PM
To:     [email-masked]
Subject:        Subtract Command with wildcard Termiantion Name

        Hi!

        Regards
MadhuBabu

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Jan 2000 16:00:35 -0500

I believe that
    Context=*{Modify=TermId{Audit{})
should return something like
    Context=c11911{Modify=TermId}

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, January 25, 2000 8:37 AM
To: Rosen, Brian; [email-masked]
Subject: RE: Subtract Command with wildcard Termination Name

OK, this is the second comment I've had to this effect -- the other was
received privately.  The one question is whether we want a way to find out
what context a termination is in without subtracting it to find out, in
which case the audit response syntax I suggested might be considered.
Silence means we don't need this additional functiuonality.

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Monday, January 24, 2000 10:10 PM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
Subject:        RE: Subtract Command with wildcard Termination Name

        I think this is headed in the wrong direction.  Subtract of
wildcarded contextId was explicitly allowed for,
among other things, the response to a ServiceChange with mass out of service
operations pending.
The MGC must subtract all calls, and do it in a hurry.

Brian

        -----Original Message-----
From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, January 24, 2000 10:06 AM
To: [email-masked]
Subject: Re: Subtract Command with wildcard Termiantion Name

        Your question has a couple of wider implications.  My first reaction
was to say this was an error, because in principle the MGC can always know
which context a termination is in, through audits if necessary.  Then I
checked out our audit response syntax and realized that the MGC cannot
determine the current context of a termination if it doesn't know it
already.

        I think the answer has to be that we change the production
auditOther to include the context ID.

                -----Original Message-----
From:   Sachin Mittal [SMTP:[email-masked]]
Sent:   Sunday, January 23, 2000 11:56 PM
To:     [email-masked]
Subject:        Subtract Command with wildcard Termiantion Name

                Hi!

                Regards
MadhuBabu

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Jan 2000 16:08:52 -0500

Just sent a couple of messages that address this:
Choose in a ContextId is create a new one

Brian

> From: Sachin Mittal [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2000 9:38 AM

---

From: Sachin Mittal <[email-masked]>
Date: Thu, 27 Jan 2000 11:29:11 +0530

Agreed that "Choose in a ContextId is create a new one".  Does this mean that
in MOVE $ in ContextID is allowed (Move a termination to a "new" context)? Or is
it that
$ in ContextID is only allowed in case of ADD?

We need to add the following line somewhere in the text:
"A $ in ContextID means to CREATE a new context and except ADD (and MOVE ??)
it can't appear in any other command"

Regarding ContextID * and $ in Subtract our thinking was:
1) ContextID * means "search for a termination in all contexts and subtract from
it"
2) ContextId $ means "find the context in which the termination exists and
subtract it from that context"
By this logical meaning it seems that both are valid. But now we agree to what
you say and (2) is not allowed.

"Rosen, Brian" <[email-masked]> on 01/27/2000 02:38:52 AM

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 11:39:36 -0600

I'll consider this one closed based on your and Brian's solutions.

> From: Chuong Nguyen [SMTP:[email-masked]]
> Sent: Tuesday, January 25, 2000 10:27 AM
> Is the following what you want to do?
>
> Transaction=1000{Context=*{AuditValue=T123}}
> Reply = 1000{Context=2222{AuditValue=Context{T123}}
>
> or
>
> Transaction=1000{Context=*{AuditValue=*}}
> Reply = 1000{Context=2222{AuditValue=Context{T123},
>                          Context=3333{AuditValue=Context{T222,T333},
>                          Context=.....}
>
> If yes, this is already taken into account by the current ABNF.
>
> Chuong
>
> Tom-PT Taylor wrote:
>
>
>
>       OK, this is the second comment I've had to this effect -- the other
> was received privately.  The one question is whether we want a way to find
> out what context a termination is in without subtracting it to find out,
> in which case the audit response syntax I suggested might be considered.
>       among other things, the response to a ServiceChange with mass out of
> service operations pending.
>               From: Tom-PT Taylor [ <mailto:[email-masked]>]
>                       Your question has a couple of wider implications.
> My first reaction was to say this was an error, because in principle the
> MGC can always know which context a termination is in, through audits if
> necessary.  Then I checked out our audit response syntax and realized that
> the MGC cannot determine the current context of a termination if it
> doesn't know it already.
>
>                       I think the answer has to be that we change the
> production auditOther to include the context ID.
>
>                       e.g.auditOther = EQUAL TerminationID LBRKT  CtxToken
> EQUAL ContextID  terminationAudit RBRKT
>
>               "whichever" context it appears in ? Or it is an error
> because a termination can
> --
>   Alcatel USA, Inc             Internet: [email-masked]
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Jan 2000 13:10:27 -0500

I always thought of the commands as actually working that way,
and it's how I would implement them, dd/Move/Modify is one command with some
syntactic sugar that makes the intention clearer.

You will note that the ABNF reflects this: we have
AMMRequest and AMMReply instead of separate constructs for
each command.

I've also pointed out that AuditValue is actually a no-op command
(since Audit can occur in AMM & Subtract), and Subtract is
        Context=-{Move=<TermId>{Audit{Statistics}}}

We do state that Move of the last termination causes the context
to be deleted (as well as Subtract of the last termination).
Making Move to Null have the side effect of deleting an ephemeral has the
same sort of rule.

In the IETF tradition, we could make the text say that the sender shall not
do this kind of thing, and the receiver shall
accept this kind of thing.

Brian

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, January 27, 2000 12:43 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Rosen, Brian writes:
>  > Can't say I have a really good reason, but I think that two ways
>  > to do the same thing are a bad idea.
>
>    So it's better to invent an artificial difference
>    to give Add some claim to uniqueness which is
>    basically covering up that it would otherwise
>    just be a subset of Move?
>
>    From a programming standpoint, I'd much rather
>    code a Move superset function where Add is
>    just an API convenience, rather than have to
>    deal with exceptions that are exceptions for
>    the sake of being exceptions.
>
>    PS: doesn't Modify also meet this test too?
>    Eg, Modify is nothing more than Move to and
>    from the same destination context? Should we
>    invent a uniqueness barrier here too? Ditto
>    Subtract?
>
>           Mike
>
>  >
>  > Brian
>  >
>  > > From: Michael Thomas [mailto:[email-masked]]
>  > > Sent: Thursday, January 27, 2000 11:45 AM
>  > > To: Rosen, Brian
>  > > Cc: [email-masked]
>  > > Rosen, Brian writes:
>  > >  > It is legal to move a termination to a new context, but we
>  > >  > wanted to not allow that from null context.
>  > >
>  > >    Why is this? If you allowed it, it seems that
>  > >    Add would just be a subset of Move.
>  > >
>  > >         Mike
>  > >  >
>  > >  > Brian
>  > >  >
>  > >  > > From: [email-masked] [mailto:[email-masked]]
>  > >  > > Sent: Thursday, January 27, 2000 12:59 AM
>  > >  > > To: Rosen, Brian
>  > >  > > Cc: [email-masked]
>  > >  > > By this logical meaning it seems that both are
> valid. But now
>  > >  > > we agree to what
>  > >  > > > OK "*"  is allowed. Is "$" allowed ? Where MGC
> indicating MG
>  > >  > > > that choose
>  > >  > > > among other things, the response to a
> ServiceChange with mass
>  > >  > > > out of service
>  > >  > > > operations pending.
>  My first
>  > >  > > > reaction was to
>  > >  > > > e.g. auditOther = EQUAL TerminationID LBRKT
> CtxToken EQUAL
>  > >  > > ContextID
>  > >  > > > terminationAudit RBRKT
>  > >  > > >
>  > >  > > >      Here is a small query regarding the case
> where ContextID
>  > >  > > > is "*" and
>  > >  > > > Termination Name is fully-specified. Does this
> implies that
>  > >  > > > MGC intends to
>  > >  > > > "whichever" context it appears in ? Or it is an
> error because
>  > >  > > > a termination
>  > >  > > > can

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 13:26:33 -0500

The catch is that ephemerals aren't there to Move in the first place.

We briefly discussed whether we really needed Move back in the thread "Move
not needed", 14-15 April 1999.  The argument then was that Move could be
done using an Add command with specified context.  Fernando Cuervo
counter-argued that one could exploit command similarity in implementation,
but gain in protocol clarity by having the separate commands.  At that time
this argument prevailed.

I'd swear I suggested Move to Null context somewhere back then and had my
wrist slapped for doing so, but I can't find the exchange at the moment.

Summary: we are where we are because the different commands have their own
distinct roles.  In particular, Move is restricted to transferring
terminations between active contexts, preserving state as much as possible
while doing so.

> From: Michael Thomas [SMTP:[email-masked]]