[Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)
flo at geekplace.eu
Thu Nov 9 20:30:49 UTC 2017
On 09.11.2017 20:10, Arc Riley wrote:
> Correct me if I'm wrong, but I remember the primary purpose of component
> protocol was to multihome gateways and other services (eg, MUC) on a
> single XMPP server which bound to the S2S port. Without this, you'd
> either need an XMPP reverse proxy (which component protocol almost is,
> almost) or one IP address per service you wanted to host.
> SRV records allow each service to be bound to a different port,
> eliminating the need for a single server to proxy S2S connections to
> respective services. This implementation detail should have zero nominal
> impact on either clients or S2S, lack of it as a feature would only
> impact sysadmins trying to run XMPP components.
Ahh, now I understand what you mean.
But I feels like you are arguing that because we have SRV records, a
component protocol is no longer required. I wouldn't come to that
conclusion. A component protocols allows components to piggyback on the
s2s capabilities of the XMPP server. And s2s is not trivial to implement
(Dialback, SASL EXTERNAL, possibly BIDI, …). Therefore a component
protocol allows developers to focus on the implementation of the
component's actual task.
> Beyond that, I'd think any XEP on the MTI list should be standards
> track, not historical.
I don't care which track it is on in this case. It just formalism. Fact
is, if you would implement a new XMPP server without xep114, you would
miss a lot of fun.
I'd rather focus on getting a successor, possibly xep0255, out of the
door. And if we see that major components (spectrum2 comes to my mind)
and servers support the successor, we could consider removing xep0114
from the compliance suite. But not before that has happened.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 642 bytes
Desc: OpenPGP digital signature
More information about the Standards