[jdev] Single host, multi service. -was [ANN] Google Talk engineering manager live chat

[Matt Tucker]

Kevin,

> Let's please quickly agree that it's something to address, 
> and that second-guessing dns entries isn't the way to do it. 

I disagree that our algorithm is a serious security issue (see my last
email), but would still love to get rid of it. It's a hack that's only
there because there's not another better solution we could think of.

> 2) Name collisions. As has previously been noted, this is 
> easily avoided through prefixes and there's probably much 
> nicer methods.

If this was an easy problem to solve, why didn't everybody just go this
route rather than building out the subdomain system?
 
> 4) JEP-045. I've just been through the muc jep, and I can't 
> find anything which prohibit it sitting on the main server. 
> The pertinent lines seem to be:

Jive Messenger and several other servers implement MUC natively (without
an external component). However, we use an artifical sub-domain for two
reasons:

 1) To avoid name collisions.
 2) Because every other server uses sub-domains and we try to follow the
community practices as much as possible.

It's a bummer that JID's weren't constructed to deal with this
sub-domain issue from the beginning. For example, they could have been
in the form:

node/service at server.com

This would work great since "/" is already a prohibited character in
nodes.

I don't think pre-fixes are a reasonable general approach, though. Let's
say that a new service is invented as a JEP called "foobar". You could
then mandate that any JID pre-pended with "foobar-" belongs to that
service on your example.com server. But, what if there's some
unfortunate person on your server named Foobar Smith that already has
the JID foobar-smith at example.com? It's just not possible to anticipate
all name conflicts unless we agreed on some format to restrict nodes
using some specific format. I don't see how that would be possible
without adding in some restrictions that aren't part of the XMPP RFC's,
but I'm open to ideas.

Regards,
Matt