Subject: RE: [Simple] 200 vs. 202

From: Michael Hammer <[email-masked]>
Date: Tue, 20 Nov 2001 10:15:07 -0500

Jonathan and others,

I have seen in this latest thread a lot of "assumptions" regarding "reach 
any" and "reach all" that seem to have an effect on how the involved nodes 
operate.  May I suggest that if a proxy decides to change a "reach one" 
request into something else, that it should also indicate that in the 
message itself.  Then at least the nodes attempting to "aggregate" or 
"choose best" or "handle one response" would be more clue-full.  It might 
also be useful for the node that creates the forking problem to make sure 
it is in the return path and take responsibility for handling the 
responses.  But, perhaps that is too much to hope for (too constraining).

Mike

At 12:24 AM 11/20/2001 -0500, Jonathan Rosenberg wrote:

>
>
> > -----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