Only my two cents...
You should not forget the other side and for e.g. the popular protocols
ICQ and MSN.
In a nutshell both protocols support the Invisible mode (in MSN it's
named appear off-line) and this is only annoying in both protocols.
Take a look at the other side, you have a list full
And Jiří Zárevúcký spoke on 04/23/2009 11:02 AM, saying:
I don't think it's ridiculous. I guards against accidental leaking of
presence.
You can leak for example by requesting users client's version or
service discovery information. I can imagine very little ordinary
users realize it.
You
2009/4/25 Paul Aurich p...@darkrain42.org:
I think it's critical to distinguish user-generated traffic from
client-generated outgoing stanzas. I agree with Will that, for the former,
this is a really frustrating UI and I'd hate my client for doing it.
I think that's exactly the problem in
I think the examples you give are arguably client bugs.
Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAck=C3=BD wrote:
You generate traffic by opening a window.
You don't need to.
You generate it by displaying your contact's information.
Then don't do so unless the contact's already whitelisted (because you
2009/4/25 Will Thompson will.thomp...@collabora.co.uk:
Obviously the client should try not to expose the user without them
doing something that obviously exposes them, so prompting them if they
wouldn't expect to be exposed is reasonable. I think that's what the XEP
was trying to ensure, but
Upon receiving notice that a data packet is cannot be processed by
the recipient, the sender SHOULD consider the bytestream to be closed
and invalid but MAY attempt to correct the error and re-send the
offending data packet using the same sequence number (the recipient
MUST NOT consider a sequence
