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

Peter Saint-Andre stpeter at stpeter.im
Mon Sep 26 21:36:54 UTC 2011


Waqas, thanks for the review. Comments inline. I will push out an
updated version sometime this week, once we settle a few of these issues.

On 9/19/11 11:34 PM, Waqas Hussain wrote:
> 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.

Fixed in my working copy.

> 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.

That seems reasonable. Added to my working copy.

> 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.

I understand nick changes on join, but not after that. What is the use case?

> 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
> nick.

I disagree. Sending presence to the Room JID <room at service> is different
from sending it to the Occupant JID <room at service/nick> (e.g., the user
might be sharing presence with the room itself, if the user and the room
are subscribed to each other's presence).

> 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
> <unknown-element/>?

IMHO a subject change should be a message with *only* a <subject/> child
element and no other children.

> 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.

Fine with me. I've changed "bare JID" to "roomnick or bare JID" but I've
left the examples the same.

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

Reference fixed.

I see no harm in repeating the rules here.

> And I have mixed feelings about that MUST NOT.

We had some discussion about that years ago, and decided that Occupant
JIDs like "room at service/      " would be problematic. Do you have a use
case for those?

> 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
> contacts.

Agreed.

> 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'.

I have no deep objections to that, as long as we don't try to define
mult-session nicks in this spec.

> 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
> a SHOULD?

Probably not. Note that I have added 'id' attributes to most of the
examples now, but they were not present before.

I've deleted that text and the following example from my working copy.

> 11. Full-to-bare JID rewriting to support vCards
> 
> All(?) implementations are doing it, but it's not specified anywhere.
> Should it be?

Yes, it should. Proposed text would be appreciated.

> 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.

I've added the following sentence to my working copy:

Because not all service implementations support MUC history management,
a client SHOULD NOT depend on receiving only the history that it has
requested.

> Misc:
> 
> s/"non"/"none"/
> 
> "Nicknames can contain virtually any Unicode character introduces the
> possibility of nick spoofing" - grammar fail.
> 
> s/hte/the/

Fixed.

> 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.

Thanks.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





More information about the Standards mailing list