[Standards] Re: Proposed XMPP Extension: Jingle Remote Control

Hi Goffi, Before going on your specific points, I'd like to make clear that I'm all in favor of this happening and this vote was very uneasy to me, because I also don't want to discourage you. I still do think that this XEP is bad for many reasons, some of which I apparently fail to get across, so I'll try to make it more explicit and to the point in this email. On Mon, 2024-05-27 at 10:54 +0200, Goffi wrote: One major criticism is that it specifies TWO protocols.  The first protocol (sections §5-7 of your proposal), which clearly belongs into the XSF, is how to use Jingle to signal a remote desktop session. As you rightly point out a Jingle application format (as per XEP-0166 §12.1) must DEFINE how the "media data" is sent. However, it doesn't need to SPECIFY the media data format. E.g. XEP-0167 defines you should use RTP packets as specified in RFC3550. The second protocol (sections §8-9) is the one that is the media data to send via the Jingle session. However that protocol is largely independent of Jingle or anything else and could be and IMO better would be specified entirely independent of that. When I said that you should consider to evaluate if a XEP is the right place to specify such a protocol, I was only referring to this part: As it stands right now, this second protocol could easily be used independent of XMPP and Jingle. I would thus see this protocol more as an RFC. Under the assumption that all remote control signals are sent using <message> and it is up to the receiving client to decide to accept or error them, there is no additional complexity introduced, by adding the possibility of a different transport path. In fact, you wouldn't even need to specify which transport path to use, you specify the stanzas to be sent to do remote control (to maintain remote control session and for input events). The fact that one decides to send those via Jingle XML streams and others use serverless messaging doesn't need to be specified, it's exactly the same stanzas being sent in both cases. Except that many clients are not meant to be advanced IM clients. I wouldn't expect a remote desktop application to strictly also be an advanced IM client. Looking at the feature set we require from advanced IM clients, I'm pretty sure most existing remote desktop apps do not qualify as advanced IM client (probably not even core im client, because group chats are definitely not common for remote desktop apps). Again, You seem to be coming from the position that a client implementing this is already a very feature rich and advanced client like yours, but this assumption comes with a huge amount of restrictions. This does not match my understanding of Council work. I see Council as clearly a technical position, not a mostly organization position. In fact, some of the tasks you listed are clearly on the Editor side and shouldn't even reach Council (e.g. copyright issues and offensive content). We do have a Council of multiple members, because Council work is not solely fact-based, but also involves individual opinions of its members. If approving a XEP for publication was exactly following a checklist of well-defined points, we wouldn't need the Council for it. I do agree that Jingle can likely be implemented on any platform, but it might be that you can only do so using Jingle IBB (e.g. because your network controller can only maintain a single TCP connection), in which case using Jingle is really not an improvement. I'm pretty sure you can't send absolute pointing events (via NotifyPointerMotionAbsolute like for a drawing tablet) or touch motion events (via NotifyTouchMotion) using the RemoteDesktop portal without also opening a screen cast, because the PipeWire stream node of the screen cast is a parameter for those APIs. So while some events can be sent without the Screen Sharing, it's not entirely optional. The RemoteDesktop portal clearly ties it to the pointer device, it's not only that the name is NotifyPointerAxis but you also must request a POINTER device in the session (i.e. only requesting a KEYBOARD and TOUCHSCREEN device does not allow you to use the API for scrolling). I know we have EXI and I know basically nobody implements it. It's very complex, has a lot of features and for best results requires to agree on a common set of XML schemas. Having something else than EXI that is easier to implement really might be a good idea, because I doubt EXI is going to ever be successful. -- So as a summary, for me the deal breaker really is the two protocols in one XEP, one of which is not really an XMPP protocol. If you do like the two protocols that you built - after all, you have implementation experience that I entirely lack, so it may be that all my concerns are invalid and I'm happy to have that in Experimental - I just feel that the second one should best not be at the XSF and if there's really no better place, make it at least a separate XEP. Marvin PS: I also firmly believe that splitting those two protocols will make the protocol design better, because you can't (or at least are less likely to) have weird interaction between unrelated protocols anymore.