Presence and IntComm WG

[Candace Holman <>]

Hi Dennis,

As we begin our trek down the road of the existential, I'd like to 
discuss the multi-source ambiguity of presence as it was addressed in 
Jonathan Rosenberg's July 2005 SIMPLE Presence Data Model update, 
sections 3.5 "Modeling Ambiguity", 3.6 "The Meaning of Nothing", and 3.7 
"Status vs. Characteristics" .  This draft was written to guide the 
research on the types of questions we ask in this email thread: 
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-03.txt  


In the draft, presence is addressed by Person, Service, and Device.  In 
section 3.5, Modeling Ambiguity, the difficulty is named - should it be 
the watcher (application, human, etc.) or the agent (generally 
automated) that merges conflicting presence information?  Sounds like 
philosophy but there are some technical recommendations.  The 
service/device/person occurrence can be uniquely identified with an 
occurrence identifier and tracked.  But to resolve ambiguities, the URI 
should not be used as the occurrence identifier. With presence agents, I 
think this means that a user agent URI should not be allowed to login to 
a server more than once. After the first login, subsequent logins should 
overrule the previous occurrence identifier. Without this, location 
tracking is not possible.  Additionally, and especially in a 
peer-to-peer case, when all else fails, the timestamp on the presence 
update document can be used by either server or peer to resolve the 
ambiguity.  What do you think?

In section 3.6, The Meaning of Nothing, Rosenberg describes how the 
absence of a particular presence attribute conveys no information about 
that attribute. It may be absent because of privacy requirements or it 
may be absent because the feature is not supported.  He suggests that 
the less presence attributes there are, the less value we can attach to 
a presence record, so the more the better.

In section 3.7, Status vs. Characteristics, he addresses an unforeseen 
flaw in the original PIDF specification - the presence information 
record contains status, device, and person.  Device and person cannot 
have their own status, they must be coupled and share a status.  
Location is regarded differently - device and person can have different 
locations.

To answer your question about the Refresh Interval on EyeBeam, that 
variable indicates how long you want your subscription to the presence 
agent to last.  I would like to see EyeBeam produce an error message 
when the subscription expires and you then try to update your contact 
list or your own presence, but I don't think it's a requirement to 
automatically resubscribe.  I think that's a privacy issue.

Candace

Dennis Baron wrote:

> I agree that we should be trying to figure out how to deal with
> multiple sources supplying presence information.  I also agree with
> Mike that this isn't going to be an easy problem to solve. Does anybody know what other 
> services are doing?  I know that when I "log into" AIM from two different 
> places it asks both instances if they want to disconnect the other one.  I haven't 
> tried not doing that.
>
>
>  said:
>  
>
> > I wrote that you should set the Presence Agent Refresh Interval to 10 
> > seconds.  I assumed that this was the same as the refresh rate for 
> > presence updates, but it is not.  This is actually the maximum time that 
> > you will remain subscribed to do presence updates with your server. 
> >    
>
> I'm a little confused about what this variable is.  Is the client
> telling the PA to "subscribe to my presence" with an Expires of N
> seconds?  If that's the case shouldn't the PA be resubscribing before
> that interval expires?
>
>                         Dennis
>