Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)
On 07.03.2017 12:31, Jonas Wielicki wrote: I would like a rationale for why after going visible again, the session is treated as before sending initial presence. This feels counter-intuitive to me: I would expect all my contacts to see the presence I most recently sent to those on my "visible list". While a client can surely implement it that way, is there a rationale to not have it specified that way by setting the outbound presence to the most recently sent during invisibility? This thing I actually liked the most - very elegant, just send the presence you want to be after invisible. In the client it's simple (just re-send current presence). In the server it's simple (just broadcast and send probes). I believe the rationale is consistency of the presence state. If server just rebroadcast last cached presence (even of cached for this connection) - it wouldn't be proper presence state since some(most?) implementations may stop sending presence once they received 'unavailable'. And they are not obliged to re-send it on receiving the new one. So you may write - server must broadcast and probe but... this is what happens on initial presence. What does a server do when a client does not send a after going visible when asked by peers to which the client has sent directed presence vs. those to which the client has not sent directed presence? If we follow XEP-0016 way - literally nothing. Directed presence is special case anyway, and is required to be tracked regardless the visibility. Secondly, what is the state of the Privacy Lists if they are used as a backing store after the client goes offline during invisibility? Are those reset automatically? This could use some clarification. Invisibility is quite straight-forward command. It's just one priv.list item - presence-out. (if we ignore probe thingy). So = hence to set is to add such item (auto-creating active list if necessary) and to unset is just remove any such item (autodeleting empty active list if necessary). The same semantic as being using in blocking commands. Just with active list instead of default. But yes, probe thingy. That changes the whole picture. Meaning normal priv.list backend can not be used as is, should be modified/extended to account for probe blocking (which is impossible with priv.lists - except total blackout case). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)
On 07.03.2017 12:31, Jonas Wielicki wrote: > On Dienstag, 28. Februar 2017 16:27:59 CET XMPP Extensions Editor wrote: >> This message constitutes notice of a Last Call for comments on XEP-0186 >> (Invisible Command). >> >> 4. Do you have any security concerns related to this specification? > > The Security Considerations section is very vague. While I can imagine some > of > the scenarios hinted at, I think that mentioning some cases would not hurt. > Examples I am currently thinking of are disco#* (or all IQs to the client in > general) and Message Delivery Receipts. I’m sure there is more. A presence leak is a generic XMPP security consideration which should be handled in one canonical place, possibly put in one of the RFCs, and not in one of the 300+ XEPs. Then XEP-0186, and other relevant XEPs like the Message Delivery Receipts one, could point to that canonical place. Unfortunately I only found RFC 6120 § 13.10.2 which discusses the service's responsibility. Maybe it is worth to write an extra XEP for this until 6120bis arrives? - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)
On Dienstag, 28. Februar 2017 16:27:59 CET XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0186 > (Invisible Command). > > Abstract: This document specifies an XMPP protocol extension for user > invisibility. > > URL: https://xmpp.org/extensions/xep-0186.html > > This Last Call begins today and shall end at the close of business on > 2017-03-14. > > Please consider the following questions during this Last Call and send your > feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol stack or > to clarify an existing protocol? Yes. > 2. Does the specification solve the problem stated in the introduction and > requirements? From reading it, it appears so. > 3. Do you plan to implement this specification in your code? If not, why > not? Yes. > 4. Do you have any security concerns related to this specification? The Security Considerations section is very vague. While I can imagine some of the scenarios hinted at, I think that mentioning some cases would not hurt. Examples I am currently thinking of are disco#* (or all IQs to the client in general) and Message Delivery Receipts. I’m sure there is more. > 5. Is the specification accurate and clearly written? I would like a rationale for why after going visible again, the session is treated as before sending initial presence. This feels counter-intuitive to me: I would expect all my contacts to see the presence I most recently sent to those on my "visible list". While a client can surely implement it that way, is there a rationale to not have it specified that way by setting the outbound presence to the most recently sent during invisibility? What does a server do when a client does not send a after going visible when asked by peers to which the client has sent directed presence vs. those to which the client has not sent directed presence? Secondly, what is the state of the Privacy Lists if they are used as a backing store after the client goes offline during invisibility? Are those reset automatically? This could use some clarification. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
