[Standards-JIG] jep-0045 question
stpeter at jabber.org
Fri Nov 4 21:11:20 UTC 2005
Etan Reisner wrote:
> On Thu, 27 Oct 2005, Peter Saint-Andre wrote:
>> On 2005-02-24 (!), Etan Reisner wrote:
>>> I was looking over jep-0045 and was puzzled by the disparity between the
>>> boolean reporting of nonanonyymous/semianonymous,
>> I don't see that this is boolean -- it is possible to also offer fully
>> anonymous rooms (even the room owner can't determine the identity of
>> occupants), although for room management purposes that is very much
>> not recommended. Where do you see that this is boolean?
>>> while the room
>>> configuration option muc#roomconfig_whois is list-single (which seems to
>>> indicate to me that implementations can have other values than the two
>>> listed in the jep).
>> It seems that the _whois configuration option is potentially
>> confusing. I suppose it was originally meant to provide a way for
>> moderators to view the real JIDs of occupants, but they can be
>> upgraded to admins if that is necessary, so I propose to remove this
>> configuration option from the next version of the JEP. Objections?
> Being slightly more familiar with jabber stuff at this point, I wouldn't
> have sent quite the email. My real concern was that things seemed
> defined in such a way that using other values for _whois didn't really
> For example, under 4.2 Room Types a Semi-Anonymous Room is defined as a
> room in which full JID:s are discovered by room admins only. (Contrasted
> to Fully-Anonymous and Non-Anonymous rooms.) Whereas section 6.3.6
> Semi-Anonymous Rooms however defines a semi-anonymous room as one in
> which full JID:s are sent to anyone with the role of "moderator".
> This already is slightly problematic, assuming "room admins" meant the
> Admin affiliation and not the "moderator" role. The further confusion is
> that if a service were to implement other gradations for _whois they
> would be somewhat hard pressed to show that information in a rooms disco
> information because only muc_nonanonymous and muc_semianonymous are
> defined and _semianonymous, I would imagine, should be interpreted as
> indicating Semi-Anonymous Rooms as defined in the spec.
> As to what to do about the situation, I have a couple thoughts.
> One, the language in 4.2 and 6.3.6 could be reworded so that they
> clearly indicate the same thing about to whom full JID:s are reported in
> Semi-Anonymous rooms. And either anyone implementing any further options
> to _whois would just not indicate that in disco info or further options
> are disallowed (which would then seem to make changing _whois to be a
> boolean option make sense).
> Two, _whois could be expanded to allow for any affiliation or role and
> the definition of Semi-Anonymous room could be changed to encompass any
> room in which not everyone receives the full JID, which would allow for
> any value of _whois to advertise muc_semianonymous.
> Three, _whois could be expanded to allow for any affiliation or role to
> be used and Service Discovery Features/Room Types could be defined for
> every affiliation/role.
Yes, right now the _whois is perhaps a bit misnamed. There really are
three possible values:
1. anyone (non-anonymous)
2. admins only (semi-anonymous)
3. no one (fully anonymous)
Personally I think #3 is not recommended, but the others map directly to
the defined room types and that needs to be specified more clearly.
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards