Subject: RE: [Simple] 200 vs. 202

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Dec 2001 12:04:14 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 4:59 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]; 'Brian Stucker'; simple
> Subject: Re: [Simple] 200 vs. 202
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:[email-masked]]
> > > Sent: Tuesday, November 27, 2001 8:40 AM
> > > To: [email-masked]
> > > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; simple
> > > Subject: Re: [Simple] 200 vs. 202
> > >
> > >
> > > OK. Thanks for the tutorial - I think I get it now.
> > >
> > > But, all the complexity and loose ends suggests to me 
> that there is
> > > something fundamentally wrong with the mechanism here.
> > 
> > Well, the problem is that we are trying to add forking 
> capabilities into a
> > method thats not ideally suited for it.
> 
> Can't argue with that. It's unfortunate that we have a 
> forking mechanism
> that really only works for INVITE even though it is defined for other
> methods and (as we see here) is potentially wanted/needed for them as
> well.

Well, there are some who think it doesn't work for INVITE all that well
either ;)

Its not clear that you really want it in this scenario, to be honest. If you
did, I might argue that we would need to define a "session presence" model
that used INVITE to establish a presence session with a peer, with the SDP
containing a place to send notifies..... I am not proposing that, mind you.

> 
> > Given the frequency that I
> > realistically expect to see forking SUBSCRIBE, I am not too worried.
> 
> As devices are deployed that support presence, it seems like there
> could develop a problem with undesired forking. You want forking
> for invites, and perhaps don't have any simple way to prevent
> forking of subscribes as well.
> 
> This won't be a problem if the presence function is combined with the
> registrar function and driven off registrations. 

It has nothing to do with being driven off of registrations; it has to do
with whether the PA function is network or UA located. 

> But it will be a
> problem with devices that want to handle presence themselves, like the
> MS endpoint. All you need is people with both a desktop and laptop
> machine that try to maintain one identity for both.

Well, I have argued that for these cases, you just need to impose the
restriction that if you want multiple end system based-PA, you need to have
an aggregation point somewhere in the network. No system today allows for
multiple independent clients to generate presence data for a single
identity, LET ALONE having them do it without a server. So, user and network
admin. expectations are already far below what we can do.

> I won't stop progress by continuing to argue, but I don't find either
> solution very appealing. 

I welcome an alternative workable proposal, as always....

-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