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.
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.
> 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")
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).
In example 7, after catching the stanza, the server forward it with its
own "from" and the original id ("pep1"), so the client doesn't notice
anything, and the "from" attribute is good (it's "capulet.lit", not
"pubsub.capulet.lit"), client can check it without problem.
cheers
Goffi
