[Standards] Proposed XMPP Extension: Privileged Components

Dave Cridland dave at cridland.net
Thu May 15 08:15:15 UTC 2014


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='user at example.com' from='user at example.com/resource' type='set'
id='123'>
  <privilege><!-- or something -->
    <forwarded>
      <iq to='someone at example.net' 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='user at example.com' to='someone at example.net' type='get'
id='random-id-1'><!-- Note filled-in id -->
  <foo/>
</iq>
<iq to='user at example.com' type='result' id='123'/><!-- Respond to the
original request with success -->

And a response would return:

<iq to='user at example.com' from='someone at example.net' type='result'
id='random-id-1'/><!-- Track the id/to/from tuple -->

The server receives this, and forwards back to the source:

<iq from='user at example.com' to='user at example.com/resource' type='set'
id='456'>
  <privilege><!-- or something -->
    <forwarded>
      <iq to='someone at example.net' type='get'>
         <foo/>
      </iq>
    </forwarded>
   </privilege>
</iq>

Source acknowledges (probably ignored):

<iq to='user at example.com' from='user at example.com/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='user at example.com' from='user at example.com/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 <editor at xmpp.org> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140515/4863fc23/attachment.html>


More information about the Standards mailing list