Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue

["Charles Eckel (eckelcu)" <[e-mail]>]

I am fine with this approach as well.

Cheers,
Charles

From: Alan Ford <[e-mail]>
Date: Wednesday, September 12, 2018 at 3:11 AM
To: Adam Roach <[e-mail]>
Cc: Christer Holmberg <[e-mail]>, Charles Eckel <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue

I would be entirely happy with Adam’s suggestions here. c-s is an abomination that I’d be very pleased to see removed from the spec.

Regards,
Alan


On 12 Sep 2018, at 02:37, Adam Roach <[e-mail]<mailto:[e-mail]>> wrote:

On 9/11/18 5:17 PM, Christer Holmberg wrote:

Hi,



Based on my reading, an endpoint being both client and server is unclear even in 4582/4582bis. My understanding is that one endpoint acts as client and one endpoints acts as server. Of course, the roles can be re-negotiated, but at any given time an endpoint only has ONE role.



Or, have I missed something?

I think so. From §3:

   Furthermore, there are situations where both endpoints act as both

   floor control client and floor control server within the same

   session.  For example, in a two-party session that involves an audio

   stream and a shared whiteboard, one endpoint acts as the floor

   control server for the audio stream and the other endpoint acts as

   the floor control server for the shared whiteboard.

I note that this text exists in RFC 4583 as well, so this has conceptually been part of the protocol at least since its first publication. The way I read this, to implement the above-described scenario, both sides would negotiate a c-s role. Client A would send FloorRequest messages to Client B to ask for the audio floor, and Client B would send FloorRequest messages to Client A to ask for the whiteboard floor. This would all take place over the same BFCP stream.
Now, what I'm hearing you and Charles say is that this "both client and server" behavior was under-specified in RFC 4582, and so the RFC 4583 behavior was consequently mis-implemented, with implementations failing to distinguish between "c-only, s-only" and "c-s" (which, based on my description above, would mean radically different things from each other); and that the confusion here was so profound that an external consortium has issued its own guidance that effectively deprecates the original meaning of "c-s" altogether.
All of which tells me that the behavior described by the paragraph I quote above is not used in the field, apparently not useful, and too confusing to understand; on top of which, IMTC has salted the ground even if we wanted to clarify meanings and procedures surrounding "c-s".
My suggestion, then, is:
1.       Remove the above quoted paragraph, replacing it with text that clarifies that one peer must be a server for all streams or a client for all steams.
2.       Explicitly deprecate the use of "c-s," with a note that some implementations are known to treat it as identical to "c-only, s-only" (and make the text otherwise consistent on this point; e.g., in §10 and its subsections)
3.       Update the examples to match.
Another alternative would be to add clarification about how to implement the scenario I quote above (I think you'd get a lot of mileage by simply adding the word "simultaneously" to the end of the description of "c-s" in §5.1, which was clearly the original intention), clarify §7.1 to indicate who re-establishes connections for "c-s" relationships, pull RFC4582bis out of the RFC Editor queue and fix it so it specifies how to act as both a client and a server over a single BFCP stream, and ignore the fact that the IMTC guidance will lead to incompatibilities anyway. This approach seems like a lot more work to clarify a feature that no one apparently uses or wants, so I would not recommend it.
/a
_______________________________________________
bfcpbis mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bfcpbis