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

Hi,

For some reason I missed the text Adam referred to. 

Now assuming we would remove the possibility to act as both client and server, for backward compatibility, perhaps we should still allow c-s in the offer, but only allow c-only and s-only in the answer? That way, the semantics of c-s in an offer would not matter, because the sender would always end up as client or server.

Regards,

Christer

-----Original Message-----
From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 12 September 2018 10:32
To: bfcpbis@ietf.org
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue

On 9/11/18 9:37 PM, Adam Roach 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.

ISTM that to go this way the document should be returned to the WG. It seems like too big a change to do otherwise.

> 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
> 

_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org
https://www.ietf.org/mailman/listinfo/bfcpbis