[Standards] Proposed XMPP Extension: namespace delegation
fippo at goodadvice.pages.de
Thu Nov 27 19:23:05 UTC 2014
Am 27.11.2014 um 00:32 schrieb Goffi:
> 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
> 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).
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.
More information about the Standards