On Fri, Apr 12, 2013 at 10:58 AM, Christian Vogler <[email protected]> wrote: > I agree - we are all on the same page with respect to randomization, I > believe. Just a couple of things: > > 1. In the face of multiple sign-ons, the clients have different full JIDs > (or at least, they should). If there is a JID mismatch I treat it as a RTT > message from a different login and as a loss of sync until the next message > refresh. It seems that Section 6.6.4.2 encourages this - so maybe it would > make sense to make this more explicit as part of the processing rules?
Yes, a JID switch can treated as a valid "loss of sync" condition for a client that keeps track of only one real-time message per window. However, there are situations (e.g. Multi-User Chat) where you definitely do want to display multiple real-time messages in the same window even for simultaneous logins. I leave it to the implementor to decide. Generally, clients that support MUC, would easily be able to also support concurrent real-time messages coming from separate full JID's of the same sender. > 2. I like having a 2**30 space for randomization, rather than 2**20 because > it makes the sequence a bit more unpredictable. I don't know if it it ever > will make a difference, but it's one of those things that reduce potential > attack vectors, and this, in my view is worth the tradeoff of having a few > extra bytes for the decimal representation of the sequence number with the > larger space. RIght. Though, the bounds of randomization is not mentioned, this is left as an implementer decision. Thanks Mark Rejhon
