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

Arc Riley arcriley at gmail.com
Thu Nov 9 19:10:17 UTC 2017


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.

Beyond that, I'd think any XEP on the MTI list should be standards track,
not historical.


On Wed, Nov 8, 2017 at 11:57 PM, Florian Schmaus <flo at geekplace.eu> wrote:

> On 09.11.2017 02:07, Arc Riley wrote:
> > Since XEP-0114 is historical and its purpose predates SRV records, I'm
> > wondering why it was included in the suite for server compliance?
>
> Because it is still the de-facto standard how you plug in external
> components into your XMPP server. :)
>
> And what do you mean with "purpose predates SRV records"?
>
> XEP-0114 components can be used with SRV records. If you want the
> component to be accessible by other XMPP servers, you just point the
> components _xmpp-server SRV record to the s2s port of your XMPP server.
> At least that is how I remember it to work.
>
> I'm not sure what a new XMPP component protocol should do
> different/better wrt. SRV records?
>
> - Florian
>
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171109/53bd1ab8/attachment.html>


More information about the Standards mailing list