Subject: v10 review: text for optional commands

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 27 Sep 1999 10:18:25 -0400

Last Thursday, Nancy Greene posted a proposal for an "o-" syntax for
optional commands within a transaction.  Why bother?  Couldn't the command
simply go into a transaction of its own?

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 30 Sep 1999 13:54:27 -0500

There's plenty of time in human terms to do the optional item after the main
one has gone through, as a separate transaction in a separate message.  At
home, my display of calling party doesn't come up until after the first ring
-- that's a delay of at least two seconds.  The rule of thumb I've suggested
for our protocol engineering is to assume a turn-around time in the order of
100 ms.

> -----Original Message-----
> From: Christian Groves [SMTP:[email-masked]]
> Sent: Thursday, September 30, 1999 12:58 AM
> To:   [email-masked]
> Subject:      Re: v10 review: text for optional commands
>
> When I first thought of the optional transactions it was more to fix the
> transaction handling and error handling for a large list of wildcarded
> terminations (which I think is fixed now). However I think that the
> point that Fernando brings up below is another valid use of the o- . I
> think the first concern in a call is that it is through connected in the
> minimum time possible.
>
> We shouldn't have to wait for error handling/rejected
> transaction/re-establishment for a failure (ie. callID) that isn't
> critical to through connection. If we can mark commands as o- I think
> this would prove beneficial particularly in the residential gateway.
>
> Cheers, Christian
>
> Fernando Cuervo wrote:
> >
> > I believe this proposal has been out there for a while. The intent is to
> > allow transactions to succeed even if certain things do not happen,
> (i.e.,
> > those labelled o-). This becomes handy for features such as name display
> > (you don't necessarily fail the call if you fail to display callId). And
> > yes, it extends the classical definition of a transaction, but
> extensions
> > have been done before for practical reasons in the enterprise world
> > (chained, hierachical  transactions, etc.). As far as doing it with two
> > transactions, that wouldn't work at all in the call display example..
> >
> > Fernando Cuervo
> >
> > > ----------
> > > From:         Taylor, Tom-PT [CAR:B904-I:EXCH]
> > > Sent:         September 27, 1999 10:18 AM
> > > To:   [email-masked]
> > > Subject:      v10 review: text for optional commands
> > >