Subject: RE: [Simple] 200 vs. 202

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 19, 2001 5:43 PM
> To: 'Jonathan Rosenberg'; [email-masked]; 'Brian 
> Stucker'; 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
> 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > 
> > Forking works fine if you want to reach any one of N things, 
> > but thats not what is desired here. I don't think we should 
> > deprecate forking for non-INVITE...
> 
> Your arguments aren't internally consistent.

I never make any guarantees about the internal consistency of my arguments
over time ;)

> 
> (a) INVITE is the only request for which the response is allowed to
>     take an arbitrarily long period of time. All other requests must
>     receive a response pretty much immediately.
> 
> (b) Many Non-INVITE requests cannot be cancelled. Even if they can be
>     cancelled, CANCELs will usually fail (arrive too late) 
> because of (a).
> 
> (c) Because of both (a) and (b), any forked non-INVITE request has an
>     extremely high chance of succeeding at all reached endpoints.
> 
> (d) Because of (c), any forked non-INVITE request acts as a "reach all
>     of" request instead of a "reach any of" request.

I think you are misunderstanding what I meant by "reach all". Of course it
will reach all endpoints for the reasons you describe above. By "reach all",
I meant that each of the things I could contact is different in some way, so
that I need to have a dialog set up with all of them in order for things to
properly work. In other words, "reach all" would mean that the presence
state of the presentity is distributed, in a non-overlapping way, across N
PUA, and I need to get presence data from all of them for me to get a
correct view of the presentity state. By reach any, it means that the
request hits all N endpoints, but that I only need to talk to one of them in
the end to get the information I want. My apologies for a poor choice of
terms.

> 
> (e) By (d), your asserting that forking of non-INVITEs is 
> okay necessarily
>     means that you are accepting a "reach all of" semantic 
> for forking --
>     but you already asserted that this is a Really Bad Thing.
> 
> Given the forgoing arguments, I believe we have precisely 
> three solutions
> to this problem:
> 
> 1. (Makes the assumption that "reach all of" is invalid)
>    We can "outlaw" valid forking for SUBSCRIBE (although your 
> proposal was
>    to outlaw forking for presence, your arguments were based 
> on outlawing
>    forking for SUBSCRIBE in general), and use the specific 
> mechanism of
>    sending a 481 to certain NOTIFYs to tear down the dialog. 
> Then you can
>    solve the problem of the "reach all of" semantics in a 
> method-specific
>    way for MESSAGE. After that, you can solve the problem in a message
>    specific way for INFO. Then, a new mechanism for REFER. 
> And something
>    else for UPLOAD. Something different for FOO. And so on.

I'm certainly not proposing that. I was merely arguing that it was simpler
to assume that a presentity is represented by one PA (with that PA perhaps
composing presence data from multiple sources), so that the SUBSCRIBE can
fork, but that you would 481 all NOTIFY except the one matching the 2xx.

Adam later writes:

> There are individual points in there to which I could respond
> (i.e. we're not solving reliable multicasting in the general case),
> but the thrust of his arguments don't address the presence
> case -- his arguments claim that valid forking of SUBSCRIBE is
> always bad, in all contexts, no matter what, game over.

No; hopefully my above statements clarify.

> 
> Instead, I agree with you (on this particular point): "If you
> want to pay attention to an apparently unsolicited NOTIFY that
> matches everything except the TO tag from the 200 OK from the
> SUBSCRIBE, go for it. If not, then you've got a problem, squelch
> the messages you don't want with the 481."

To which I agree as well.

> This, as I understand it, is the agreement we nailed down about
> 8 months ago. I can't stop us from revisiting the issue, but I'm
> growing increasingly frustrated that the very same people who
> claim to be in a hurry insist an repeatedly opening the same can
> of worms over and over and over again.

I can only assume you refer to me here; I am not advocating overturning that
decision, I am merely advocating we keep what is already documented in the
presence spec, and what has been there since the draft was written, which is
that you 481 all NOTIFY except the one that matches the 2xx to SUBSCRIBE. 

-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