[Standards] Proposed XMPP Extension: namespace delegation

Dave Cridland dave at cridland.net
Wed Nov 19 09:22:25 UTC 2014

On 19 Nov 2014 05:00, "Kurt Zeilenga" <kurt.zeilenga at isode.com> wrote:
>> On Nov 18, 2014, at 2:27 PM, Dave Cridland <dave at cridland.net> wrote:
>> On 18 Nov 2014 20:21, "Kurt Zeilenga" <kurt.zeilenga at isode.com> 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
> 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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141119/9f9b829b/attachment.html>

More information about the Standards mailing list