[Standards] Proposed XMPP Extension: Zero Handshake Server to Server Protocol
dave at cridland.net
Tue Jul 14 15:31:09 UTC 2015
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
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='bob at nato.example' from='alice at mod.example' type='chat'
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 '
(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
On 14 July 2015 at 15:35, Steve Kille <steve.kille at isode.com> 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
> > -----Original Message-----
> > From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of XMPP
> Extensions Editor
> > Sent: 14 July 2015 14:31
> > To: standards at xmpp.org
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards