On 13 November 2017 at 23:50, Sam Whited <s...@samwhited.com> wrote: > On Mon, Nov 13, 2017, at 14:03, Arc Riley wrote: >> The question is whether a server implementation should be considered >> modern >> and complete if it does not implement XEP-0114, and I've made what I >> believe are strong arguments as to why XEP-0114 should not be considered >> mandatory. > > I could go either way on this; if anything I'm leaning slightly towards > removing it. However, so far everyone else seems to be in favor of > keeping it, is there anyone else in support of removing it?
I commented in xsf@ a while back, but to reiterate, I lean toward including it. I base my opinion on two assertions: 1) Every implementation of S2S (so every XMPP server plus Metre) also implements XEP-0114. Either it is utterly trivial to implement, or else it is desirable in the marketplace. Much of XEP-0387's purpose is to give a reasonable "shopping list" of what a new server developer should implement to be competitive, so if it's a desirable feature we should just go with that, and if it's trivial; to implement that there's no harm in doing so. One could argue, of course, that this is also evidence that if we do not include XEP-0114 in XEP-0387, it doesn't matter, because people "in the know" will implement it anyway. In which case, I'd be concerned with the point of XEP-0387 at all. 2) Interoperability and Interfaces. An XMPP Server has up to three interfaces to external systems. C2S, S2S, and Components. XEP-0387 does, of course, concentrate on C2S, but I see no particular reason why it should not also include S2S features and Component features. To a Client, or another Server, then Components are indeed the internal implementation issue that Arc says they are - but to the Server itself, or a Component of course, it's a rather different matter. I don't see there's the fundamental argument that Arc implies that Components are of lesser importance than other interfaces. To put things another way, it would be possible to implement an XMPP Server that doesn't do S2S. After all, to a Client, all domains aside from the home service look the same, right? Just an implementation detail. Obviously this would be a bizarre argument to make, and nobody is making it - it would be arguing that federation is an undesirable feature. I think Components are, similarly, a desirable part of the XMPP ecosystem, and we should support their existence. As a final note, however, I would be emphatically opposed to including any encouragement for "jabber:component:connect" - in fact, I think we should get rid of that from XEP-0114 entirely. Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
