RE: When can a BEEP peer send <close number='0'>

I think this is a bug in beepcore-c. Any peer receiving a "close" MUST
NOT reply with "ok", but can also reply with "error". The later, IMHU,
should be used as long as any other channels are open if the close
request is for channel 0. Thus, beepcore MUST NOT allow to close channel
0 in the case you describe.

Rainer 

> -----Original Message-----
> From: Lei Zhang [mailto:[email protected]] 
> Sent: Thursday, February 19, 2004 11:17 PM
> To: [email protected]
> Subject: [BEEPwg] When can a BEEP peer send <close number='0'>
> 
> RFC 3080 section 2.3.1.3 clearly specifies when a BEEP peer 
> may send a 
> "close" message for a channel, but the RFC isn't quite clear 
> about when 
> a BEEP peer may send <close number='0'>.  I''m asking this 
> because I run 
> into a problem with beepcore-c: peer A sends <close 
> number='0'> after it 
> receives <close number='1'> but before it acknowledges the 
> channel close 
> request; and peer B releases all channel on seeing <close 
> number='0'>, 
> then it sees the <ok> for the <close number='1'> request it 
> sent out and 
> core dumps while trying to reference channel 1.  This does 
> not look like 
> 100% implementation issue - the RFC can be more affirmative on this?
> 
> Thanks..
> 
> 
> 
> _______________________________________________
> BEEPwg mailing list
> [email protected]
> http://lists.beepcore.org/mailman/listinfo/beepwg
>