[Standards] request for reviews: XEP-0045 v1.25rc5
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:
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
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
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
More information about the Standards