Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Mon, 19 Nov 2001 17:35:19 -0600

Adam,

I respect your viewpoint and the work in the event draft, but I'm going to
have to disagree with you.

Option 1 makes the assumption that sometimes reach-all is valid, and
sometimes it's not. It's flexible. 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.

Option 2 is overkill. It might not matter to the particular service or
mechanism being deployed if the forking behavior of non-INVITE messages is
going to pose a problem. Not allowing forking would be (to me) like forcing
everything to use TCP instead of UDP. Plus, it's SIP/2.1.

Option 3 assumes that the problem of having multiple dialogs created as part
of presence is a good thing to have in the first place. And it's SIP/2.1.

My argument all along has been that even if the forking issues are resolved,
there's fundamental problems with allowing multiple subscriptions to be
created, in the case of presence. That because of this, for presence, it is
best to very strongly recommend that only one presence agent be in the
network at any point at time. It would not matter if forking worked exactly
how everyone wanted it to work or not, you'd still have serious problems.

Option 1 works for presence as far as I can see, and does not place or pose
any restrictions on others who, for their event package, want to loosen up
the rules a bit more. It is a client problem entirely. The network won't
even know what is going on or care.

Am I missing something?

Regards,

Brian Stucker

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 19, 2001 4:43 PM
To: 'Jonathan Rosenberg'; adam.roach; Stucker, Brian [NGB:B635:EXCH];
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.

(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

---

From: [email-masked]
Date: Mon, 19 Nov 2001 17:52:25 -0600

I think what you interpreted option 1 to mean is what I
was proposing by option 3. That is: forking of SUBSCRIBE
is allowed in general, but that subscribers always have
the option to terminate unwanted subscriptions with a
481.

I suspect that the reason you misinterpreted what I said
is that you didn't frame it in the correct context. I quote
Jonathan Rosenberg's comments below; it is to them that
I am responding:

    "I fear that the complexities of forking SUBSCRIBE are
     simply too great compared to the potential benefits, and
     Brian does a fine job here of providing some good reasons.
     The simple fact that we have no real way to do
     authentication (only works if the same number of proxies
     exists between subscriber and watcher!!) is a clear hint
     that things are headed in the wrong direction. 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. Effectively, the difference is between
     designing something that does reliable anycast (which is
     not too hard) as compared to reliable multicast (which is
     still largely an unsolved problem in the general case)."

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.

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

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.

In this message, I've done nothing but agree with you. To avoid
mixing the discussions, I'll be sending out a note in which I
disagree with you about presence in particular in just a moment.

/a

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Monday, November 19, 2001 5:35 PM
To: 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

Adam,
I respect your viewpoint and the work in the event draft, but I'm going to have
to disagree with you.
Option 1 makes the assumption that sometimes reach-all is valid, and sometimes
it's not. It's flexible. 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.
Option 2 is overkill. It might not matter to the particular service or
mechanism being deployed if the forking behavior of non-INVITE messages is
going to pose a problem. Not allowing forking would be (to me) like forcing
everything to use TCP instead of UDP. Plus, it's SIP/2.1.
Option 3 assumes that the problem of having multiple dialogs created as part of
presence is a good thing to have in the first place. And it's SIP/2.1.
My argument all along has been that even if the forking issues are resolved,
there's fundamental problems with allowing multiple subscriptions to be
created, in the case of presence. That because of this, for presence, it is
best to very strongly recommend that only one presence agent be in the network
at any point at time. It would not matter if forking worked exactly how
everyone wanted it to work or not, you'd still have serious problems.
Option 1 works for presence as far as I can see, and does not place or pose any
restrictions on others who, for their event package, want to loosen up the
rules a bit more. It is a client problem entirely. The network won't even know
what is going on or care.
Am I missing something?
Regards,
Brian Stucker

---

From: [email-masked]
Date: Mon, 19 Nov 2001 18:04:16 -0600

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.

I've put those nine words in all-caps because they are crucial
to understanding what I'm trying to say.

For presence, the state information delivered by a
concentration point in the network will contain the state of
several different entities. This differs in no real way (in terms
of forming a single coherent state to be rendered to the user)
from the situation in which you receive this state directly from
each entity.

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.

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.

/a

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Monday, November 19, 2001 5:35 PM
To: adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, ALCTA; Paul Kyzivat
Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)';

Adam,