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 <stpe...@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@service> is different from sending it to the Occupant JID <room@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@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/
