[Standards-JIG] Re: component protocol

Ralph Meijer jabber.org at ralphm.ik.nu
Fri Nov 17 08:51:52 UTC 2006

On Fri, 2006-11-17 at 09:03 +0100, Jean-Louis Seguineau wrote:
> I support Matthias approach here. If we make components able to connect
> directly, they become de-facto similar to IM servers, with the associated
> advantages and drawbacks. In particular, it could impose a dependence on DNS
> which components do not need.
> IMO components are meant to extend the functionality of an associated
> server, and sometimes do not provide services which are visible to an end
> users. They may need to receive stanzas independently from any DNS
> resolution. In many cases, they will be part of a greater whole comprising a
> home server.
> Rationalizing the namespace is probably the way to go. But as many servers
> use the "jabber:component:accept" to differentiate from an S2S connection we
> need to come up with a better alternative than just connecting on a
> different port. Maybe adding a new optional feature on the stream... 

If your server has an s2s implementation you have to configure it to
listen to port 5269. Or, i you choose another port, you can setup DNS
SRV records to point to the actual port.

If your server has an c2s implementation [..] 5222. Or, [..]

So, why is it a problem to configure a server to use a particular port
for component connections. E.g. jabberd2 accepts all components on the
same port 5347.

About the namespace, why is that a problem exactly? I suppose that if
your development platform is able to switch between 'jabber:client' and
'jabber:server', a third namespace wouldn't be an issue. I haven't had
any difficulty with it in my code.

The advantage of a separate namespace is that it clearly marks that
stanzas are treated differently.

As for the actual component protocol, I do agree that it can use a fresh
look. SASL and TLS are one thing. But I am also interested in giving
components more access to server internals to implement something like
PEP as a component.
A while back this page was created to try and list some requirements:

Making 'components' do s2s is not a protocol issue, but an
implementation issue. You can do this today, and I am actually looking
into implementing this in Twisted. The reason the component protocol
exists is that it makes it easier to 'offshore' the s2s handling.
External entities need to set up separate s2s connections for every
component that you host in this way, too.

I also want to investigate the possibility to create a server of which
the node part of its JIDs is in a shared namespace. For example, you
could have ralphm at ik.nu being a user account and hallway at ik.nu being a
MUC room. This deviates a bit from the traditional view on how to
implement servers, but I think it simplifies deployment. You only need
one s2s connection for exposing all your services to external entities,
and only one SRV record.



More information about the Standards mailing list