Being a noob in S2S I need to ask 2 things 1. if this also is applicable using EXI http://xmpp.org/extensions/xep-0322.html to greater lower the bandwith with EXI compression
2. Is there also a C2S zero handshake available (This is for smaller IoT devices)? *Regards* Joachim Lindborg CTO, systems architect Sustainable Innovation SUST.se Barnhusgatan 3 111 23 Stockholm Email: [email protected] linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270 2015-07-16 16:26 GMT+02:00 Steve Kille <[email protected]>: > Dave, > > > > I’ll look to address these points, once the XSF editing mechanics are > sorted. > > > > Regards > > > > Steve > > > > *From:* Standards [mailto:[email protected]] *On Behalf Of *Dave > Cridland > *Sent:* 14 July 2015 16:31 > *To:* XMPP Standards > *Subject:* Re: [Standards] Proposed XMPP Extension: Zero Handshake Server > to Server Protocol > > > > I think it's worth noting that low-bandwidth support is a key > differentiator for Isode's implementation, and so it's especially pleasing > to see this low-bandwidth binding of XML Streams be submitted for > standardization in this way. While I appreciate it's relatively niche, I > think it will benefit the community, and exemplifies the nature of the > community's relationship with industry, and our common desire for open > standards. > > > > Non-blocking comments follow: > > > > With this specification as written, what happens is, roughly, that a TCP > session is opened and then XML fragments sent "as if" a stream open had > been sent, something like: > > > > <message to='[email protected]' from='[email protected]' type='chat' > id='foo'><body>Hi!</body></message> > > <stream:error>...</stream:error> > > > > Two questions: > > > > 1) What defines what the default namespace is? (I think it's mandatorily > defined as 'jabber:server') > > > > 2) When a stream is closed, should a close tag be exchanged? (I suspect > yes, for all the reasons given in XEP-0190) > > > > 3) What defines what the stream prefix means? (I think it's fixed as ' > http://etherx.jabber.org/stream') > > > > (1) and (3) can be specified as being due to an unsent <stream:stream > xmlns:stream='...' xmlns='...'> tag, or by configuration. I'd prefer to fix > the prefixes used, and minimize their use (ie, maybe require that stream > errors should be explicitly namespaced). > > > > It's tempting, as a result, to define more, such as XEP-0198's namespace > for use with <r/> and <a/> elements, but this is rapidly increasing the > complexity of the approach. > > > > An alternate design (changing the wire protocol) would be to send, > pipelined, the stream-open, which XML namespaces properly defined. I think > this is the most flexible approach, but I appreciate that accurately > defining what has been implemented is the right first step. > > > > Bandwidth constraints for the deployment of this protocol suggest we want > to avoid explicitly namespacing elements if we can avoid it, so the > approach used in the WebSocket binding, for example, is likely > inappropriate. > > > > > > On 14 July 2015 at 15:35, Steve Kille <[email protected]> wrote: > > Let me give a bit more background on this proto-XEP. > > We (Isode) have been involved with a number of systems operating over very > high latency (several second) slow and flakey links. > Using standard XMPP over these links is barely useable - many minutes to > establish communications. > > The approach here of eliminating server to server handshakes has been > implemented and tested in a number of UK and NATO trials. > > It seems desirable to make this useful approach available as a XEP. NATO > are keen to see this happen, and I prefer to avoid > proprietary approaches. > > This proto-XEP writes up what we implemented. I'd welcome any input on > this. > > Regards > > > Steve > > > > > -----Original Message----- > > From: Standards [mailto:[email protected]] On Behalf Of XMPP > Extensions Editor > > Sent: 14 July 2015 14:31 > > To: [email protected] > > Subject: [Standards] Proposed XMPP Extension: Zero Handshake Server to > Server Protocol > > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Zero Handshake Server to Server Protocol > > > > Abstract: > > This specification defines an approach for a pair of servers to > eliminate initial handshakes and associated > > data transfer when using the XMPP S2S Protocol. This approach may > only be used with a priori agreement and configuration > > of the two servers involved. This is of significant benefit in high > latency environments. > > > > > > URL: http://xmpp.org/extensions/inbox/optimized-s2s.html > > > > The XMPP Council will decide in the next two weeks whether to accept > this proposal as an official XEP. > > >
