Bruce_Kahn(_at_)notesdev(_dot_)ibm(_dot_)com 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
-------------------------------|-----------------------------
Doug(_at_)Royer(_dot_)com | Office: (208)612-INET
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
smime.p7s
Description: S/MIME Cryptographic Signature