[Standards] Proposed XMPP Extension: namespace delegation

Goffi goffi at goffi.org
Thu Nov 27 09:08:08 UTC 2014

Hi Kurt,

Indeed the in-ordeing could be an issue in some particular cases, but 
should not in the majority of cases.

We have different options, has mentionned by Dave:

	- (1) just mention it in implemention note, the server could decide to 
ignore or wait for the answer for a list of namespaces it manage, that's 
not ideal but easy.

	- (2) add an attribute while requesting delegation "e.g. 
blocking='true'", that would give something like:

<iq from='managing.capulet.lit' type='get' id='delegation1'>
     <query xmlns='urn:xmpp:delegation:0' type='request' delegation='admin'>
         <delegate namespace='urn:xmpp:blocking' blocking='true'/>

with some specifications about timeout etc. That's would complicate a 
bit the specification, but it's doable. In admin mode it's actually 
quite easy, but in client mode it's more tricky.

	- (3) forbid that case, just say that blocking XEPs are not allowed 
with delegation, and in-ordering can't be preserved.

I think nobody wants a managing entity to block all the traffic.
In my opinion, (1) (a simple mention in implementation notes) is OK for 
now, and we'll see if (2) or (3) are necessary after the first 


On 19/11/2014 14:01, Kurt Zeilenga wrote:
>> On Nov 19, 2014, at 1:22 AM, Dave Cridland <dave at cridland.net
>> <mailto:dave at cridland.net>> wrote:
>> I certainly wouldn't want all delegated traffic to cause blocking.
> Neither do I... I just worry about breaking the in-ordering requirement
> and the ramifications from doing so.  Maybe the only ramification will
> be some protocol weenie submitting a bug report to implementor of this
> and like extensions.
> In our "iq delegation" implementation, we never block.  But we're only
> generally only delegating stanzas for vendor-specific application where
> the vendor is in control of both the client and the component using the
> delegated namespace.
> An issue we did consider was IQ handling, in particular, should the
> server track forwarded "get"/"set" and if the component doesn't respond
> in a timely manner, provide the client with an appropriate "error" and,
> of course, don't forward the "result"/"error" the component might
> subsequently provide.
> Presently we're interceding where the component fails to provide a
> timely response... but I'm thinking this is a bad thing, at least in our
> use case.  The interceding is likely to break the application which is
> relying on the delegation.   But with more some widely used name spaces,
> maybe interceding is a good thing.
> -- Kurt

More information about the Standards mailing list