[Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

Dave Cridland dave at cridland.net
Wed Nov 15 09:28:06 UTC 2017


On 15 November 2017 at 08:59, Ruslan N. Marchenko <me at ruff.mobi> wrote:
>
>
> On 14.11.2017 22:37, Sam Whited wrote:
>>
>>
>> What do the server devs here think?
>>
>>
> To be fair this protocol is implemented in majority(?) of existing xmpp
> server implementations so the burden is zero.
> The question is rather - what is the future vision for this component
> protocol? It considered as a necessary communication method for new external
> services or s2s with all the new features (like bidi) is sufficient making
> this one redundant. My personal answer is - go S2S. But at the same time i'm
> not doing much of component development therefore cannot say whether
> XEP-0114 is really resolving some corner cases hence being irreplaceable.

Having written Metre, which implements *only* S2S and '114, I can tell
you it's not straightforward. I've just spent a couple of weeks on
Openfire's implementation to remove a bug there, too, and I've worked
on other implementations as well - bugs are tricky to find, the edge
cases are many, authentication is a tricksy nightmare. If I were
writing a standalone XMPP service now, I wouldn't want to write
(another) S2S implementation - I'd want to just connect using a
lightweight protocol and have the server to do heavy lifting.

I did propose, as part of this work, a component protocol based on
profiling S2S with mandatory Bidi in order to replace '114, but
Council rejected this:

https://xmpp.org/extensions/inbox/s2s-components.html

Dave.


More information about the Standards mailing list