On 1/22/10 10:31 AM, Dave Cridland wrote: > On Fri Jan 22 17:22:59 2010, Peter Saint-Andre wrote: >> That's nice if you want to check the member list, security clearance, or >> other information before returning disco#items results, but it is out of >> scope for XEP-0045. >> >> > It's the security clearance, mostly in our case, but as a general thing, > it seems vaguely sensible. > > >> > The muc#roomconfig_publicroom option possibly always lists, possibly >> the >> > inverse never lists, and possibly controls listing absolutely. >> >> See above. >> >> > But if it's the latter, then how does one achieve option 3 for a set of >> > rooms? >> >> If you want to do Option #3 in your implementation, that's great, but it >> is a special product feature that you can tout in comparison to your >> competitors. :) > > Right, but if we also want to support muc#roomconfig_publicroom, and > "blind" clients which don't actually parse the form (and there are a > few), then we're a bit stuck. > > The problem is that muc#roomconfig_publicroom is a boolean, whereas it > needs to be a tristate.
I disagree. I think that security clearances and other permissions trump the public room setting in your implementation. Have at it. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
