On 19 Nov 2014 05:00, "Kurt Zeilenga" <[email protected]> wrote: > > >> On Nov 18, 2014, at 2:27 PM, Dave Cridland <[email protected]> wrote: >> >> >> On 18 Nov 2014 20:21, "Kurt Zeilenga" <[email protected]> wrote: >> > >> > Another comment... >> > >> > RFC 6120 requires XMPP servers to provide "in-order processing" as described in 10.1. Delegating the stanza to another does not vacate this requirements and have this delegation be transparent to the originators of the forwarded stanzas. And the desired transparency means the forwarding entity basically has to block processing of any stream of stanzas its processing for the component to answer. And this, I think, makes the this extension significant less desirable. >> > >> >> The RFC only says that further input needs to suspended in the case where the traffic being processed has effect on subsequent traffic processing. >> >> > > And how would a server, developed independently of the components it has to interoperate with, supporting arbitrary namespace delegation know what traffic processing done by the component has effect on subsequent traffic processing? >
Obviously the traffic processing of the component alters based on previous traffic it handles, and that doesn't matter here. To affect the traffic processing of the server the component would have to issue commands back to the server, such as privacy lists or blocking. These can be easily enough warned about (or blocked) in some cases, but I agree that there may be other cases - particularly when we consider the interaction between this and the other protoXEP on the table. But the best defense we have is probably to simply note this issue in the specification - it's really no different to a server mangling the ordering of stanzas to a client or other server, after all. Of course, we could also embed the details in the protocol, so a component may request delegation and also request blocking, and when forwarding stanzas, a server indicated blocking status, and the component can "unblock" the server. It's not ideal, but at least it would allow the case to be covered. I certainly wouldn't want all delegated traffic to cause blocking. Dave.
