RE: On the need for presence service identifiers

I think Mr. Day is correct here that the RFC2778 model does not support the
contention that a presence services ever generates presence information -
even in the absence of a principal. A presentity is the only generator of
presence information in RFC2778. What I think Mr. Ramsdell means by a
'presence service', as I suggested a couple days ago, is some sort of
distributed presentity. The need for a presence service identifier must be
evaluated in the context of Mr. Ramsdell's definition, but I believe that
the authors of RFC2779 rejected the idea having exactly this sort of
identifier, as section A5 of the Appendix suggests.

I also think Mr. Day is correct that if presence information has a timestamp
that indicates when it was created, there could also be a time after which
it is considered not to be valid any longer - either an explicit indication
(an expiration time, which creates as Mr. Day suggests a lease) or an
implicit indication, one built into the protocol that expires presence
information after a given interval. Without one of these two it is difficult
to see how the protocol could handle a case when a presentity crashes
ungracefully.

When a presentity is off-line, and therefore unable to report its status at
all, I think other clients should consider it to be 'off-line'. I would have
thought this was obvious. There is no need for anyone to sign presence
information on behalf of a presentity that is off-line.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Mark Day [mailto:[email protected]]
> Sent: Thursday, August 22, 2002 9:15 AM
> To: [email protected]
> Cc: [email protected]
> Subject: RE: On the need for presence service identifiers
> 
> 
> I guess I'm a little confused here because your conceptual 
> model and terms
> don't seem to align with RFC 2778.
> 
> In particular, I can't tell whether you're concerned about 
> principals or
> presentities going away. 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
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Thursday, August 22, 2002 8:41 AM
> > To: Mark Day
> > Cc: [email protected]
> > Subject: Re: On the need for presence service identifiers
> >
> >
> > This proposal has some interesting properties, but I don't 
> understand
> > how presence information is refreshed.  Suppose the standard lease
> > duration is one hour, and the person that owns the presentity goes
> > away for a week.  That person can no longer sign presence 
> information
> > updates.  The alternative is that the presence service signs the
> > messages, but your note suggests you do not intend this.  Who signs
> > presence information when the person is away?
> >
> > John
> >
> > "Mark Day" <[email protected]> writes:
> >
> > > I think I understand this, and agree that it is a potential
> > vulnerability. I
> > > disagree about its likely practical importance and the proposed
> > solution.
> > >
> > > If I were particularly concerned about foiling this attack, I
> > would change
> > > the timestamps in the presence information to leases -- they
> > would have a
> > > start-time and an end-time, or a start-time and a duration. The
> > presentity
> > > could choose the length of lease so as to trade off the 
> interval during
> > > which this attack is possible vs. the inconvenience of refreshing
> > > otherwise-unchanged presence information whose lease has expired.
> > >
> > > I believe this approach would solve the identified problem
> > without the need
> > > to introduce the machinery to name, authenticate, etc. 
> etc. the presence
> > > services and individual notifications.  But I may have
> > overlooked something,
> > > so I'd welcome correction.
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 



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