On 24 Sep 2005, at 23:47, Matt Tucker wrote:
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.
Well, serious or minor is all open to debate, and whichever the
outcome is irrelevant. I'm not attacking you here by saying "serious
security hole". You tried to fix a problem that I want fixed. It's
trying to find the better solution that you speak of that I want this
thread to now focus on. We've got some damn smart people hanging
around, someone smarter than me will undoubtedly have the answers I
don't. I do not want your hack removed and the old functionality
restored. I just want the hack replaced ;)
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?
Well, given the choice I still think the multiple subdomain thing is
a prettier system and (as previously proven in this list) it is a
reasonable suprise to some people that it would be difficult for
anyone with one entry to get several. I know for both of the servers
I'm part-admin of it wasn't a problem, I can only imagine it being a
problem in enterprises because of brief dealings with the computing
policies I've brushed against once or twice.
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.
If this is the main sticking point, lets discuss if (or people
smarter than me discuss it ;))
2) Because every other server uses sub-domains and we try to
follow the
community practices as much as possible.
I think that's a very reasonable approach but (as you also seem to
have thought) I think the community practises in this case aren't ideal.
It's a bummer that JID's weren't constructed to deal with this
sub-domain issue from the beginning.
Yes, it quite possibly is.
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.
Well, lets start with the two things that occur to me.
1) #-prefixes for room names, like IRC. Remember that this isn't a
retrospective change, we're not asking for people who currently have
multiple DNS entries to give them up, we're providing a method for
new servers to be set up.
2) On-the-fly collision checking. If there's a user jid existing,
don't allow a muc jid there, just as you wouldn't if there was an
existing muc room there. Similarly don't allow users to register with
room names.
Not perfect but I don't want you to implement my ideas, I'd just like
some discussion from everyone with an interest :)
/K
--
Kevin Smith
Psi Jabber client maintainer (http://psi.affinix.com/)
Taekwon-do club captain (outgoing), University of Exeter
Postgraduate Research Student, Computer Science, University Of Exeter
