[Standards] UPDATED: XEP-0186 (Invisible Command)
stpeter at stpeter.im
Wed Sep 12 19:43:04 UTC 2007
Tomasz Sterna wrote:
> Dnia 10-09-2007, Pn o godzinie 14:58 -0600, Peter Saint-Andre
>>> XEP-0186 is just this sh$%^ XEP-0018 in a pretty IQ envelope.
>>> I hate it just as much as presence-invisible.
>> Can you elaborate your reasoning? "I hate it" is not very helpful. :)
> Please do look at both the XEP-0016 and XEP-0186 specs.
> It is spaghetti. So many conditions, corner cases, if this than thats.
> Implementing it is even more horrible spaghetti. The whole presence
> handling pipline needs to be intersected with all these special cases
> handling conditions and tracking.
Sorry about that. We pushed that protocol into RFC 3921 before it was
fully baked, I think.
> And I do not see a reason for this invisibility thingy existence too.
I agree. But that's just me. Some people love it.
> We do not have to mirror patches for deficiencies in legacy protocols.
> We really could do better with Privacy Lists.
I'm sure we could. The question is: do we throw away privacy lists or
develop something better? I don't know if it is worth the time. Or at
least I'm too lazy to work on a whole new protocol.
>>> Maybe it's time to think of Stacked Privacy Lists (more than one PL
>>> enabled at a time) that would make XEP-0126 much more sensible.
>> Yes, we've talked about that for a long time. It's a fairly major
>> change, but it may be worth considering.
> I do not think it is that major change.
> Just a thin layer on top of XEP-0016 with one more advertised feature
> and ability to activate another list without deactivating current.
> Let's consider this (by XEP-0016 2.4. Ex.11):
> <iq from='romeo at example.net/orchard' type='set' id='active1'>
> <query xmlns='jabber:iq:privacy' xmlns:spl='urn:xmpp:stacked-privacy-lists'>
> <active name='invisible-to-all' spl:insert='first'/>
> that would activate list 'invisible-to-all' and insert it on top of
> stack. If a packet passes the first active list it is put through second
> and so on.
Yes, something like that might do the trick.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards