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 <f...@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-unsubscr...@xmpp.org > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
