Subject: RE: [Simple] 200 vs. 202

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Nov 2001 17:16:02 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 19, 2001 11:06 AM
> To: 'Jonathan Rosenberg'; 'Brian Stucker'; Roy, Radhika R, ALCTA; Paul
> Kyzivat; [email-masked]
> 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 was meant for the case where you 
> > want to reach any
> > one of N things. Thats perfect for INVITE, but clearly it 
> > fails for the case
> > where you want to reach all things, as we seem to want here. 
> 
> This is a very concise restatement of the primary argument
> that I made when I proposed that we deprecate forking for
> all non-INVITE requests.

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, I am merely saying that we specify that the presence event
package stay as defined, and pretty much assume no forking. If it does
happen, you get no gaurantees on getting full state of the presenttiy.

-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

---

From: [email-masked]
Date: Mon, 19 Nov 2001 16:42:33 -0600

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

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

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

2. (Makes the assumption that "reach all of" in invalid)
   A more coherent approach would be to outlaw forking for all non-INVITEs.

3. (Makes the assumption that "reach all of" is valid)
   I believe that the easiest and fastest way forward would be to *allow*
   forking of arbitrary requests with "reach all of" semantics, and attempt
   to solve the concrete problem(s), once they are proposed, that arise
   from allowing multiple dialogs to be established by a SUBSCRIBE in the
   context of presence.

I'll go for options 2 and 3. Option 1 is pure and unbridled insanity.

/a