Thanks Daniel! I've updated the XEP once more to do exactly what you proposed. The current version can be found at [1] and the diff to v0.3.1 is at [2]. Since, by the lack of other feedback, this seems to be ready, I've created PR #1268 at [3].
I've also added a new <ringing/> element so you don't have to use message- receipts to fake this ;) -tmolitor [1] https://dyn.eightysoft.de/final/xep-0353.html [2] https://dyn.eightysoft.de/final/jmi_diff.html [3] https://github.com/xsf/xeps/pull/1268 Am Donnerstag, 26. Januar 2023, 08:23:32 CET schrieb Daniel Gultsch: > What ever you do please don’t rename the <proceed/> and <accept/> > elements. Proceed should continue to be the 'main' element that tells > the initiator to proceed with the jingle handshake. Anything else will > just be a nightmare to talk about because you would always have to > specific if you are talking about version 0.3 <accept/> or version 0.5 > > Assuming this semantic I think they are generally three possible > options on what to do with the (now obsolete) <accept/> > > 1) Keep sending it in a separate message addressed to your own devices > 2) Simple don’t send it > 3) Send accept and proceed in one message > > I think we can agree that (2) would be the cleanest solution if we > weren’t worried about backward compatibility. > (1) would undeniably offer the best backward compatibility as this is > what most implementations currently do. So the question is does (3) > actually offer sufficient backward compatibility: The <accept/> will > be addressed to the wrong address so any pedantic implementation will > just discard it[1]. Having two JMI elements in one message is also > highly unusual and I bet that a lot of implementations will just parse > one of them. > > Assuming that (3) won’t perfectly do what you hope it does I’m > advocating for a mix of (1) and (2) with (2) being the ultimate goal. > I think parsing the carbon copied proceed is a relatively minor change > that implementations can ship as a 'bug fix' of sorts. In fact > Conversations already does parse the carbon copied <proceed/>. A > device that keeps ringing sounds like something one could tolerate for > a short migration period. > > Besides nobody stops you from sending the accept (with a no-store) > hint for a migration period while advocating for other clients to rely > on the carbon copied proceed. That’s what I mean by 'mix of (1) and > (2)'. (2) don’t send it is what the XEP says. (1) is what some clients > might do for a migration period. But those client will be 'wrong' and > will require minor fixing. > > cheers > Daniel > > [1]: > https://github.com/iNPUTmice/Conversations/blob/master/src/main/java/eu/sia > cs/conversations/xmpp/jingle/JingleRtpConnection.java#L1371 > On Wed, Jan 25, 2023 at 10:22 PM Thilo Molitor <th...@eightysoft.de> wrote: > > Am Mittwoch, 25. Januar 2023, 17:12:06 CET schrieb Daniel Gultsch: > > > I'd get rid of <accept/> instead of <proceed/> > > > > > > Only put <proceed/> into the stanza. Don’t send <accept/> at all. > > > > > > Stops you from having to put two elements in the message. > > > > > > What in the :0 version was <accept/> will just quietly go away. (In > > > favor of wording around proceed being carbon copied) > > > > But clients implementing the old :0 version won't stop ringing if I accept > > the call on a device on the same account implementing the new :0 version, > > no? > > > > -tmolitor > > > > > On Wed, Jan 25, 2023 at 3:49 AM Thilo Molitor <th...@eightysoft.de> wrote: > > > > As discussed in the XSF MUC, I've updated XEP-0353 to use the old :0 > > > > namespace, but still incorporate all features of the :1 namespace. > > > > I had to water down some MUST of :1 to SHOULD to accomplish this. > > > > I've also merged the <accept/> and <proceed/> elements into the same > > > > message stanza in order to maintain backwards compatibility without > > > > introducing yet another stanza stored into MAM etc. > > > > > > > > Please read this carefully to check if I did not miss anything still > > > > mandating a namespace bump. > > > > > > > > Rendered version: https://dyn.eightysoft.de/final/xep-0353.html > > > > Diff to the old :0 version 0.3.1: > > > > https://dyn.eightysoft.de/final/jmi_diff.html > > > > > > > > The commit can be found in the following branch, I'm happy to take > > > > pull > > > > requests fixing stuff I've missed: > > > > https://github.com/tmolitor-stud-tu/xeps/tree/jmi0 > > > > > > > > -tmolitor > > > > > > > > > > > > > > > > _______________________________________________ > > > > Standards mailing list > > > > Info: https://mail.jabber.org/mailman/listinfo/standards > > > > Unsubscribe: standards-unsubscr...@xmpp.org > > > > _______________________________________________ > > > > > > _______________________________________________ > > > Standards mailing list > > > Info: https://mail.jabber.org/mailman/listinfo/standards > > > Unsubscribe: standards-unsubscr...@xmpp.org > > > _______________________________________________ > > > > _______________________________________________ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
