So I read this, expecting to see one protocol, and to my surprise found a completely different one.
I suspect Section 4.1 is entirely unnecessary - a component either needs admin rights or doesn't, and this would be provisioned within the server. Section 4.2 seems like a reasonable idea on the face of it. I wonder if we couldn't reuse stanza forwarding here. I don't think this needs to be limited to components, and I think the general processing by the server ought to be to send the stanza from target bare jid, relaying responses back, something like: <iq to='[email protected]' from='[email protected]/resource' type='set' id='123'> <privilege><!-- or something --> <forwarded> <iq to='[email protected]' type='get'> <foo/> </iq> </forwarded> </privilege> </iq> The server would then send its own stanza on behalf of the target, in this case: <iq from='[email protected]' to='[email protected]' type='get' id='random-id-1'><!-- Note filled-in id --> <foo/> </iq> <iq to='[email protected]' type='result' id='123'/><!-- Respond to the original request with success --> And a response would return: <iq to='[email protected]' from='[email protected]' type='result' id='random-id-1'/><!-- Track the id/to/from tuple --> The server receives this, and forwards back to the source: <iq from='[email protected]' to='[email protected]/resource' type='set' id='456'> <privilege><!-- or something --> <forwarded> <iq to='[email protected]' type='get'> <foo/> </iq> </forwarded> </privilege> </iq> Source acknowledges (probably ignored): <iq to='[email protected]' from='[email protected]/resource' type='result' id='456'/> Section 5, I worry over - I don't think components which aren't explicitly provisioned in the server are really going to work. That said, expanding the stanza relaying thing from Section 4.2 across to all clients probably works for most use cases. The bit I was expecting to see, and didn't, was a protocol for trapping and/or intercepting specific namespaces. I think a small amount of expansion of Section 4.2 should do the trick, something like: <iq to='[email protected]' from='[email protected]/resource' type='set' id='789'> <privilege> <handle stanzas='*' namespace='...'/> </privilege> </iq> This expanded Section 4.2 really needs to be a XEP in itself. What you can then do is handle quite a bit of the services traditionally run by the server on your bare jid within a client instead, up to and including PEP - though I strongly suspect that any server implementing this would be implementing PEP as well. Similarly, a component could run services for all bare jids with relative ease. The final missing portion is having a component actually intercept traffic heading to other connections or sessions. I'm nervous about this, and suspect it'd be problematic - is there much interest? On 12 May 2014 16:27, XMPP Extensions Editor <[email protected]> wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Privileged Components > > Abstract: This specification provides a way for XMPP components to have a > privileged access to entities data > > URL: http://xmpp.org/extensions/inbox/privilege-component.html > > The XMPP Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > >
