On 05/06/2008 1:50 AM, Ralph Meijer wrote: > On Mon, 2008-05-05 at 15:52 +0200, Tomasz Sterna wrote: >> Dnia 2008-05-05, pon o godzinie 07:35 -0600, Peter Saint-Andre pisze: >>>>> http://www.xmpp.org/extensions/xep-0186.html >>>> I prefer: http://www.xmpp.org/extensions/xep-0126.html >>> Or something. :) >>> >>> Let's get consensus on an approach that works so we can stop talking >>> about <presence type='invisible'/> because that monstrosity will never >>> be standardized. >> If XEP-0018 (Invisible Presence) is such a monstrosity, why do you >> propose XEP-0186? >> These are after all nearly the same. The only difference is the switch >> that turns the invisible mode (IQ instead of PRESENCE). >> It requires the same as XEP-0018 (or even more) special casing in >> presence handling and is similarly horrid to implement. > > Any form of invisibility will require special casing in presence > handling by the server, no? I believe XEP-0186 could be mapped to the > same backend as Privacy Lists, and is just a protocol short-hand for > XEP-0126 in that case.
Yes that seems reasonable. > I am with Peter that adding new types to one of our three Stanza kinds > is not the proper way to solve this problem. First of all, we extend > through namespaces. Second, an iq is an ideal way to ask the server to > process something differently for you, in this case, how it handles > presence distribution. I think it is a nice separation of concerns. If we were defining presence from the start, maybe we would include type="invisible", but it was not something we defined in the beginning and it has always been a kind of ugly stepchild. Either we can try to dress up the ugly stepchild or use something that is functionally equivalent, which I think the IQ approach is. > My only concern with XEP-0186 is the security considerations section, > which advises not to reply to IQs. I don't think that is proper. If the > intend is for the client to not respond to incoming IQs, the server > should respond on behalf of the client. XEP-0126's security > considerations mention this nicely. You're right, I will clean that up. AFAIC, the fundamental problem here is that no one is excited enough about invisibility to stand up and say "yes I love and need this feature and I will implement Spec X in the next 3 days if we can agree that it's the right way to go". Whenever I sense a lack of enthusiasm, I hesitate about pushing something forward. But sometimes the only way to get consensus is to ask for a Last Call, so perhaps that's in order soon... Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
