[Standards-JIG] UPDATED: JEP-0045 (Multi-User Chat)

Ian Paterson ian.paterson at clientside.co.uk
Fri Jun 25 11:41:04 UTC 2004


Peter,

Thanks for all your latest changes to JEP-0045.


Just one question, I wondered why you decided to make "admin/owner
revocation text and examples consistent with the state chart" rather than
the other way around. IMHO, the limitations in the Affiliation State Chart
seem to create extra work for implementors without achieving anything
useful.

Can anyone tell me why it should not be possible to change an 'Admin' or
'Owner' affiliation directly to 'None'? This is possibly the most common
scenario. (For example when one of the room owners leaves the organisation
that operates a MUC service.) So why force the client to send three
consecutive stanzas in order to remove a user's room ownership?
(owner->admin, admin->member, member->none)

I guess there is no insurmountable implementation problem here, since the
latest release of the MU-Conference implementation (version 0.6) allows
owners/admins to be given the affiliation 'None' directly (owner->none in
one stanza).

Why even bother to prevent the more unlikely affiliation changes, when the
effect can be achieved with multiple stanzas anyway?. For example, an
owner's affiliation being set directly to 'outcast', or vice versa. Why
*require* that all client and server implementators write the extra code
needed to check for illegal behaviour and/or generate the error messages?
After all, if we remove the state change limitations from the spec, then a
client implementation is still free to ask users for confirmation (before
banning an owner, for example).

Regards,

- Ian



> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org]On Behalf Of Peter Saint-Andre
> Sent: 25 June 2004 05:00
> To: standards-jig at jabber.org
> Subject: [Standards-JIG] UPDATED: JEP-0045 (Multi-User Chat)
>
>
> Version 1.15 of JEP-0045 (Multi-User Chat) is now available; the
> changelog is:
>
>    Removed jabber:iq:browse references; clarified order of presence
>    stanzas sent to new occupant on entering room; specified format of
>    in-room messages (type='groupchat', from='room at service'); clarified
>    allowable attributes in various list-related operations; made
>    admin/owner revocation text and examples consistent with state chart;
>    clarified ownership revocation conflict scenarios; changed the
>    'muc#owner_inviteonly' field to 'muc#owner_membersonly'; changed
>    attribute order in examples to match XML canonicalization rules;
>    corrected several errors in the schemas. (psa)
>
> I believe this addresses all questions raised on the list in the last
> month or so (I apologize for having not participated, but at least now
> I'm caught up).
>
> http://www.jabber.org/jeps/jep-0045.html
>
> Peter
>
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
>




More information about the Standards mailing list