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

Dave Cridland dave at cridland.net
Tue Nov 14 08:35:36 UTC 2017

On 13 November 2017 at 23:50, Sam Whited <sam at samwhited.com> wrote:
> On Mon, Nov 13, 2017, at 14:03, Arc Riley wrote:
>> The question is whether a server implementation should be considered
>> modern
>> and complete if it does not implement XEP-0114, and I've made what I
>> believe are strong arguments as to why XEP-0114 should not be considered
>> mandatory.
> I could go either way on this; if anything I'm leaning slightly towards
> removing it. However, so far everyone else seems to be in favor of
> keeping it, is there anyone else in support of removing it?

I commented in xsf@ a while back, but to reiterate, I lean toward
including it. I base my opinion on two assertions:

1) Every implementation of S2S (so every XMPP server plus Metre) also
implements XEP-0114.

Either it is utterly trivial to implement, or else it is desirable in
the marketplace. Much of XEP-0387's purpose is to give a reasonable
"shopping list" of what a new server developer should implement to be
competitive, so if it's a desirable feature we should just go with
that, and if it's trivial; to implement that there's no harm in doing

One could argue, of course, that this is also evidence that if we do
not include XEP-0114 in XEP-0387, it doesn't matter, because people
"in the know" will implement it anyway. In which case, I'd be
concerned with the point of XEP-0387 at all.

2) Interoperability and Interfaces.

An XMPP Server has up to three interfaces to external systems.  C2S,
S2S, and Components. XEP-0387 does, of course, concentrate on C2S, but
I see no particular reason why it should not also include S2S features
and Component features. To a Client, or another Server, then
Components are indeed the internal implementation issue that Arc says
they are - but to the Server itself, or a Component of course, it's a
rather different matter. I don't see there's the fundamental argument
that Arc implies that Components are of lesser importance than other

To put things another way, it would be possible to implement an XMPP
Server that doesn't do S2S. After all, to a Client, all domains aside
from the home service look the same, right? Just an implementation
detail. Obviously this would be a bizarre argument to make, and nobody
is making it - it would be arguing that federation is an undesirable
feature. I think Components are, similarly, a desirable part of the
XMPP ecosystem, and we should support their existence.

As a final note, however, I would be emphatically opposed to including
any encouragement for "jabber:component:connect" - in fact, I think we
should get rid of that from XEP-0114 entirely.


More information about the Standards mailing list