[Standards] Proposed XMPP Extension: Component Connections

Mridul Muralidharan mridul at sun.com
Thu Aug 2 21:36:42 UTC 2007

Peter Saint-Andre wrote:
> Mridul Muralidharan wrote:
>> XMPP Extensions Editor wrote:
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>> Title: Component Connections
>>> Abstract: This document specifies a standards-track XMPP protocol
>>> extension that enables server components to connect to XMPP servers.
>>> URL: http://www.xmpp.org/extensions/inbox/component.html
>>> The XMPP Council will decide at its next meeting whether to accept
>>> this proposal as an official XEP.
>> What exactly does binding a hostname mean ? Multiple component JID's
>> over the same stream ? If yes, why exactly do we need it ?
> Think virtual hosts:
> conference.jabber.org
> conference.xmpp.org

Hmm, this is very tricky ground - and I am not sure if the proposal is 
considering a lot of aspects of hosted domains ...
For example, how does conference.jabber.org get associated with 
jabber.org virtual domain (so that users of jabber.org will be 
implicitly exposed to only this muc, not to conference.xmpp.org, etc).

I can understand the intention here - the way we handle this is slightly 
differently: the muc/pubsub/jud is part of the server, so the 
server/component 'knows' which hosted domain the client belongs to, and 
which hosted domain the conference should belong to, etc.

With an external component, this becomes really tricky without wildcard 
support of some sort - something like conference.<hosted_domains>, etc.

Thinking more, to expose this sort of behavior, we will need a way for 
components to query for list of hosted domains (which would not be 
available in a lot of cases - it is typically lazily loaded (and subject 
to change at runtime), sometimes to the tune of 4k+ domains).

Typically, in our deployments, external components are not restricted to 
a domain - but are available to the whole deployment. We would expect 
impl specific acl's controlling which component is exposed to which 
hosted domain.

> Etc.
>> Also, since there seems to be no restriction on what can be bound, it
>> can potentially bind valid s2s domains ... unlike the current component
>> jid which is preconfigured at the server.
> Yes that needs to be specified more carefully.
>> Also, how would this interact with dix [1] ? Not sure of the state of
>> that submission - but just the support for multiple resources made it
>> very useful proposal.
> Ask Chris Mullins. :)

Asked JD :)


> /psa

More information about the Standards mailing list