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 <adam@nostrum.com> 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:
> 
> 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.
> 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)
> 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
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis