Kevin, > Let's please quickly agree that it's something to address, > and that second-guessing dns entries isn't the way to do it.
I disagree that our algorithm is a serious security issue (see my last email), but would still love to get rid of it. It's a hack that's only there because there's not another better solution we could think of. > 2) Name collisions. As has previously been noted, this is > easily avoided through prefixes and there's probably much > nicer methods. If this was an easy problem to solve, why didn't everybody just go this route rather than building out the subdomain system? > 4) JEP-045. I've just been through the muc jep, and I can't > find anything which prohibit it sitting on the main server. > The pertinent lines seem to be: Jive Messenger and several other servers implement MUC natively (without an external component). However, we use an artifical sub-domain for two reasons: 1) To avoid name collisions. 2) Because every other server uses sub-domains and we try to follow the community practices as much as possible. 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. 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. Regards, Matt
