Re: [bfcpbis] Out-of-sequence or unexpected FloorRequestSatus messages

I just noticed that section 6.2 partially covers the issue I described in my previous mail. The second last paragraph says:

   "A server-initiated request (e.g. a FloorStatus with an update from
   the floor control server) received by a participant before the
   initial FloorRequestStatus message that closes the client-initiated
   transaction that was instigated by the FloorRequest MUST be treated
   as superseding the information conveyed in any delinquent response."

However, this does not resolve the problem of the unknown Floor Request ID - it may or may not be the one also contained in the late FloorRequestStatus that terminates the client-initiaed FloorRequest transaction. If it is the same the sentence above is correct, but if it is not then there is some state misalignment between server and client that needs sorting out.

Thanks,
Ernst

> -----Original Message-----
> From: bfcpbis-bounces@ietf.org 
> [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Horvath, Ernst
> Sent: Dienstag, 24. Juli 2012 16:40
> To: bfcpbis@ietf.org
> Subject: [bfcpbis] Out-of-sequence or unexpected 
> FloorRequestSatus messages
> 
> A point still missing from the rfc4582bis draft is the 
> handling of an out-of-sequence or unexpected 
> FloorRequestStatus message. 
> 
> An out-of-sequence FloorRequestStatus can occur if a 
> participant has sent a FloorRequest and the first response 
> from the server is lost or overtaken by the next 
> FloorRequestStatus with a different Transaction ID. In this 
> case the client does not yet know the Floor Request ID 
> assigned by the server and cannot determine whether or not 
> the received status message corresponds to the pending FloorRequest. 
> 
> The best way to cope with this situation seems to be that the 
> client ignores any FloorRequestStatus with an unknown Floor 
> Request ID while still waiting for the first response to a 
> FloorRequest the client has sent. Message retransmissions 
> from both sides should eventually sort out the situation. If 
> this is an acceptable solution then corresponding text should 
> be added, e.g. in section 10.1.3.
> 
> Another situation is the receipt of an unexpected 
> FloorRequestStatus, i.e. one that does not fit any Floor 
> Request ID the client is aware of, and the client has no 
> outstanding FloorRequest transaction waiting for the initial 
> response. Possible reactions could be to respond with 
> FloorRequestStatusAck or to send Goodbye. The client could 
> also try to resynchronise its state information, e.g. via 
> UserQuery or FloorQuery. In any case it seems worthwhile to 
> cover this situation in the draft, too.
> 
> BTW, the other "subscription-like" message pair, FloorQuery 
> and FloorStatus, shouldn't have this problem.
> 
> Regards,
> Ernst
> 
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis
> 