[BEEPbuilders] questions about session release and channel close

David Kramer dkramer at apple.com
Mon Oct 23 16:19:00 PDT 2006

On Oct 23, 2006, at 2:18 PM, Simon Raess wrote:

> You only answered how close requests for channel 0 that cross in  
> transit should be handled. What about close requests of any other  
> channel? It makes sense (too me) to reply to those close requests  
> with an ok message too. After all, the peer requested to close the  
> session so it wouldn't be sane to reply with an error in that case.  
> I think it should then still wait for the response to it's own  
> close request and be prepared to handle a negative response. Or?

(You confuse channel with session -- I'll assume you meant to say  
"After all, the peer requested to close the channel...")

This can only be answered on a channel-by-channel basis.  The channel  
profile must specify the correct behavior in this case.  BEEP  
frameworks should delegate this question to the profile implementations.

If you send a close channel request, and then receive a close channel  
request, you can choose to reply however you want.  Regardless of  
what you choose, if the remote peer responds to your request with  
"ok", you must close the channel.  And if you send an "ok" response  
to the remote peer's request, then the remote peer must close the  
channel, even if it replied "error" to your request.

Once you've replied "ok" to the peer's request, it doesn't make sense  
to wait for the peer's response to your request.  The response is  
meaningless.  By sending the request, the remote peer has already  
promised to close the channel as soon as it receives your "ok"  
response.  So the remote peer's response to your own request becomes  

Another way to say this is that once you request a close, you can't  
change your mind unless the remote peer decides to reject your request.

> Too bad that this part of RFC3080 is underspecified. After all,  
> what's the use of a standard if there is room for such  
> interoperability problems between implementations?

I think this is adequately specified.  I do not see any  
interoperability issues here -- if you request a channel close, and  
the peer says "ok", you must close it.  End of story.  No wiggle  
room.  The only grey area is what to do about the second response --  
if you have already agreed to close the channel by responding "ok" to  
your peer's request, and then you receive an "ok" or "error" from  
your peer in response to your request, I think you should simply  
ignore the message.  In other words, BEEP peers should always ignore  
replies to channel-close requests if the reply arrives after the  
channel has been closed.

If I'm missing something, perhaps you could clarify what  
interoperability issues you think could arise between implementations.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/beepbuilders/attachments/20061023/e6daef68/attachment.htm

More information about the BEEPbuilders mailing list