On 9/24/11 1:53 PM, Waqas Hussain wrote: > On Sat, Sep 24, 2011 at 2:08 AM, Peter Saint-Andre <stpe...@stpeter.im> 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/
