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). /K
