[Standards-JIG] Re: password-protected room with no password (MUC)

Nolan Eakins sneakin at semanticgap.com
Wed Sep 21 03:20:48 CDT 2005


Trejkaz wrote:
>>Another way to "resolve" this discussion is to say in the jep that
>>password format (including whether or not the password can be blank) is
>>a matter of site policy.  In the event that this policy is violated
>>while configuring the room, the owner request should fail with an
>>appropriate (not-acceptable?  bad-request?  new one?) condition.
> 
> 
> That sounds like the best idea so far.  Trivial passwords, if someone
> chooses to allow them, should be acceptable.  An empty password is just
> the most trivial password possible, but passwords which are dictionary
> words might also be rejected, or any password which cracklib deems to be
> insecure.

I completely disagree that a blank password should be allowed at all. 
The way I have Psi coded right now is that if the password field is 
blank when you join, then it doesn't send a password element at all. 
Allowing a blank password could do three things:
    1. forces a "Is the room password protected?" checkbox onto the join 
room UI which is completely unneeded
    2. the client queries the room to see if it's password protected
    3. the client tries to join w/o sending a blank password, fails, 
then tries sending a blank password

Number 2 might be the best thing since it could enable/disable the 
password field, but there's the lag issue of sending the query and 
getting results. That puts us back to how I currently have Psi's join 
dialog working which would allow those impatient types to quickly get 
into a room w/o waiting for all the data to get received.

All in all, I really like making blank password == no password.

- Nolan




More information about the Standards-JIG mailing list