Am 27.11.2014 um 00:32 schrieb Goffi:
G'day,Thanks for your feedback, and sorry for the late answer...Does this really have to use query + type=request? <request xmlns=urn:xmppp:delegation:0' delegation='admin'>Indeed, binary told me the same thing on a MUC, I'll remove it in the next revision.
fab.
How about reusing what we have in disco, i.e. <feature var='jabber:iq:roster'/>According to Dave answer, it's probably better to let it unchanged.
WFM.
> 4.2 Server Forwards Delegated <iq/> Stanza In one direction the stanza goes via the server Juliet -> capulet -> pubsub.capulet and in the other it goes directly to juliet pubsub.capulet -> Juliet and is also stamped with a from=pubsub.capulet. I think that's not going to work for cases where the client checks the from in addition to the iq id.Maybe I'm not well awake, but I think the example is alright: In example 4, Juliet send her mood normally, no "to" attribute so it go to capulet.lit (the server). In example 5 the server forward the stanza to pubsub.capulet.lit, note that the id has changed ("delegate1" versus "pep1")
Oh, I missed that id change. The text needs to be tweaked slightly to describe this actually "wraps" the iq response.
Protocol-wise, should the server change the from? See below. Some MUC implementations do the same for iq's between participants and that pattern seems to work quite well.
In example 6 pubsub.capulet.lit answer normally to the stanza *with the
second id* ("delegate1"), so it answer to pubsub.capulet.lit but the
server will catch it (the delagation is done by the server of juliet, so
the stanza necessarily go through capulet.lit).
<hat type=guy-who-wrote-two-servers>The stanza in the example is addressed to Juliets full JID. Which makes it harder for the server to intercept if stanzas addressed to full/bare JIDs don't go down the same code path. I wouldn't want to inspect any iq-result to the full JID and do a lookup for the response id. There might be efficient ways to do that however.
Changing this would require using the bare jid in example 5. That makes it easier for the server to receive the result (likewise addressed to the bare jid) and unwrap it. The downside is that the entity that gets the forwarded stanza receives it from the bare JID and can not determine the full JID of the sender.
Is it interested in that? Sometimes probably. Using XEP-0297 for wrapping seems to solve this. </hat>
