Hi, I agree with you about the expected behavior. But the behavior when changing the <show/> status is specific to the client implementation and I think this "lock screen" behavior is nowhere specified by XMPP (at best is should be specified in some "best practices" informational XEP or in an "Implementation Notes" section of XEP-0256 and/or XEP-0319, but I am not sure, it's the responsibility of XMPP).
Out of curiosity I just checked my client's behavior, which uses Java AWT to track mouse movement. And fortunately it behaves "correct" (as we'd expect), because java.awt.MouseInfo.getPointerInfo() returns null, while the screen is locked (Java 8, Windows 10), so that the client only switches back to "available", when the screen is unlocked and there are actual non-null mouse pointer values. > Now they claim that is ok with the RFC, and are referencing "4.6. > Handling of Silent Peers" in RFC 6120. As Dave said, this is about broken TCP connections. -- Christian _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
