RE: Presence service basics

> Subjects possess private keys.  One of the reasons I must define some
> terms is because RFC 2778 does not have a term for the things that
> possess private keys.  In particular, both PRINCIPALS and PRESENCE
> SERVICES may possess private keys.

Is there any reason that a PRESENTITY may not possess a private key?

Strictly speaking, our scope is the communication among PRESENTITIES,
PRESENCE SERVICES, and WATCHERS.  RFC 2778 is pretty clear about the idea
that PRINCIPALS and the various USER AGENTS are defined primarily so as to
have some terms to describe aspects of the "real world" outside IMPP.

The PRESENTITY is defined as the source of PRESENCE INFORMATION, not the
PRINCIPAL.  I think this is fairly consistent across all group documents.

> RFC 2778 presents a model for presence service in which there are
> three kinds of operations and two kinds of objects.  Objects are
> either PRESENTITIES or WATCHERS.

It's hard for me to reconcile the above two sentences with section 2.1 of
2778, which says

   The PRESENCE SERVICE has two distinct sets of "clients" (remember,
   these may be combined in an implementation, but treated separately in
   the model).  One set of clients, called PRESENTITIES, provides
   PRESENCE INFORMATION to be stored and distributed.  The other set of
   clients, called WATCHERS, receives PRESENCE INFORMATION from the
   service.

Somehow "clients" that "provide" or "receive" information don't seem very
much like "objects" that are "operated on" by "subjects."

I think it's fine to critique 2778 if it doesn't provide the tools/terms we
need to make progress on understanding your concerns.  But let's critique it
for the model it actually describes, not substitute a different one as a
"summary."

--Mark




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