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

[Matt Tucker]

David,

Yep, I'm in agreement with all of your points. We thought long and hard
about how to come up with a reasonable workaround for the name collision
issue and couldn't. That's how we arrived at the parent DNS algorithm
workaround.

Regards,
Matt

> -----Original Message-----
> From: jdev-bounces at jabber.org 
> [mailto:jdev-bounces at jabber.org] On Behalf Of David Waite
> Sent: Saturday, September 24, 2005 5:32 PM
> To: Jabber software development list
> Cc: hal at halr9000.com
> Subject: Re: [jdev] Single host,multi service. -was [ANN] 
> Google Talk engineering manager live chat
> 
> 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.
>