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

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

That works for me, and it aligns with what we did within IMTC.

Cheers,
Charles

-----Original Message-----
From: bfcpbis <[e-mail]> on behalf of Christer Holmberg <[e-mail]>
Date: Wednesday, September 12, 2018 at 12:22 PM
To: Paul Kyzivat <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: 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:[e-mail]] On Behalf Of Paul Kyzivat
    Sent: 12 September 2018 10:32
    To: [e-mail]
    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
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/bfcpbis
    > 
    
    _______________________________________________
    bfcpbis mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/bfcpbis
    _______________________________________________
    bfcpbis mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/bfcpbis