[Standards-JIG] JEP-0045: 1.21pre6

[Boyd Fletcher]

Peter,

Though its probably too late for 1.21, what would you think about adding
some extensions to MUC in the near future that would support the relaying of
a MUC session between multiple servers. This capability serves a couple of
purposes:

1) reduces the load/stress on a individual server
2) allows for redundancy in MUC architecture without resorting to
proprietary tricks on the end
3) solves a big problem with disconnected operations. For example you have
Two Ships and a Shore operation. Let's say the ships are connected to each
and the shore via Satellite Communications. The sea is rough so the SATCOM
goes up and down a lot, unfortunately the chat server is on land so the
users keep getting kicked out of the chat session. If IRC was being used, a
user on the ship would still be able to chat in the room on the local ship
and when the connection was restored the messages would be sync'd with the
next IRC server in the relay chain. If MUC could do something similar, many
folks could start transitioning from IRC to XMPP.
4) adds to XMPP one of the last remaining major features that is in IRC but
not in XMPP. 

Essentially we see two basic approaches:

1) Quick and Dirty Approach:  A remote users MUC is configured to subscribes
the master/main MUC as a user and relays messages to the locally connected
users
2) Elegant Approach: Would be to implement a MUC server to MUC Server
protocol and essentially let one muc as another muc to create a local
instantiation of a MUC room that its local users can use. Usually there
would be some minimal threshold number of remote users at a site to make
that useful (perhaps 5?)

regards,

boyd



On 8/23/06 10:26 PM, "Peter Saint-Andre" <stpeter at jabber.org> wrote:

> Version 1.21pre6 of JEP-0045 is here:
> 
> http://www.jabber.org/jeps/tmp/jep-0045-1.21.html
> 
> The CVS diff since 1.20 is here:
> 
> http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/0045/jep-0045.xml?r1=
> 1.173&r2=1.182
> 
> The revision history is:
> 
> ******
> 
>     *  Clarified that inclusion of MUC extension in room join/create
> request triggers Data Forms flow but that absence of MUC extension leads
> to automatic room creation for backwards compatibility with older
> groupchat 1.0 protocol.
>     * Specified use of <not-acceptable/> error on nickname change if
> nicks are locked down.
>     * Required clients to discover room configuration prior to entering
> room and specified related security considerations, including use of
> privacy-related status codes 170, 171, 172, 173, and 174.
>     * Specified use of <not-acceptable/> error if room configuration
> options cannot be processed or violate service policies.
>     * Made explicit that roomnicks must not consist only of spaces.
>     * Moved all service discovery use cases into dedicated section.
>     * Changed jabber:x:delay support from SHOULD to MUST.
>     * Clarified that _whois room configuration option specifies room type.
>     * Defined JEP-0128 room information fields for discussion logs,
> associated pubsub node, and contact JID.
>     * Specified that changing role to moderator upon affiliation change
> to admin or owner is recommended, not required.
>     * Added internationalization consideration about localization of
> field labels for various data forms.
>     * Specified that implementations may persist roles across visits and
> should do so for moderated rooms.
>     * Added protocol and service discovery feature for requesting a
> unique room name prior to room creation.
>     * Further clarified nature of reserved room nicknames and nickname
> lockdown.
>     * Defined data forms for requesting voice and approving voice requests.
>     * Added multiple invitee example for XMPP URI.
>     * Added status code for service-modified nick on join.
> 
> ******
> 
> I would like the Council to vote on accepting this version before too
> long (probably in its meeting on August 30 or September 13).
> 
> Note that this version does *not* include a generalized cleanup of the
> permissions model, as some folks on this list seem to desire, since (1)
> that's a major change and (2) I'm not convinced we need it.
> 
> Feedback is welcome.
> 
> Peter