[Standards] request for reviews: XEP-0045 v1.25rc5

Waqas Hussain waqas20 at gmail.com
Tue Sep 20 05:34:09 UTC 2011

On Thu, Aug 18, 2011 at 6:43 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an
> effort to incorporate developer feedback I've received since the last
> version 3 years ago. The XMPP Council would like to vote on these revisions
> before the end of September or possibly early October, so it would be great
> if folks could check the diff in the next few weeks:
> http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5

1. Using GC instead of "groupchat 1.0" in various places

This doesn't affect me, but new readers of the document might find it confusing.

2. Room subject

The current text suggests the room should send a subject if it's set.
I'd like it to send <subject></subject> in the case when it's not set.
The subject will then act as a clear end marker for room history.

3. Service changing room nick

I'd like some text stating that a service can change the occupant's
nick at any time, including room join. An occupant MUST listen for
status code=100 in available presence for their current nick.

4. Presence from existing occupant to bare room JID

The MUC's behavior is currently undefined. At least for the
type="unavailable" case (and perhaps also for the available case), the
MUC should handle and treat it as if it was sent to the occupant's

5. Both <subject/> and <body/> in a single message

"(A message with a <subject/> and a <body/> is a legitimate message,
but it SHALL NOT be interpreted as a subject change.)"

I object to this. It complicates subject handling. I believe much
existing MUC software considers a message a subject change if it has a
<subject/> in it. How should software determine this? Assume it's a
subject change if there's no <body/>? What if there is not body, but
xHTML-IM is included? What if there's no body, but some

6. action nick and jid for kicks and bans

Examples 85 and 108 have been updated from <actor jid='...'/> to
<actor nick='...'/>, but the text immediately before them still says
"the bare JID of the user who initiated [...]". What I'd like here is
to allow the room to include a nick and/or a bare/full JID. A nick is
useful for general consumption, but a service should be allowed to
turn this off. And a service should be allowed to include JID in the
stanzas going to occupants who are allowed to see JIDs (moderators).
And I don't see any particular reason to not make them full JIDs.

7. Section 16.1 restates what RFC6122 already specifies (and calls it
RFC6120 instead).

And I have mixed feelings about that MUST NOT.

8. Presence subscriptions

I've been wanting to add this in Prosody, but have worried about
client behavior on receiving both MUC-specific, and normal presence
from the same JID. I'm +1 to it though. Many users do add rooms as

9. In schema section 18.2 http://jabber.org/protocol/muc#user

I'd like <xs:element ref='item' minOccurs='0'/> changed to <xs:element
ref='item' minOccurs='0' maxOccurs='unbounded'/>, to allow one <item/>
element for each session in a multi-session nick when including 'jid'.

10. MUC child element in presence errors

"Note: If an error occurs in relation to joining a room, the service
SHOULD include the MUC child element (i.e., <x
xmlns='http://jabber.org/protocol/muc'/>) in the <presence/> stanza of
type "error"."

What is the rationale behind this SHOULD? 'id' attributes are the
canonical XMPP way for matching stanzas to error replies;
RFC6120#8.1.3 is quite clear that 'id' attributes can be depended on
to work fine with presence.

IIRC, in Prosody, we added this specifically because Gajim was having
issues with nick changes (I note that you didn't specify the above
quoted text for this and other error cases). But should this really be

11. Full-to-bare JID rewriting to support vCards

All(?) implementations are doing it, but it's not specified anywhere.
Should it be?

12. History management

Should it perhaps be noted that clients shouldn't depend on getting
only what they asked for? I don't think all MUC implementations
support history management. And 'maxchars' is particularly
troublesome, as anything between the MUC history code and the client
could modify the stanza.



"Nicknames can contain virtually any Unicode character introduces the
possibility of nick spoofing" - grammar fail.


All this came from skimming the diff. I'll probably have more feedback
when I manage to review the entire spec in detail while looking at
Prosody's code.

Waqas Hussain

More information about the Standards mailing list