[ejabberd] MUC / JEP-0045

Peter Saint-Andre stpeter at jabber.org
Wed Jan 4 21:45:24 MSK 2006


Sergei Golovan wrote:
> On Wed, Jan 04, 2006 at 07:12:30PM +0100, Le Boulanger Yann wrote:
>> Hi all,
>>
>> when I read JEP-0045, I see that (section 9.1.1, workflow sequence #2):
>>
>> "If this user is allowed to create a room and the room does not yet 
>> exist, the service MUST create the room according to some default 
>> configuration, assign the requesting user as the initial room owner, and 
>> add the owner to the room but not allow anyone else to enter the room 
>> (effectively "locking" the room)."
>>
>> but when I create a room on an ejabberd server, it is never locked, even 
>> if I don't configure it. So users can join it before I configure it. Is 
>> it a bug in MUC implementation of ejabberd ? cause it violates the JEP.
> 
> Yes. ejabberd never locks the room. And I don't see any reason (except the
> word MUST in JEP-0045) why the room has to be locked after its creation.
> 
> I think that it's not a good practice to force users doing something. If user
> wants to configure room, he/she can do it.
> 

The lock is there to avoid certain race conditions, allowing people to 
discover the room before it has been properly configured (maybe the 
owner wants to require a password or make it members-only and doesn't 
want anyone to enter before setting that up), etc. If clients want 
instant rooms (no locking), they can request that.

See also the note at the end of Section 9.l.1 of JEP-0045:

***

Note: If the presence stanza sent to a nonexistent room does not include 
an <x/> element qualified by the 'http://jabber.org/protocol/muc' 
namespace as shown above, the service SHOULD create a default room 
without delay (i.e., it MUST assume that the client supports "groupchat 
1.0" rather than Multi-User Chat and therefore it MUST NOT lock the room 
while waiting for the room creator to either accept an instant room or 
configure a reserved room).

***

Just because you don't happen to like room locking doesn't mean you can 
ignore the spec. Clients have plenty of options to avoid room locking if 
they want to.

Peter


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.jabber.ru/pipermail/ejabberd/attachments/20060104/8c8b88a4/smime.bin


More information about the ejabberd mailing list