Re: Definition of the pres: URI in impp-pres-01

inline.

Derek Atkins wrote:
> Dave Crocker <[email protected]> writes:
> 
> 
>>1. This is supposed to be a minimal system, and that means that the
>>argument "I see no reason why we should not add this feature" is
>>exactly the wrong criterion. The proper criterion is supposed to be
>>"The system will not function without this."
> 
> 
> Well, I have ALWAYS argued that the core system has to deal with
> "mulicase" fanout.  I suspect that for any presentity there will be
> multiple watchers.  If some subset of these watchers are at the same
> locations (same "server"), then I maintain that the notification
> should be "multicast" from the presentity server to the watcher server
> -- one packet over the long-haul link with local fanout.  I've argued
> that since 1998, and I still maintain that today.

Well, there are many tricky issues lurking in such a solution.

First and foremost is security. If we want to provide end-to-end 
encryption of the presence document, how would that be done? Would we 
need to somehow create and manage group shared keys? Egads! Would you 
need to encrypt it N times, one for each watcher? That defeats the 
purpose of your mechanism. Would we need to forsake e2e security? I hope 
not.

Secondly is authorization. What if the presentity wishes for one of 
those watchers to receive the presence document, but not others? Or, if 
it wishes for one of them to receive one subset of the presence 
information, and another to receive a different subset?

The model you are discussing also seems to imply a different 
architecture. There is a bunch of clients, a local aggregation server of 
sorts, and a presence server managing the presentity. Our current CPP 
protocol is built for the more simple case of a client and a presence 
server. There is no notion of this third intermediary, which seems like 
it would need to be incorporated into the protocol.

> 
> 
>>2. Multicast is difficult. One could rather easily argue that
>>large-scale protocol infrastructure that relies on serious multi-cast
>>-- where there is a logical single entity that is handled as an
>>aggregation of sub-entities -- is still a research topic. For example,
>>large-scale acknowledgement of multicast packets does not have an
>>existence proof, as far as I am aware. Research is not the goal of
>>this working group.
> 
> 
> I think it very much depends on your definition of multicast.  What I
> had in mind was a two-layer "local fanout" tree.  For example, a bunch
> of people at MIT are watching someone at CMU.  It would be nice if the
> protocol could send a single notification from CMU to MIT and let MIT
> fan out the messages to the local users.  Yes, I still say "it would
> be nice" because I still don't believe that people understand that
> this is a problem.  But I still maintain it is.  I have since 1998. :)

A problem, yes. It is definitely something you need to help scalability 
in very large systems. But, its significant security implications imply 
its usage in very specific situations where there is strong trust 
between the two domains. I do not think it is ever practical in the 
inter-domain case you describe above.

Even if it was practical, it certainly seems like something which is 
beyond the 'baseline' model we have been following for CPIM/CPP all along.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com




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