RE: On the need for presence service identifiers

I'm very glad that we could come to consensus on this point.

I believe that this eliminates the demand for a presence 'wrapper' that
consists of a small set of headers. The two motivations for this wrapper had
been the need for a notification timestamp header, and the need for a
presence service (or presentity set) identifier. On this latter point, from
other messages to the list I believe we have consensus that this identifier
(were we to grant its existence at all) would not need to exist in a header,
since it would be redundant with the identity of the subject of the
certificate with which the presence information is signed.

Unless I hear anything to the contrary quite soon, I will consider the issue
closed with regard to the base CPIM specification.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Saturday, August 24, 2002 11:49 AM
> To: Peterson, Jon
> Cc: [email protected]
> Subject: Re: On the need for presence service identifiers
> 
> 
> Jon,
> 
> I spent some time trying to devise a passive attack that demonstrates
> the need for notification request timestamps.  Since I failed, I find
> I have no other choice but to withdraw my example.  As a result, I can
> no longer justify my request for timestamped notifications, so I
> withdraw that too.
> 
> John
> 
> "Peterson, Jon" <[email protected]> writes:
> 
> > A few more notes below. Sorry for the length...
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]
> > > Sent: Wednesday, August 21, 2002 6:29 AM
> > > To: Peterson, Jon
> > > Cc: [email protected]; [email protected]
> > > Subject: Re: On the need for presence service identifiers
> > > 
> > > 
> > > "Peterson, Jon" <[email protected]> writes:
> > > 
> > [snip]
> > > 
> > > Maybe this will calm your fears.  Let's look at the big 
> picture.  The
> > > goal is to produce a protocol that meets the requirements 
> outlined in
> > > RFC 2779.  The requirement in focus is 5.2.4 of RFC 2779.
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 



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