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

[Jacques Belissent]

I was assuming perhaps naively that there were good reasons for having 
the 2 options.

One possible benefit of the passwordprotected option is to allow 
toggling between requiring password and not requiring password while not 
having to reenter the password everytime.  Conversely there may also be 
some use cases where we want to the room to be password protected (and 
hence set passwordprotected=1), but maintaining the password in a static 
configuration form is not practical.  Perhaps someone is aware of a more 
convincing use case.

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.

Jacques



Julien PUYDT wrote:
> Hal Rottenberg a écrit :
> 
>> I think the best solution is to do as Nolan suggested.  Not let this
>> confusing situation happen.  Let me give you a hypothetical example
>> using a text-based jabber client:
>>
>> # create_room roomname
>> Enter password, or hit ENTER for no password
>>
>> I can't see doing this any other way.  At least not without
>> intentionally introducing confusion.  :)
>>
> 
> $ create_room roomname
> Password-protect the new room (y/n) ? y
> Password:
> Re-enter password for verification:
> Room created.
> 
> Where is the confusion ?
> 
> Snark on #gnomemeeting