Re: On the need for presence service identifiers

"Mark Day" <[email protected]> writes:

> I guess I'm a little confused here because your conceptual model and terms
> don't seem to align with RFC 2778.

Let me rephrase my question.  A PRINCIPLE, in this case a person, uses
a PRESENCE USER AGENT to sign and deliver presence information to a
PRESENTITY.  The PRINCIPLE's private key used for signing is on the
same laptop as the PRESENCE USER AGENT.  The PRINCIPLE goes away for a
week, and takes the laptop.  The PRESENCE USER AGENT is no longer able
to sign presence information updates.

> In particular, I can't tell whether you're concerned about principals or
> presentities going away. 

I am concerned about a PRESENCE USER AGENT, which has access to a
private key, going away.  As near as I can tell, a PRESENCE SERVICE
can combine a set of PRESENTITY's within an implementation, so saying
that a PRESENTITY will sign PRESENCE INFORMATION can be interpreted as
saying that a PRESENCE SERVICE will sign.  But you excluded the idea
that the server is signing.

> Even if a principal is "going away for a week",
> that principal can still arrange for a corresponding presentity to supply
> hourly refreshes of their "I'm away" information if that's what they want.
> I'm not saying that everyone's implementation will support that, but there's
> no logical impediment to having that functionality if it's desired.
> 
> >From the perspective of the presence service, the presentity is the source
> of the presence information, and the part of the system doing the signing of
> that presence info... isn't it?
> 
> --Mark

John



  [reminder: [email protected] for non-technical discussions, please]