> On Nov 18, 2014, at 2:27 PM, Dave Cridland <[email protected]> wrote: > > > On 18 Nov 2014 20:21, "Kurt Zeilenga" <[email protected] > <mailto:[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?
