[Standards-JIG] Re: JEP-0045: Room Destruction & Room Full Error Code

Peter Saint-Andre stpeter at jabber.org
Thu Jan 13 18:46:15 UTC 2005

In article <loom.20041202T013215-556 at post.gmane.org>,
 Nolan Eakins <sneakin at semanticgap.com> wrote:

> As usual I was going through JEP-0045 and came across a couple new issues. 
> The 
> first is with the room destruction use case. There's no way to join an 
> alternate venue if it is password protected. The '<destroy/>' doesn't have a 
> password attribute or a '<password/>' to pass along a password. I don't know 
> if 
> this was planned or not, but may be useful.

I have no objections to including a <password/> element as a child of 
> The second was with the error code that gets sent when the room is full. It 
> uses the same error code as when room creation is restricted, 405. I noticed 
> error codes 402 and 408 are not used, so it would be apt to change the error 
> code for when a room is full to one of those. Otherwise someone joining a 
> room 
> will not know if the room is full or if they can't create it.

Well, if we were doing things over now (MUC++?), we would not use 
numeric error codes, but I don't think it's worth the effort to refactor 
that now. In the past, we tried to keep Jabber error codes somewhat 
close to the corresponding HTTP error codes. In HTTP, 402 is payment 
required and 408 is request timeout. Neither of those seems appropriate 
for a full room. In fact, this seems closest to 503 (see RFC 2616):

503 Service Unavailable: The server is currently unable to handle the 
request due to a temporary overloading or maintenance of the server. The 
implication is that this is a temporary condition which will be 
alleviated after some delay. 


More information about the Standards mailing list