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/siacs/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 _______________________________________________
