[Standards-JIG] Re: password-protected room with no password (MUC)
jacques.belissent at Sun.COM
Mon Sep 19 22:35:21 UTC 2005
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.
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
> Re-enter password for verification:
> Room created.
> Where is the confusion ?
> Snark on #gnomemeeting
More information about the Standards