On Aug 21, 2011, at 04:24, Kevin Smith wrote: > I've been thinking about 296, and I'm still not happy with this > 'unlock on any presence even if it's irrelevant' thing. > > My preference is to say something like: > SHOULD (or MUST) unlock on a change of availability (available/FFC <> > Away/NA <> DND <> unavailable) and MAY unlock on other changes. > > The current text, and Matt's preference is: > MUST unlock on ... any <presence/> update. >
My preference is based on experience. Not everyone has interpreted the use of <show/> the way we do. However, things did get slightly clearer between RFC 3921 and RFC 6121. As implementations are updated, this will hopefully be less of a problem. If we do make a change, it MUST also take <priority/> changes into account. But at that point, is a client starting to reproduce some of the server's own routing rules? Maybe unlocking on any presence update (which, according to RFC 6121 § 4.4.1, SHOULD only to be signal a change in availability) is more appropriate. > My argument is that unlocking on all presence will result in many > messages being sent to the bare JID unnecessarily, which creates a bad > experience for any users of multiple concurrent sessions and is > exasperated by the clients putting extra details into their presence . > It's not just clients putting extra details in. There are a number of gateways into XMPP, and not all of them change show. If I recall correctly, this behavior is often exhibited if the other end is MS Lync (SIP-like) or IBM SameTime (SIMPLE). Note that both have XMPP server-to-server connectors. > Matt's argument is that there exists a client that encourages people > to never change availability and that it's more important to address > this case. I guess I don't say more important, but that we be cognizant these clients (and gateways). Also, a re-read of RFC 6121 seems to lead to a broader rule. > > My suggestion to resolve this is to add a 'requirements' section to > the start of XEP-0296 explaining what the objectives are. If we can > agree on objectives, the rest should flow out sensibly. I've been thinking of what to put there. I am open to suggestions, but it MUST to take the existing reality into account. - m&m <http://goo.gl/voEzk>
