I recall Ralph once noted that many of the major XEPs were each the third try at the concepts. So here's hoping for components v3 :)
The motivation for using __xmpp-component as a "domain" name is unclear to me, but I'm probably lacking the imagination at the moment to create the enlightening example. (It also makes me want to reserve an actual domain name for this use case like how we use bob.xmpp.org in XEP-0231, but that is probably a bad idea.) Can a component establish S2S sessions with multiple host servers? This might seem odd in the context of most existing component implementations, but the proposed XEP is essentially allowing an XMPP server to act as a connection manager for another server using S2S. So I can easily imagine the "component" to be a true XMPP service (that could typically handle multiple S2S sessions), and the "host" servers acting as connection managers. Maybe an implementation note? Can a component create or accept S2S sessions to non-host servers? I would expect the answer to be no (what's the point of having the host server then?), but it isn't called out. Overall, I like the idea. I also would be very interested in any attempts (or past ones) to define things in reverse: connection managers that can sit in front of any traditional XMPP server, and thus any S2S-style component, implementation. — Lance
smime.p7s
Description: S/MIME cryptographic signature
