[JDEV] In-band registration

[Ryan Eatmon]

Bart van Bragt <jabber at vanbragt.com> said:

> Ryan Eatmon wrote:
> > Part of the goal was to make it easy to run a jabber server.  Just 
> > configure it (which can be hard enough), and run it.  That's it.  That's 
> > all that is required.
> I see your point but IMO this is hardly a usable setup in most settings. 
> In 99% of the (non-test) implementations you want to use an existing 
> userdatabase and you at least want some control over the userbase (admin 
> tools etc). So I would propose to drop inband registration (to help both 
> new users and to make clients easier) and to include a small tool with 
> the Jabber server to manually create (test) accounts.
> 
> Jabber servers that are going to be used by ISPs and companies will most 
> definately disable in-band registration anyway which leaves public 
> servers and test servers. Public servers need something more than only a 
> jabber server, it would be nice if there was at least some kind of 
> contact info and people with test servers can just use the admin tools 
> that come with the server.
> 
> IMO this would also make the user experience more consistent because at 
> the moment with some servers you can do in-band registration and with 
> other servers you can't :\



You might be correct, and I might agree with you that in MOST settings in band
registration is either A) insecure or B) unneeded.  But MOST is not the same
as ALL.

I have yet to hear any good arguments for dropping it 100%.  I hear lots and
lots of arguments for creating new methods of registering, which as I said I
fully support.

I also hear that turning off open registration by default would be good thing,
which I also 100% support.

But to remove an option that makes things very flexible in some situations
just because it makes clients easier, or it's insecure, or spammers, or
whatever...  These are not a good enough reasons.  There are lots of reasons
that it would be nice to provide an open registration, and here is just one:


I have a private network (say home network) and I want to hook up some
automatoed clients (say home theatre equipment).  I cannot tell the equipment
what jabber account to log in with.  Nor do I really want to go to my jabber
server and manually add all of the new stereo equipment/dvd players that I
just purchased.  As an end user, either is painful.  I just want to plug it
in, turn them on, and boom.  They work.

So I tell my private jabber server, that doesn't allow outside connections
(the optional feature), to allow for in band registration (another optional
feature).  Now the stereo equipment can use SRV records to find the Jabber
server, register, and login.  Now they discover each other and pass messages.
 Home automation at it's finest.


Before we just blindly remove features from Jabber just because someone
doesn't like it, think about ALL of the ramifications:

- Does keeping in band registration make clients harder.  I don't think so,
but some people do.  Support x:data and get the 2.0 server to send out
register packets with x:data forms.  Your client should support x:data anyway.

- You cannot get rid of iq:register completely because it used to register
with transports and other components...  So why get rid of it completely for
user accounts (which is just another component).

- Schemes can be created to tighten security.  Basic encryption, or what not.

- As for spammers.  I am not in favor of giving up freedoms just because
someone might abuse them.



> -- 
> Bart van Bragt
> Get Jabbered!    :    www.jabber.org     :     JID = jabber at vanbragt.com
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 



-- 
Ryan Eatmon
reatmon at jabber.org