jdev - 2023-06-27

Tobi_ hello

Welcome, can we help you?

A JID without a localpart is not a valid JID for a MUC, is that correct?

It Depends™

Zash, how so?

I don't think there's any technical reason for it not to work

In fact, it's secretly implemented in some server alreaday 😉

selurvedu, why do you ask? why did you think that?

Is there clear text in the XEP? (It's late, not going to read '45 now)

> A JID without a localpart is not a valid JID for a MUC, is that correct? According to the XEP that is correct. Much as is makes me grumpy ↺

> I don't think there's any technical reason for it not to work Zash, me neither. I read 0045 more carefully now, and the only place where "Room ID" (the localpart of a room JID) is mentioned as being used in any way is this paragraph: > Other than the foregoing, this document does not specify what (if anything) a MUC service implementation shall do as a result of a room destruction request. For example, if the room was defined as persistent, an implementation MAY choose to lock the room ID so that it cannot be re-used, redirect enter requests to the alternate venue, or invite the current participants to the new room; however, such behavior is OPTIONAL. Well, since a room with localpart-less JID can probably be created only by a server operator, I guess it's safe to assume that there would be no need to lock that room JID to protect it from being re-used, and so it's totally safe to disregard the OPTIONAL choice that an implementation MAY make.

The XEP says nothing about MUC JID localpart / room ID in terms of "MAY, SHOULD, MUST be present", it's written as if it's always "just there" and its guaranteed presence is some sort of "common knowledge". I interpret it as an implicit MUST (sounds as an oxymoron, I know). ✏