Subject: Re: 10.4 IDENTIFY Command II

From: Doug Royer <[email-masked]>
Date: Wed, 04 Dec 2002 15:02:36 -0700

[email-masked] wrote:
> 
> Andrea responded on 11/18/2002 01:33:41 PM:
>  > The more I think about it, the more I think an explicit BYE command
>  > would be beneficial.
> 
> I concur.  The BEEP dropping of a session is at the transport level. 
>  CAP is at the application level so a command _is_ appropriate.  After 
> all, there may be CAP commands still in progress when the CUA decides to 
> go away.  It should do so first at the application level rather than at 
> the transport or network levels.
> 
> If the CS has commands its still processing then the BYE command should 
> be prevented.  Otherwise a nice clean disconnect can be done and BEEP 
> shutdown done, etc.

In [BEEP]:

2.3.1.3 The Close Message

  When a BEEP peer wants to close a channel, it sends a "close" element
    on channel zero, e.g.,

    ...

    A BEEP peer may send a "close" message for a channel whenever all
    "MSG" messages it has sent on that channel have been acknowledged.
    (Acknowledgement consists of the first frame of a reply being
    received by the BEEP peer that sent the MSG "message".)

    ...

    NOTE WELL: until a positive reply to the request to close the channel
    is received, the BEEP peer must be prepared to process any "MSG"
    messages that it receives on that channel.

So there can not be any outstanding commands on an open channel.
You can not send CAP commands on BEEP channel zero.
And you have to wait for the responder to acknowledge the close.
So your above case can not happen.

There was a recent post by someone saying that we should not
be doing anything that increases the chattiness (my words) of
the protocol - and this is one of them. As in 100% of all
of the cases the over the wire sequence would be:

     (1) CUA: sends - BYE

     (2)  CS: <CS ignores this because the channel is not closed>
              but sends - okay anyway because it is specified in CAP.

     (3) CUA: sends - close channel X.

     (4)  CS: sends - okay <this time it is real>

Steps (1) and (2) are a 100% useless delay. And if there
are any outstanding commands on channel X, then they MUST BE
processed by the CS and the CUA MUST be ready for those
replies - AFTER THE BYE.

No lets not do that.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards