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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Waite > Sent: Saturday, September 24, 2005 5:32 PM > To: Jabber software development list > Cc: [EMAIL PROTECTED] > Subject: Re: [jdev] Single host,multi service. -was [ANN] > Google Talk engineering manager live chat > > On 9/24/05, Matt Tucker <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] > > > > 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 > > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > 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 > > [EMAIL PROTECTED]/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 [EMAIL PROTECTED] 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. >
