[Standards] Proposed XMPP Extension: Zero Handshake Server to Server Protocol

Joachim Lindborg joachim.lindborg at sust.se
Thu Jul 16 22:19:43 UTC 2015


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: Joachim.lindborg at sust.se
linkedin: http://www.linkedin.com/in/joachimlindborg
Tel +46 706-442270

2015-07-16 16:26 GMT+02:00 Steve Kille <steve.kille at isode.com>:

> Dave,
>
>
>
> I’ll look to address these points, once the XSF editing mechanics are
> sorted.
>
>
>
> Regards
>
>
>
> Steve
>
>
>
> *From:* Standards [mailto:standards-bounces at xmpp.org] *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='bob at nato.example' from='alice at mod.example' 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 <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
> this.
>
> Regards
>
>
> Steve
>
>
>
> > -----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...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150717/6ec5d7c0/attachment.html>


More information about the Standards mailing list