[jdev] Single host, multi service. -was [ANN] Google Talk engineering manager live chat
matt at jivesoftware.com
Sat Sep 24 19:54:01 CDT 2005
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
> -----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
> > 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.
More information about the JDev