Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Tue, 20 Nov 2001 09:05:18 -0600

I think that'll work just fine, and it's what you have in your draft, isn't
it? I wasn't as involved with the list 8 months ago, so if I'm included in
the people who are opening up old issues, apologies for that.

Regards,

Brian

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

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