Subject: RE: [Simple] 200 vs. 202

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Nov 2001 00:24:54 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 19, 2001 7:04 PM
> To: 'Brian Stucker'; adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R,
> ALCTA; Paul Kyzivat
> Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai
> (c)'; 'Brazier Lachlan'; 'simple'
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> Part 2... note that I'm addressing multiple presence sources
> specifically here, **not** the general SUB/NOT forking problem
> (that was my previous mail).
> 
> Perhaps I'm being daft, but I can't see what is so complicated
> about merging state received from two different sources,
> GIVEN THE WAY THE CPIM PRESENCE FORMAT IS DEFINED.

The problem is not that it cannot be done, the problem is that it cannot be
done within the policy constraints of the PA. Creating an aggregate presence
document is more than just a union operation, its also a filtering operation
which removes/modifies depending on lots of things. That kind of processing
can only rationally happen at a PA in the presentity's domain. This is why
we have 481'd extra NOTIFY's from the very beginning - we are trying to keep
the composition function in the presentity domain.

> I've given it a bit of thought, and (for presence, at least), can
> really see only two open issues if we allow multiple PUAs to be
> established by an initial SUBSCRIBE:
> 
> - How do we ensure that the presentity ID is unique? (We could fix
>   this by requiring GUIDs or similar), and
> 
> - How do we make sure that we don't get information about a particular
>   presentity from more than one source (e.g. an endpoint PUA and a
>   concentrator) -- or, if you do (and they are in conflict), how do
>   you sort out which is authoritative? The answer to this 
> isn't as trivial,
>   but I can think of several easy-to-implement schemes that would make
>   this work out just fine.
> 
> Neither of these are showstoppers. The first one isn't even difficult.

Agreed. I don't see these as a real problem.

> 
> That said, there have been several intelligent people on this list
> insisting that there are hordes of intractable problems that prohibit
> merging state at the subscriber end, so I must be overlooking 
> something
> massive. It would be instructive -- and probably more conducive to
> progress -- if people would argue their points in specific terms (such
> as detailing individual problems, like the two I describe 
> above) instead
> of just calling the entire problem set "difficult" and throwing their
> hands up.

Well, beyond the one above, which is very much presence specific, Robert
raised some issues that I had not thought of which were not specific to
presence:

http://mailman.dynamicsoft.com/pipermail/simple/2001-November/001052.html

I am not sure the DoS one was ever resolved; it may not be a big issue. The
one about authentication requiring the same number of proxies seemed a
serious one, with no clear solution. James had proposed something:

http://mailman.dynamicsoft.com/pipermail/simple/2001-November/001070.html

but it had many issues, as he himself indicated.

At this point in time, I am really eager to just keep things simple, and not
worry about problems that we don't need to. It is much easier, IMHO, to
simply assume that the client does not need to do aggregation, than to
assume it may need to. Since we have no clear requirement or need to solve
this broader problem, why bother?

-Jonathan R.

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

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple