On Thu, Jul 21, 2011 at 4:23 PM, Matthew A. Miller <[email protected]> wrote: > > On Jul 21, 2011, at 08:39, Peter Saint-Andre wrote: > >> On 7/21/11 8:37 AM, Kevin Smith wrote: >>> On Thu, Jul 21, 2011 at 3:28 PM, Dave Cridland<[email protected]> wrote: >>>> On Wed Jul 20 23:00:33 2011, Matthew A. Miller wrote: >>>>> >>>>>> If there is only one resource online and the resource updates presence >>>>>> but remains available. >>>>>> >>>>> >>>>> This seems reasonable. >>>>> >>>>>> If the locked resource updates presence but changes only<status/>. >>>>> >>>>> I don't agree with this one. There are clients that, most often at the >>>>> explicit direction of their users, only update<status/>. >>>> >>>> Well, I think that's the point, and it's fine to stay locked. If the change >>>> of any informational aspect of presence has to cause unlocking, then you >>>> should be mandating unlocking on several PEP events, too. >>>> >>>> But we don't have to agree, here - just give the first case above as a "for >>>> example", and note that it's always safe to unlock. >>> >>> I'll go further than this, I don't think we can claim it's a best >>> practice to unlock on text-only presence changes. >>> >>> I'd suggest something along the lines of: SHOULD unlock on any change >>> of availability (e.g. changing from away to available) and MAY unlock >>> on other presence changes (e.g. where the text changes). >> >> Sounds right to me. >> > > No, sorry, it's not right at all. > > Like I said, there are a significant enough number of clients/users that will > use status and only status to indicate change in availability. Whether > that's right or not can be debated, but this line **WILL** break behavior for > a number of people, and there's no sure fire way to detect such behaviors.
The line can't break anything - clients that already unbind on any change can continue to do so. I don't think the right thing to do is to mandate this behaviour, though, because it makes the experience worse for users who do sensible things with their presence/have sensible clients for the benefit of those that don't. It would be worth having, potentially, a section in the XEP about presence updates and changing availability when the user changes availability, such that things are unlocked. By far the most common case is either a new client coming online, or a client that was previously auto-away coming back from away, I think, and either wording addresses this. If we start considering clients that do silly things, we'd have to consider MUST NOT change on presence without availability changes, to deal with clients that include User Tune in the presence text. /K
