[jdev] Single host, multi service.

[Kevin Smith]

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 foobar-smith at example.com? 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