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. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
