Subject: RE: ContextId for an error

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 30 Mar 2001 11:48:49 -0500

Good point.  I suppose that leaves us with CHOOSE as the response, but is
this going to upset things?

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, March 30, 2001 11:31 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; [email-masked]'
Subject: RE: ContextId for an error

The problem with b is that the MGC sends a CHOOSE, expecting a
new ContextId back, but gets an error, with an EXISTING contextId back.
I'm worried it will be confused
 
You can read that as a concern that you get a complicated implementation
to deal with getting a ContextId that exists back from a command that
specified CHOOSE.  It implies that you ignore the ContextId until you 
parse the command (and discover an error).
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Friday, March 30, 2001 11:17 AM
To: 'Rosen, Brian'; [email-masked]'
Subject: RE: ContextId for an error

(b) would supply the maximum information, so long as everyone agrees. 

> -----Original Message----- 
> From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Friday, March 30, 2001 8:55 AM 
> To: [email-masked]' 
> Subject: ContextId for an error 
> 
> 
> Suppose you sent an Add to an MG with a CHOOSE ContextId, 
> but the termination was already in a context.  You get an 
> error (433), but in the reply, what ContextId do you get: 
> 
> a) Null 
> b) Context termination is already in 
> c) Context you would have assigned 
> d) CHOOSE 
> 
> I think a) 
> c) is clearly wrong 
> 
> Need words in the Implementor's Guide 
> 
> Brian 
>

---

From: "PAUL RHEAUME" <[email-masked]>
Date: Fri, 30 Mar 2001 12:52:13 -0500

Brian, Tom, List,

The problem, as I see it, with using CHOOSE in the reply is that it
forces an extra step to be carried out, i.e. the MGC will need to do an
Audit on the TerminationID to find out what Context the termination
belongs to.  The MGC can then go ahead and do whatever clean up is
necessary.

By returning the (b) Context termination is already in, the MG provides
all the information the MGC will require to clean up.

Cheers,
Paul

Tom-PT Taylor wrote:

>  Good point.  I suppose that leaves us with CHOOSE as the response,
> but is this going to upset things?
>
>      The problem with b is that the MGC sends a CHOOSE, expecting
>      anew ContextId back, but gets an error, with an EXISTING
>      contextId back.I'm worried it will be confusedYou can read
>      that as a concern that you get a complicated
>      implementationto deal with getting a ContextId that exists
>      back from a command thatspecified CHOOSE.  It implies that
>      you ignore the ContextId until you parse the command (and
>      discover an error).Brian
>

---

From: Chuong Nguyen <[email-masked]>
Date: Fri, 30 Mar 2001 12:29:26 -0600

Brian

Are you saying that by just looking at ContextID, one can assume
everything is Ok
before parsing the rest of the command?

The implementation is going to be complicated no matter what because
the implementation might have 1 ADD or multiple ADDs in an Action.
The implementation is going to have to parse throught the commands before
it can
decide how to treat the ContextID.

What if there were multiple ADDs in the Action w/ContextID=$?
The first ADD was successful and the second ADD returns 433.
The returned ContextID would have not been CHOOSE but a valid ContextId
since
the first ADD was successful.

Do we need to explicitly describe every scenarios in the IG and what the
responses
will look like for each scenarios?

Tom, what do you mean by upset things - Someone's current implementation
or
break other commands?

Chuong

--
  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 ****