Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Mon, Sep 26, 2011 at 10:55 PM, Kurt Zeilenga wrote: > > On Sep 26, 2011, at 2:36 PM, Peter Saint-Andre wrote: > >>> >>> 5. Both and in a single message >>> >>> "(A message with a and a 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 >>> in it. How should software determine this? Assume it's a >>> subject change if there's no ? What if there is not body, but >>> xHTML-IM is included? What if there's no body, but some >>> ? >> >> IMHO a subject change should be a message with *only* a child >> element and no other children. > > I think one ought to allow for extension elements in the subject change > message. For instance, say the subject change message is delayed at an > occupant's server, which hence adds a element. Hence, I think it > should be a child with a . I don't mind if it has other children than , but existing implementations require there to be no on a subject change, and I see no reason to break them at this stage. /K
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Sep 26, 2011, at 2:36 PM, Peter Saint-Andre wrote: >> >> 5. Both and in a single message >> >> "(A message with a and a 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 >> in it. How should software determine this? Assume it's a >> subject change if there's no ? What if there is not body, but >> xHTML-IM is included? What if there's no body, but some >> ? > > IMHO a subject change should be a message with *only* a child > element and no other children. I think one ought to allow for extension elements in the subject change message. For instance, say the subject change message is delayed at an occupant's server, which hence adds a element. Hence, I think it should be a child with a . -- Kurt
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
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 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 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 is different from sending it to the Occupant JID (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 and in a single message > > "(A message with a and a 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 > in it. How should software determine this? Assume it's a > subject change if there's no ? What if there is not body, but > xHTML-IM is included? What if there's no body, but some > ? IMHO a subject change should be a message with *only* a child element and no other children. > 6. action nick and jid for kicks and bans > > Examples 85 and 108 have been updated from to > , 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 changed to ref='item' minOccurs='0' maxOccurs='unbounded'/>, to allow one > 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., xmlns='http://jabber.org/protocol/muc'/>) in the 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 f
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/24/11 1:53 PM, Waqas Hussain wrote: > On Sat, Sep 24, 2011 at 2:08 AM, Peter Saint-Andre wrote: >> On 9/20/11 6:00 PM, Evgeniy Khramtsov wrote: >>> On 20.09.2011 08:46, Peter Saint-Andre wrote: On 9/19/11 4:40 PM, Alexander Holler wrote: > > No, but maybe adding some muc-features which are making it obvious what > is supported by the server is an option. I don't know if there is an > implemention which supports e.g. those voice-requests as described, > those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Peter >>> >>> We have a patch and we are going to include it in the new ejabberd >>> version. Please don't remove the feature from the spec. >> >> Cool, thanks for letting us know. I won't touch that part of the spec. :) >> > > I note that this feature has no disco feature defined. MUC does not have the plethora of disco features that PubSub has. You decide whether that's a good thing or a bad thing. > Given that > no-one seems to have deployed this yet, we need a way to discover > support. Do we want or need to define fine-grained disco features for XEP-0045? And if so, why limit the new features to just this one? > I propose the features http://jabber.org/protocol/muc#request and > http://jabber.org/protocol/muc#register > > Also, it's worth considering moving this (nick register, registration > approval, voice request) out of XEP-0045, and into an XEP of its own. > As far as I see, MUC implementations have up until now treated this is > an optional secondary part of the main MUC spec. The new XEP could > also include text about service-level nick registrations, which is > what it currently implemented and deployed, and can have interesting > interactions with room-level registration. I like the idea of slimming down XEP-0045 to the extent possible. > I do intend to implement these in Prosody. Thanks for letting us know. > P.S. An important thing in this is the room requesting additional > information. One obvious example is captcha support. How should that > flow? The room should send a captcha form IQ-set or message to the > requester? Those are good questions. I don't have the answers, but it might be easier to work out the answers if we put this feature into a separate spec. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Suggestion for XEP-0045 : permit alias for the MUC address
On 9/24/11 12:14 PM, Kim Alvefur wrote: > I think it would be better to say "this room has moved". There is > mention of something like this in the section on destroying rooms[1], > but it's not mentioned how you should inform someone joining after the > room has been destroyed about the new location. > > Current implementations (AFAIK) forget about the old room being > destroyed and let anyone create, and become owner of, a room named the > same as the old room. I can imagine this not being optimal sometimes, > possibly even a security issue. > > How about some clarification, like saying you should send the > same /presence@type=unavailable/x/destroyed stanza as when the room is > destroyed. And maybe we should discourage implementations from letting > anyone recreate the room for a while? > > [1]: http://xmpp.org/extensions/xep-0045.html#destroyroom I think the MUC service would return a stanza error: http://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-gone Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] XEP-0306: MUC status codes
After last week's XMPP Council meeting, a few folks had a discussion about MUC status codes (XEP-0306)... http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110921/#16:22:29 Ralph Meijer's point was that it would be good to use the same kind of approach we followed for core stanza errors. So instead of what we have in XEP-0306 right now: We could define each new condition element as a child of the related status code: This would enable us to eventually get rid of the 'code' attribute, just as we did for stanza errors. I rather like that idea so I plan to update XEP-0306 accordingly. (Dave Cridland brought up a separate issue, which is that many implementations don't support more than one element in MUC presence, for example reading/showing only the first or the last instance. But that's a separate issue...) Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] Fwd: Minutes 20110921
FYI -- Forwarded message -- From: Kevin Smith Date: Mon, Sep 26, 2011 at 9:14 AM Subject: Minutes 20110921 To: XMPP Council Minutes for Council meeting 20110921. Room logs: http://logs.xmpp.org/council/110921/ 1) Roll call Matt, Matt, Kev present, Ralph absent (arrived after meeting concluded). 2) Move XEP-0260 to Draft? +1 3) Move XEP-0261 to Draft? +1 4) Accept XEP-0249 version 1.2? +1 5) http://www.xmpp.org/extensions/inbox/account-management.html - accept as XEP? Much discussion about whether this approach was sufficiently wrong to block publication. Agreement to start a discussion on the standards@ list to gauge community opinion and revisit after list discussion. 6) Replace Fritzy. Agreement it's not worth re-filling Fritzy's Council spot, given it'd take as long to fill it as there is time left in the term. 7) Date of next meeting 2011-09-28 1500GMT. 8) Any other business. Kev remembers that he agreed to produce statistics on attendance for members@ at the end of Council term, which is approaching. Fini
