[ticker-dev] Presence specification draft 0.4.1

[Phillips, Matthew]

> 1. Re Section 3.7 -> Status. Do we need something like 
> 'appear offline'
> or 'invisible' as a standard value. 

Not sure what you would use this for - you can always pretend not to be
there by sending an offline status.

> 2. Is there any provision to specify PRESENTITY's access 
> rules? (nicely
> implemented within msn messenger) 

The access rules would be up to the client.  We do have a Requestor field in
Presence-Request that would allow a client to customize what information is
sent.  I think that to do this properly though, you would need to use
security keys.

> 3. Re Section3.8-> Conflict resolution. Why can't we just accept
> 'most-recent'(based on Presenceinfo.Status_Duration) status as *the*
> valid status value?  

Because clients that automatically mark you "unavailable?" after a certain
period of time could override a previous "online" sent by another client.
In general, if you get two replies to a Presence-Request with the same User,
one saying the person is online 10 mins the other saying they are offline 2
mins, I would say you would still err on the side of assuming they are
actually online, even though the offline is more recent.  This is especially
true with clients that automatically go to "unavailable?" after a period of
inactivity, because then an "online" status is a "positive" indication that
they really are there.

> 4. What will happen to precedence based system (3) if users 
> are allowed
> to enter specific status values ('illegal' as mentioned in Specs) that
> may not necessarily fall between 'unavailable' and 'offline' 

A reasonable way to handle illegal statuses is to assume they mean the same
as "unavailable".

> 5. Re 4 -> Ref. Would be worthwhile to see
> http://www.cs.berkeley.edu/~mikechen/im/docs/rfc2779.txt if haven't
> referred already.  

Done.

Cheers,

Matthew.