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.
