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. - m&m
smime.p7s
Description: S/MIME cryptographic signature
