[Top] [All Lists]

Re: 10.4 IDENTIFY Command II

2002-12-04 15:50:22

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]: 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                     |
 Doug(_at_)Royer(_dot_)com                 | Office: (208)612-INET   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

                We Do Standards - You Need Standards

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

<Prev in Thread] Current Thread [Next in Thread>