RE: Presence notification security - catching up

More gently, I think the consensus of the group is that this is not in our
initial problem space. This doesn't mean that it is unimportant. There are
good reasons to be skeptical about global end-user PKI enrollment, and trust
delegation/federation is the most promising alternative. I have no doubt
that we will go on to address this requirement after we have finished with
our current round of requirements. I'll also try to make sure that the
wording in CPIM doesn't unnecessarily close any doors in this regard that we
might like to have open later.

Unless I hear otherwise soon, I'll assume this issue (broadly, what has been
called 'presence service identifiers') is closed for the current round of
the core CPIM specification.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Monday, August 26, 2002 4:38 AM
> To: Adrian Bateman
> Cc: [email protected]
> Subject: Re: Presence notification security - catching up
> 
> 
> Adrian,
> 
> It appears to me there is a consensus by this group that there be no
> standard way to identify the set of presentities associated with a
> given domain.  I have described a reasonable IMPP compliant
> architecture that becomes difficult to implement in the absence of
> presentity set identifiers.  There appears to be a consensus by this
> group not to care about implementations that use one server to provide
> presence notifications for every presentity within its domain.  It is
> time for me to drop this issue without agreeing to the consensus.
> 
> "Adrian Bateman" <[email protected]> writes:
> 
> > In other words, the 'minimalist' approach is that we only include
> > what is necessary to make a workable 2778/2779 compliant protocol,
>                               ^^^^^^^^
> > but it does mean making some choices that remove ambiguity.
> 
> But the protocol won't work for implementations that use one server to
> provide presence notifications for every presentity within its domain.
> 
> John
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 



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