On 8/12/11 4:49 PM, Waqas Hussain wrote: > On Sat, Aug 13, 2011 at 1:37 AM, XMPP Extensions Editor > <[email protected]> wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Extensible Status Conditions for Multi-User Chat >> >> Abstract: This document defines an extensible format for status >> conditions in Multi-User Chat, similar to the error format used in >> the core of XMPP. >> >> URL: http://www.xmpp.org/extensions/inbox/mucstatus.html >> >> The XMPP Council will decide at its next meeting whether to accept >> this proposal as an official XEP. >> > > Is this intended to remain as a separate XEP, or will this be merged > into XEP-0045? I hope the current status codes are going to go away.
Eventually, yes. But it took us 5+ years to deprecate the core error code numbers. I'd expect a similarly slow progression here. >> 102 <unavailable-shown/> >> 103 <unavailable-not-shown/> > > I admit to not being aware of these. How do these work? I see them > in the status codes registry, but nowhere else. If they don't work, > then we shouldn't have them in the new XEP. They're used in at least one implementation -- basically, members who are not in the room can be shown as in the room. > Codes 170 to 174 in MUC were specific to configuration change, but > I'd like these to be sendable by the service outside of > configuration change (e.g., on room join). > >> 100 <realjid-public/> >> 172 <non-anonymous/> > > <real-jid/> is redundant. <non-anonymous/> can be used in its place. > If the client really wants to know whether this is a new > configuration change, it can just detect <configuration-changed/>. Currently, 100 is used on join and 172 is used if the room configuration changes such that the room is now non-anonymous. So there is a distinction, but it might be a distinction without a difference. Peter -- Peter Saint-Andre https://stpeter.im/
