[Standards-JIG] jep-0045 question

Peter Saint-Andre 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?
>> Peter
> 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 
> function.
> 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.


Peter Saint-Andre
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20051104/e5f95809/attachment.bin>

More information about the Standards mailing list