[Standards-JIG] JEP-0045 role/affiliation changes

Peter Saint-Andre stpeter at jabber.org
Tue Apr 18 17:08:31 UTC 2006

Hash: SHA1

Ian Paterson wrote:
>> The examples in JEP-0045 (e.g. 157/160 in sections 9.6 and 
>> 9.7) seem to suggest that whenever a user's affiliation is 
>> changed then the role will automatically be changed at the 
>> same time. Is that true?
>> I couldn't find that behaviour explicitly described in the 
>> JEP. (I may well have missed it, in which case my apologies.) 
> I did miss it, immediately above the examples I quoted above!! Sorry.
>> Should these role change triggers at least be mentioned in 
>> Table 2 (section 5.1.2).
> I still think this would be a good idea. Since, for example, when
> 'admin' or 'owner' privileges are given then the 'role' MUST be changed
> to 'moderator'.

I think that's reasonable, but want to noodle on it some more to be sure.

> Also, when privileges are removed the language is seems (deliberately?)
> vague: the 'role' MUST be set to an "appropriate value" given the
> affiliation level and the room type. Should we tighten this up, or are
> implementations free to consider any value "appropriate"? For example
> when removing "admin" privileges could an implementation leave the
> 'moderator' role unchanged?

The current text is deliberately vague. Yes, an implementation could
make a non-admin a moderator after revoking admin privs, for example.
Legislating that a former admin MUST be demoted to participant (not
moderator) seems a bit odd, and hardcodes the relationship (if any)
between role and affiliation in ways that seem unnecessary to me.

> If so then client developers would probably find another note useful.
> Something like: "Since the client can't predict what the role will be
> after revoking privileges then if it wants to remove both admin/owner
> privileges and moderator role *at the same time* (i.e. without an
> asynchronous wait and see) then it should specifically request the role
> change."

Yes, the client would need to request both the affiliation change and
the role change if that is what's desired.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- 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/20060418/20fcd881/attachment.bin>

More information about the Standards mailing list