Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Mon, 26 Nov 2001 13:12:43 -0600

At the risk of being flogged (I am not suggesting reopening how we do
forking in SIP events)...

Wouldn't just accepting the first NOTIFY go completely against the forking
rules, etc., in your draft, or are we allowing presence to go it's own
direction in this regard? Just taking the first NOTIFY makes it seem like
the argument of a 3-way handshake with the response to the SUBSCRIBE isn't
all that important.

One thing I wonder about is "grinching" the watcher with this. If I have a
fast presence agent (one with very little information to send in the
NOTIFY), and a slow presence agent (one with lots of information to send in
the NOTIFY, and a more complete presence picture); does being the fastest to
respond mean that the information provided is the best as well? Seems like a
race condition waiting to happen.

Regards,

Brian Stucker

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 26, 2001 11:14 AM
To: 'Jonathan Rosenberg'; Stucker, Brian [NGB:B635:EXCH]; adam.roach;
simple
Subject: RE: [Simple] 200 vs. 202

That works, but it seems like a lot of extra implementation effort.

There's really nothing magical about the dialog established by the
200-class response to the SUBSCRIBE; it's just an arbitrary leg
which happens to have responded first.

Given that fact, why don't we just change the scheme so that the
dialog associated with the SUBSCRIBE response isn't special, and
we just accept the first NOTIFY that arrives (and reject all the
other dialogs)?

Is there something I'm overlooking? Accepting the first NOTIFY
seems much easier to implement than keeping track of dialogs that
will just need to be torn down.

/a

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 2:00 PM
> To: 'Brian Stucker'; adam.roach; simple
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> how about this:
> 
> 1. if the subscriber hasn't gotten a 2xx to the SUBSCRIBE, it 
> accepts the
> NOTIFY
> 2. once the response to the SUBSCRIBE comes, if its not a 
> match for the
> NOTIFY, the subscriber refreshes the dialog associated with 
> the NOTIFY, but
> with Expires:0, to terminate it.
> 
> This avoids the tight transaction timing interdependencies at 
> the expense of
> some additional higher level processing.
> 
> BTW, this is really a sip-events issue not so much a simple issue.
> 
> -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
>   
> -----Original Message-----
> From: Brian Stucker [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 2:23 PM
> To: adam.roach; simple
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> You bring up an important point about the watcher having to 
> wait for the
> response to the SUBSCRIBE before processing the NOTIFY. This 
> could give us
> problems if the 200 takes a long time getting back to the 
> watcher, and the
> NOTIFY, in the meantime, is just sitting there being 
> retransmitted over and
> over, waiting for a response. Depending on the T1 and T2 
> timers being used,
> this could create a race condition that might cause a 
> subscription to fail
> because there was no response to the immediate NOTIFY.
> In general, what happens when a NOTIFY to the inital 
> SUBSCRIBE fails to be
> acknowledged?  Does the subscription go away like it does for 
> later NOTIFY
> messages? The reason I ask, is because it would seem to leave 
> the watcher in
> an undefined state. What are the responsibilities of a 
> watcher that sends a
> SUBSCRIBE, gets a 200, and then no NOTIFY?
> A possible solution would be to silently throw away and 
> NOTIFY messages that
> we have not gotten a response (200) on the request to create 
> a dialogue for
> (the SUBSCRIBE). If we do that, then we could wait for some 
> period of time
> (say the expires header in the 200 response). If that period 
> of time elapses
> without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200).
> Thoughts? 
> Brian 
> -----Original Message----- 
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, November 20, 2001 3:18 PM 
> To: simple 
> Subject: RE: [Simple] 200 vs. 202 
> 
> 
> While I disagree with Brian and Jonathan about the problems presented 
> by having multiple PAs in the network, I am willing to quit the topic 
> for the sake of moving forward. 
> I am very wary, however, of any discussions which use arguments about 
> the general case of forking of SUBSCRIBE requests instead of those 
> involving multiple PAs. I wouldn't have even entered the fray if the 
> arguments presented by several parties didn't attack the very notion 
> of SUBSCRIBE forking (instead of limiting themselves to presence in 
> particular). 
> So, with my capitulation, I'll attempt to enumerate what I think 
> we've all agreed on: 
>  1. SUBSCRIBE requests may fork. 
>  2. Subscribers may choose to accept zero or more of the 
>     NOTIFY requests that arrive by responding to them with 
>     a 200. 
>  3. Subscribers may choose to reject zero or more of the 
>     NOTIFY requests that arrive by responding to them with 
>     a 481. 
>  4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I 
>     don't personally care which) accept exactly one NOTIFY 
>     message with a 200, and reject all others with a 481. 
>  5. Subscribers _to_ _presence_ _information_ select which 
>     NOTIFY to accept based on the dialog information 
>     established by the 2xx response to the SUBSCRIBE. 
> Moving forward, then, I see two sets of problems to be addressed: 
> Forking SUBSCRIBE: 
>   - How do we perform authentication for forked SUBSCRIBE messages? 
>     This is actually a more general problem which can be phrased 
>     "How do we perform authentication for forked XXX messages?" where 
>     XXX includes INVITE. I would *really*, *really* like to see a 
>     more general solution to this problem before we start trying 
>     to cobble something together for SUBSCRIBE. 
>   - How do we protect against the DOS attacks that Robert describes? 
> Presence: 
>   - In a forking situation, it is likely (probable, even) that the 
>     NOTIFY requests will arrive at the subscriber before the 2xx 
>     reply to the SUBSCRIBE. Does that mean that the response to the 
>     NOTIFY requests will be suppressed until the SUBSCRIBE request 
>     completes? If so, this should be well documented in the 
>     presence event package. 
>   - Some of the arguments made against accepting multiple dialogs 
>     created by a single SUBSCRIBE were privacy based: an aggregation 
>     point must exist in the network to provide a consistent policy. 
>     Given that there is no way to enforce that only one dialog is 
>     accepted, are there any privacy concerns that can arise from 
>     rogue clients accepting all received NOTIFYs? 
> /a 
> _______________________________________________ 
> simple mailing list 
> [email-masked] 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple 
> 

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple