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'/>
</query>
</iq>
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
implementations...
Cheers
Goffi
On 19/11/2014 14:01, Kurt Zeilenga wrote:
On Nov 19, 2014, at 1:22 AM, Dave Cridland <[email protected]
<mailto:[email protected]>> 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
