Subject: [bfcpbis] please review drafts prior to IETF 84

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 18 Jul 2012 18:42:04 +0000

I'd like to thank Tom for posting the updated versions of both drafts before the submission deadline:
http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/
http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/

Thanks as well to those who have already provided review comments. 
Please be sure to review and raise any open issues prior to IETF 84. We'd like to be able to address any outstanding areas/issues before and/or during the IETF 84, such that we can start WGLC on the drafts following IETF 84.
Currently, the draft agenda divides the majority of the time between the two drafts. If there are any significant open issues, I'd like to add them explicitly the agenda so as to make sure we make the best use of our working group session.

Cheers,
Charles (co-chair)

---

From: "Horvath, Ernst" <[email-masked]>
Date: Tue, 24 Jul 2012 14:40:06 +0000

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

---

From: "Horvath, Ernst" <[email-masked]>
Date: Wed, 25 Jul 2012 09:51:08 +0000

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Horvath, Ernst
> Sent: Dienstag, 24. Juli 2012 16:40
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>