[Standards] XEP-0045 Room (JID) aliases
dave at cridland.net
Wed May 2 07:44:26 UTC 2018
On 1 May 2018 at 12:03, Maxime Buquet <pep at bouah.net> wrote:
> On 2018/05/01, Dave Cridland wrote:
> > > I wanted to have fancyname at muc and serious-business at muc, pointing to
> > > the same room.
> > >
> > > For this particular use case an alias might be best, The component
> > > what other has joined what JID and speaks to them via this JID. I would
> > > also be ok with a redirect though, having the component state "business
> > > happens _there_".
> > >
> > > Redirect implies client support I assume, but that would also allow for
> > > redirects to other components.
> > >
> > >
> > Right.
> > But if you have it in the same domain, then the domain can manage all
> > without the client being at all aware - there's no need for a
> > here, since you're just using the existing one.
> Which existing one? Can you point me to the place in 0045 for this?
> Or are you talking of 0045 in general? In this case it would just seem
> like an implementation detail (the aliasing) and nothing actually
If you have one server providing a room under two names, then every
occupant of each room sees only one name, and interacts in exactly the same
way as described in XEP-0045. The server can do all manner of things as
long as it is in full conformance with XEP-0045.
As a different example, a room can be hosted on multiple server instances
without contravening, or extending, XEP-0045 - we do this all the time and
call it clustering.
We only define two things:
* What traffic causes what behaviour.
* What the security implications of that traffic and/or behaviour are.
Anything outside that it also outside our scope (modulo legal implication
If we wanted to have a named room hosted across multiple administrative
domains, though, that would mean we had a second boundary and that would
need definition - so far we've avoided doing that because of the
implications of sharing administrative access, and instead gone for FMUC.
But if there was a will, we could go further.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards