Re: [Standards] PR #793 - XEP-0166: Relax transport element requirement
My review of the PR is that, although I agree entirely with the sentiment, this change would be breaking, and by itself is not worth the namespace fracturing. Looking at Jingle code I currently have deployed in production systems, the expectation that a session or content accept action includes a transport element is present, and this change would trigger bad-request errors. Generating and sending an “empty answer” transport element (for whatever an empty answer would look like for the transport in question) is the cleanest solution that still works in the existing namespace. I would prefer not sending the element at all, but again, not worth the namespace bump for such a minor detail. /Lance ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] PR #793 - XEP-0166: Relax transport element requirement
I agree. The empty transport elements is one of the approaches. I thought about it. But then I thought "if every transport may declare it's own set of obligatory transport attributes then why should I parse transport elements at all figuring out whichi attributes are required and which not if it doesn't bring any value and some other jingle action already allow the absence of the transport element". Best Regards, Sergey ср, 26 июн. 2019 г. в 13:43, Philipp Hancke : > Am 22.06.19 um 17:18 schrieb Sergey Ilinykh: > > In response to Council Minutes 2019-06-19 > > > > quote from > > > https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method > > > > > > Another problem with early (before accept) transport replace is the fact > we > > have to send the same offer twice. For example we have S5B and IBB. The > > lousy s5b implementation can only gather s5b proxy candidates so it may > > fail before we sent initial offer (session/content accept). So after > proxy > > discovery failure we may want to send transport-replace request to IBB > > which will contain everything needed for IBB negotiation (at least block > > size). Then we have to repeat transport offer with session/content-accept > > which will force the remote party to reinitialize IBB transport what > looks > > like a bad practice, which may be even worse with other transports. To > make > > things right it has to be allowed to send session/content-accept without > > transport element if it was accepted earlier. > > > > To solve this we have https://github.com/xsf/xeps/pull/793 but may be it > > require more actions. > > Let's discuss. > > Moving over from github. Peter, Lance and me looked at a very similar > case back in 2015, fallback from ice-udp to raw-udp. It also does a > transport-replace before session-accept. > >https://xmpp.org/extensions/xep-0371.html#fallback > has the full protocol flow. Its a bit unclear to me now why Romeo would > send a ice-udp transport to the gateway which is unlikely to announce > this in disco... (which I assume is the way to pick the transport even > though 0166 is silent here) > > > We kept this within the current jingle specification by including an > empty namespaced > > in the session-accept (example 15) which basically says "reminder: we > agreed on this transport, hopefully you remember the details". > > For IBB I would recommend a similar thing but keeping the sid attribute, > the initiator can then verify that this refers to an already active > session that does not need to be reinitialized. > > (I just hope we're using this pattern consistently...) > > cheers > > Philipp > (and thanks for the poke Dave!) > ___ > 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 ___
Re: [Standards] PR #793 - XEP-0166: Relax transport element requirement
Am 22.06.19 um 17:18 schrieb Sergey Ilinykh: In response to Council Minutes 2019-06-19 quote from https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method Another problem with early (before accept) transport replace is the fact we have to send the same offer twice. For example we have S5B and IBB. The lousy s5b implementation can only gather s5b proxy candidates so it may fail before we sent initial offer (session/content accept). So after proxy discovery failure we may want to send transport-replace request to IBB which will contain everything needed for IBB negotiation (at least block size). Then we have to repeat transport offer with session/content-accept which will force the remote party to reinitialize IBB transport what looks like a bad practice, which may be even worse with other transports. To make things right it has to be allowed to send session/content-accept without transport element if it was accepted earlier. To solve this we have https://github.com/xsf/xeps/pull/793 but may be it require more actions. Let's discuss. Moving over from github. Peter, Lance and me looked at a very similar case back in 2015, fallback from ice-udp to raw-udp. It also does a transport-replace before session-accept. https://xmpp.org/extensions/xep-0371.html#fallback has the full protocol flow. Its a bit unclear to me now why Romeo would send a ice-udp transport to the gateway which is unlikely to announce this in disco... (which I assume is the way to pick the transport even though 0166 is silent here) We kept this within the current jingle specification by including an empty namespaced in the session-accept (example 15) which basically says "reminder: we agreed on this transport, hopefully you remember the details". For IBB I would recommend a similar thing but keeping the sid attribute, the initiator can then verify that this refers to an already active session that does not need to be reinitialized. (I just hope we're using this pattern consistently...) cheers Philipp (and thanks for the poke Dave!) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] PR #793 - XEP-0166: Relax transport element requirement
In response to Council Minutes 2019-06-19 quote from https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method Another problem with early (before accept) transport replace is the fact we have to send the same offer twice. For example we have S5B and IBB. The lousy s5b implementation can only gather s5b proxy candidates so it may fail before we sent initial offer (session/content accept). So after proxy discovery failure we may want to send transport-replace request to IBB which will contain everything needed for IBB negotiation (at least block size). Then we have to repeat transport offer with session/content-accept which will force the remote party to reinitialize IBB transport what looks like a bad practice, which may be even worse with other transports. To make things right it has to be allowed to send session/content-accept without transport element if it was accepted earlier. To solve this we have https://github.com/xsf/xeps/pull/793 but may be it require more actions. Let's discuss. Best Regards, Sergey ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
