[Standards-JIG] Re: password-protected room with no password (MUC)
sneakin at semanticgap.com
Wed Sep 21 08:20:48 UTC 2005
>>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
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.
More information about the Standards