[Standards] Proposed XMPP Extension: namespace delegation
dave at cridland.net
Tue Nov 18 22:27:06 UTC 2014
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 processing.
There are cases where such effect is possible, for example handing XEP 191
traffic via delegation a server supporting privacy lists, but should just
say these are illegal.
Specifically, the pep example wouldn't need any ordering considerations.
> I think any spec providing for such delegation needs to provide some
discussion of how the in-order processing requirements of RFC 6120 are
fulfilled . At a minimum, text which calls attention to the in-order
processing requirements and clearly states the delegating server MUST still
abide them ought to be incorporated into the spec.
> -- Kurt
> PS: I would love to lift the "in-order processing" requirement generally,
but it's way too late to do that, me thinks.
> > On Nov 18, 2014, at 7:37 AM, XMPP Extensions Editor <editor at xmpp.org>
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> > Title: namespace delegation
> > Abstract: This specification provides a way for XMPP server to delegate
treatments for a namespace to an other entity
> > URL: http://xmpp.org/extensions/inbox/namespace-delegation.html
> > The XMPP Council will decide in the next two weeks whether to accept
this proposal as an official XEP.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards