Jabberd Component Protocol

Please read the original jabberd2 Component Protocol JEP proposition first,
or the shorter, developers version.

jabberd 2.x uses the following packets, not included in the proposition:

Changes

Changes introduced in 2.1 series are:

  • <route/> packet has now a type='log' attribute for packets that are a result of duplication for logger component

Proposed Enhancements

Presence subscriptions

A component could subscribe a JID presence from SM. It is treated by SM like any other user presence subscription. 

<presence xmlns='http://jabberd.jabberstudio.org/ns/component/1.0' from='component' to='domain.tld' type='subscribe'>
  <jid>user@domain.tld</jid>
</presence>

which is auto-accepted (if component had bind with presence access right) 

<presence xmlns='http://jabberd.jabberstudio.org/ns/component/1.0' from='domain.tld' to='component' type='subscribed'>
  <jid>user@domain.tld</jid>
</presence>

or denied 

<presence xmlns='http://jabberd.jabberstudio.org/ns/component/1.0' from='domain.tld' to='component' type='unsubscribed'>
  <jid>user@domain.tld</jid>
</presence>

To remove the presence subscription send: 

<presence xmlns='http://jabberd.jabberstudio.org/ns/component/1.0' from='component' to='domain.tld' type='unsubscribe'>
  <jid>user@domain.tld</jid>
</presence>

which is confirmed 

<presence xmlns='http://jabberd.jabberstudio.org/ns/component/1.0' from='domain.tld' to='component' type='unsubscribed'>
  <jid>user@domain.tld</jid>
</presence>

Roster access

It is modelled after user roster access protocol. 

<route xmlns='http://jabberd.jabberstudio.org/ns/component/1.0' from='component' to='domain.tld'>
  <iq from='component' to='user@domain.tld' type='get' id='roster_1'>
    <query xmlns='jabber:iq:roster'/>
  </iq>
</route>

and SM repies with usuall: 

<route xmlns='http://jabberd.jabberstudio.org/ns/component/1.0' from='domain.tld' to='component'>
  <iq to='component' from='user@domain.tld' type='result' id='roster_1'>
    <query xmlns='jabber:iq:roster'>
      <item jid='romeo@example.net'
            name='Romeo'
            subscription='both'>
        <group>Friends</group>
      </item>
[...]
    </query>
  </iq>
</route>

And, as every available user resource, the component that requested a roster will recieve usuall roster pushes when user modifies the roster.

Security note: SM MUST check if the <route/> and <iq/> from attributes match. If not, the roster request could sneak through S2S.

Attachments