Subject: RE: [Simple] 200 vs. 202

From: "Moran Tim (NET/Dallas)" <[email-masked]>
Date: Thu, 1 Nov 2001 18:11:49 -0600

-----Original Message-----
From: ext Brian Stucker [mailto:[email-masked]]
Sent: Thursday, November 01, 2001 12:52 PM
To: Brian Stucker; Moran Tim (NET/Dallas); Ngo, Dai (c); 'Brazier
Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan
Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. 202

[Tim] I think I've reached a point where a set of flows are needed. 
 
Forking interactions, for one. The NOTIFY is used to clear out the
subscriptions that may have been created on nodes that the SUBSCRIBE got
forked to, but whose response was not forwarded back to the UAC that
sent the original SUBSCRIBE.
[Tim] . Section 5 of sip events does not recommend canceling
subscriptions. But assuming we need to, what is wrong with the scenario
of: 

1.	proxy forks subscription to multiple potential notifiers (PAs). 
2.	Some number of notifiers send 202. 
3.	Either one of the notifiers sends a 200 or if none, then at some
time later a notifier sends a non-empty Notify. 
4.	Now, the proxy wishes to cancel the subscription in the other
notifiers. It sends Cancel request & receives 487.

The timer I refer to (in the earlier email) is for receiving a 200/202
from the notifier (not for the Notify itself). Now you might ask the
question of how does the forking proxy know when to cancel the
subscription if none of the notifiers sent a 200 or non-empty notify in
short order? Well,  I think the forking proxy would need to set some
larger granularity timer to cancel the subscription. At that time it
could send the Cancel Request or not worry about the Notifier state and
let it handle its own gross time cleanup. If all the 202 notifiers send
an empty Notify you still haven't bought anything in terms of state
machine cleanup since you are still waiting for that "real" notify with
real information. Were you thinking of doing cleanup by sending a 487 to
the Notify requests of the non-forwarding notifiers???
 
So, the way I see it is that you 1) if noone sent a 200 ensure all
notifiers send 202  and if not try 1 or 2 more times and give up (a
rarity) then 2) if noone sent a 200, wait for a real Notify. 3) if no
real notifys are received for a reasonable amt of time, forget about it
(do internal cleanup) or explicitly cancel the request with each
notifier.

202 Pending means you've been authenticated, but not authorized yet. You
can't send back a dummy (meaning a NOTIFY containing a message body)
back, because that's how you signal to the subscriber that their
subscription has been authorized finally (authorization triggers a
NOTIFY with a message body). Thus, sending a NOTIFY back that is empty
takes care of the 3-way handshake requirement, but doesn't trick the
user into thinking that a subscription was authorized when it wasn't.
[Tim] I should have been clear in that dummy notify is an empty notify. 

You way basically causes the client to ping the network incessantly
asking if their subscription has been authorized yet: "Am I authorized
yet?", "Am I authorized yet?", "Am I authorized yet?", "Am I authorized
yet?".... Seems wasteful, given that you can simply send back an empty
NOTIFY, and be done with it. Your solution also does not take care of
cleaning up forking interactions if I understand it correctly.
[Tim] The timer I mentioned was for the 200/202 response in case it got
lost, not for the Notify.  After receiving a 202 you don't ping. Again,
the 202 to me means     wait - I'll get back with you later - maybe
as I understand from 2068 (HTTP)". Now if later gets to be ridiculous
and you are running out of state variable space - cancel or just abort
the subscription in the proxy - and the notifier --- and even the
subscriber.

The three-way handshake is in the events draft, and it works. The only
issue that I can see are getting the presence and watcherinfo drafts on
board with what the events draft has set forth, and just clarifying the
text in the events draft a little. It's not a big change in my view.

Regards, 

Brian 
-----Original Message----- 
From: Moran Tim (NET/Dallas) [ mailto:[email-masked]] 
Sent: Thursday, November 01, 2001 11:36 AM 
To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); 'Brazier Lachlan';
adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg

Cc: simple 
Subject: RE: [Simple] 200 vs. 202 

To me the term Pending (as in 202 Pending) says hold on I can not answer
right now. Sorry, but I just don't see the justification in the
immediate dummy message to the receiver of the 202. I understand (think
I do) that the empty Notify request is sent so that the notifier can
know that the 202 was received because it causes a 200 from Subscriber
to Notifier. 4 messages to do a 3 way handshake. 

It would appear the assumption is that 3-way handshake is required. What
is wrong with the subscriber timing out on receiving a response from the
notifer (200 or 202) and resending the subscribe? That is, what is wrong
with a  two-way handshake with a timer?

Tim M. 
-----Original Message----- 
From: ext Brian Stucker [ mailto:[email-masked]] 
Sent: Thursday, November 01, 2001 10:49 AM 
To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach;
James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg

Cc: simple 
Subject: RE: [Simple] 200 vs. 202 

The wording there can be taken several ways, and probably needs to be
clarified. We really need to be talking about two notifications at the
point at which a pending subscription comes in: notifying the client
that has a event-package.winfo subscription, and notifying the client
that is requesting the new event-package subscription (where in this
case, event-package is likely to be "presence").

I would argue that you should send an empty NOTIFY to the "presence"
subscription, and send a NOTIFY to the "presence.winfo" subscriber
telling them that the subscription is waiting for their authorization.
If the subscription is a refresh of the pending "presence" subscription,
then you need to send an empty NOTIFY to the "presence" subscription,
but it's a MAY notify on the "presence.winfo" side (the renotification
may not be particularly useful).

I think the new version of the events draft is supposed to be sent out
today, so maybe that'll provide more clarification.

Thoughts? 

Regards, 

Brian Stucker 
-----Original Message----- 
From: Ngo, Dai (c) [ mailto:[email-masked]] 
Sent: Thursday, November 01, 2001 10:27 AM 
To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran Tim
(NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan
Rosenberg

Cc: simple 
Subject: RE: [Simple] 200 vs. 202 

While reviewing the draft "draft-ietf-simple-winfo-package-00.txt" in
the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a
subscription arrives, there is no authorization policy in existence, the
subscription moves into the pending state. In this state, the server is
awaiting an authorization decision. *No notifications are generated*,
but the subscription FSM is maintained."

It seems to me that the above statement contradicts with what we are
saying here, that an empty notification is needed to complete the
three-ways handshake.

How do we reconcile this conflict? 
  
-- Dai