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.
