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

[David Waite]

On 9/24/05, Matt Tucker <matt at jivesoftware.com> wrote:
> 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.

no no no.

The whole reason you _can't_ run every service on one domain name
today is because people attached semantic meaning to portions of the
identifiers, causing collisions and confusion in naming. Adding a
level of categorization to the JID would solve the symptoms, but not
the actual problem. For example, I can't really get away with having

room-general at server.com
user-foo at server.com

for groupchats and users unless I'm willing to live with rooms having
the 'room-' prefix on all their displayed names, and only allowing
registration if someone types in 'room-<whatever>'. Nor can I go with
an internal naming system like

muc at server.com/general/user3

It simplified writing clients because there was less metadata to deal
with for interacting with services - but pushed the uniqueness
requirement out to the DNS level. This had the benefit for users
in-the-know that they could look at a jid and have a good idea that
'conference.jabber.org' probably was something they used groupchat to
talk to.

Pretty much your only option for single domain name usage would be to
take the naming conflict hit; to not allow having a 'general' room and
a 'general' user at the same time. There would be no naming hint to
indicate how you are supposed to interact with 'general', which would
cause user confusion (there isn't a fundamental type of interaction or
discovery within XMPP, and extensions like disco are sadly
undersupported). You would also be unable to expose a transport (like
msn.jabber.org) because there wouldn't be a way to prevent the
namespaces from colliding.

Adding type of to the URI is something that just isn't recommended.
For instance, when I go to a web site with a http URL, I have no idea
whether that is a static page, a dynamic page, an image, or a WebDAV
share. Likewise, when I have an email address, there isn't anything
within that 'mailto' that distinguishes a user or administrative
account from a mailing list or SOAP endpoint. Add in that
categorization, and it quickly explodes into.. well, MIME.

-David Waite

> 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.

The semantic meaning of the node portion of the JID makes it a tough
and limiting choice. For instance, even administrator-created fixed
muc room names will cause a problem if your users are maintained
externally, such as within LDAP.