[Standards] XEP-0045 Room (JID) aliases

Dave Cridland 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
> knows
> > > 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
> this
> > without the client being at all aware - there's no need for a
> specification
> > 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
> specified?

The latter.

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
discussions elsewhere).

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...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180502/28076064/attachment.html>

More information about the Standards mailing list