Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Tue, 9 Oct 2001 14:27:18 -0500

Maybe the confusion that we're having is centered around how to deal with an
empty NOTIFY. If you think of an empty NOTIFY as signifying nothing about
the
status of the subscription (pending or accepted) and nothing about the state
of the resource the subscription is made to (in this case the presence
agent),
then things get a lot simpler.

If you think about it that way, then the processing of an empty NOTIFY
creates
a three-way handshake to the subscription request, and that helps with
forking
issues.

If the events draft is updated to clarify this thinking (assuming that this
is 
the behaviour desired), and the presence draft is updated such that an
*empty*
NOTIFY, and not one with bogus information in it, is sent after a 202, then
I
think things will get a lot less fuzzy.

Jonathan? Adam?

Brian

-----Original Message-----
From: Ngo, Dai (c) [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 8:32 AM
To: 'Brazier Lachlan'; Stucker, Brian [NGB:B621:EXCH]; Moran Tim
(NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan
Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. 202

In section 5.2.3 "Notifier NOTIFY Behavior" of draft-ietf-sip-events-00.txt
from Adam Roach, it states, "When a SUBSCRIBE request is successfully
processed or a relevant change in the subscribed state occurs, the notifier
will construct and send a NOTIFY request to the subscribers, as specified in
the contact field of the SUBSCRIBE request. Such a message should be sent in
as timely a manner as is practical".

In section 5.8 "Notifier Generation of NOTIFY Requests" of
draft-ietf-simple-presence-03.txt it states, "If a subscription is accepted
(or politely blocked) a NOTIFY must be sent after the 200 OK response to the
SUBSCRIBE has been sent. Notifications MAY be sent at later times, possibly
when the presence state of the presentity changes."

It makes more sense to NOT sending the empty NOTIFY after a 202.

Regards,

-- Dai Ngo

-----Original Message-----
From: Brazier Lachlan [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2001 3:29 AM
To: 'Brian Stucker'; Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo,
Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg
Cc: simple
Subject: AW: [Simple] 200 vs. 202

Hello,
 
When a subscriber receives a 200 on a SUBSCRIBE request, a NOTIFY from the
presentity can be handled. NOTIFY's from other senders will be responded to
with an error (481). The tags in the FROM header of these NOTIFY's are
different than the tag in the To header in the response to the SUBSCRIBE.
 
When a subscriber receives a 202 on a SUBSCRIBE request, a NOTIFY from the
presentity can be handled. NOTIFY's from other senders will be responded to
with an error (481). The tags in the FROM header of these NOTIFY's are
different than the tag in the To header in the response to the SUBSCRIBE.

The question is now, when is the presentity sending the NOTIFY? 
 
If a 200 Ok was returned to the SUBSCRIBE request, the PA of the presentity
knows the status of the presentity. If a 202 Accepted was returned, it
doesn't know right now, but it can find out.
 
I believe that a NOTIFY must be sent "immediately" after sending a 2xx
response to the subscriber. What does "immediately mean"? Does it mean
sending the NOTIFY without delay, or does it mean sending the NOTIFY when
the status is obtained by the PA?
 
If "immediately" means after obtaining the status, I don't see the problem.
 
If "immediately" means without delay, the first NOTIFY after sending a 202
will be useless. I've looked in the presence draft
(draft-ietf-simple-presence-03.txt), but I haven't found the phrase stating,
that a NOTIFY MUST be sent immediately after sending a 202 Acepted. I only
found it for 200 Ok.
Still, as 202 Accepted is a positive response, the NOTIFY could be required.

This leads to my next question: Why is it required? 
Anyway, to follow the requirements, I always can send an empty NOTIFY.

Please correct me, when I stated something wrong or missunderstood
something!
 
Lachlan

-----Ursprüngliche Nachricht-----
Von: Brian Stucker [mailto:[email-masked]]
Gesendet am: Dienstag, 09. Oktober 2001 01:34
An: Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext
Paul Kyzivat'; Jonathan Rosenberg
Cc: simple
Betreff: RE: [Simple] 200 vs. 202

It is my understanding that if the 200 OK is dropped to a SUBSCRIBE, the
watcher must reject the subsequent NOTIFY because it never saw what the TO
tag was from the response to the SUBSCRIBE (because it was in the 200 OK).
You could argue that the watcher takes the TO tag in the first response or
NOTIFY it gets back (as long as the FROM tag and everything else matches
ok). However, that seems to be a bit dangerous if we consider cases where
multiple packets are being dropped (unintentionally or otherwise).

Forking subscriptions seems to be problematic at best unless you ACK the
response (as Adam pointed out with the 3-way handshake mention) like an
INVITE does instead of relying on a NOTIFY that does nothing because CPIM
wants it. It's coming from the wrong endpoint, as you say. I would think
that anything that forks, and creates a meta-session routing requirement
needs to be ACK'd.

Brian Stucker 

-----Original Message----- 
From: Moran Tim (NET/Dallas) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, October 08, 2001 6:17 PM 
To: adam.roach; Stucker, Brian [NGB:B621:EXCH]; James Undery; Ngo, Dai (c);
'ext Paul Kyzivat'; Jonathan Rosenberg 
Cc: simple 
Subject: RE: [Simple] 200 vs. 202 

Three-way handshake in my dictionary implies A->B, A<-B, and then a A->B
again. This is not the case in a Subscribe, 200/202 and then a Notify in
the same direction as the 2xx.. I am also puzzled by your "immediate"
requirement after a 202 since your own draft uses phrases like ...

A 202 response indicates that there may be a sizable delay before a
notification is received, pending the actual creation of the subscription

If the notifier owner is interactively queried to determine whether a
subscription is allowed, a "202 Accept" response is returned immediately,
and the subsequent NOTIFY request is suppressed until the notifier  owner
responds.

Does the requirement for an immediate notify after a 202 only apply to
forked requests? How does the server know when a request has been forked?

So let's say a Subscribe is forked and all the PAs respond with 202. The
best one is returned to the watcher and the rest dropped. All of the PAs
must also respond with a Notify with useless information which the proxy
passes on. How enlightened is the watcher upon receiving the dummy
Notifications? What change is there in the state machine? Then there is the
scenario of 202s come back, proxy timer expires so the best 202 is sent back
to watcher - and then a 200 comes. I presume it would be dropped. The PA
which sent the 200 sends a Notify (immediately) which is forwarded but there
is no preceding 200 so the watcher drops it?  There is the out-of-sequence
clause, but if the 200 never appears wouldn't the notify be rejected? Nodes
which know they can't authorize at the time of subscription may respond
quicker than the node which is actually doing the work of obtaining
authorization. Sounds like some guidelines are needed as to how fast is
immediate and how long a proxy waits for that 200 with the immediate notify.

Tim M. 

> -----Original Message----- 
> From: ext [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Monday, October 08, 2001 2:12 PM 
> To: 'Brian Stucker'; James Undery; Ngo, Dai (c); Moran Tim 
> (NET/Dallas); 
> 'ext Paul Kyzivat'; Jonathan Rosenberg 
> Cc: simple 
> Subject: RE: [Simple] 200 vs. 202 
> 
> 
> Sorry; I haven't been following this closely (things have been 
> hellishly busy recently). This conversation, though, seems to 
> have taken a dangerous turn. 
> 
> Remember that the behaviour of SUB/NOT is general, and not just 
> related to presence. And, in the general case, forking of SUBSCRIBEs 
> can be extremely useful. 
> 
> However, without a three-way handshake, such forking becomes quite 
> messy and unpleasant to implement. 
> 
> The immediate NOTIFY is the third message of this three-way handshake. 
> It can't be removed from the base SUB/NOT draft; by extension, the use 
> of SUB/NOT for presence needs to keep it. 
> 
> /a 
> 
> 
> -----Original Message----- 
> From: Brian Stucker [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Monday, October 08, 2001 1:54 PM 
> To: James Undery; Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; 
> 'ext Paul Kyzivat'; 
> Jonathan Rosenberg 
> Cc: simple 
> Subject: RE: [Simple] 200 vs. 202 
> 
> 
> Ok, as a compromise, since we all seem to feel that the 
> NOTIFY after a 202 is 
> totally useless... 
> Can't we make the 202 act as an implied 'Offline' (or some 
> other harmless, and 
> meaningless indication) 
> NOTIFY within the context of how CPIM requirements work in a 
> SIP network? 
> Gateway functions to other 
> protocols can generate whatever messages they want from this, 
> but in the 
> context of what gets sent 
> around in a SIP network, the 202 acts as a NOTIFY itself. 
> Heck, you could even put dummy XML in the 202 message body if 
> you really wanted 
> (but I'd rather not). 
> Brian Stucker 
> -----Original Message----- 
> From: James Undery [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Monday, October 08, 2001 5:12 AM 
> To: Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; 'ext Paul 
> Kyzivat'; Jonathan 
> Rosenberg 
> Cc: simple 
> Subject: RE: [Simple] 200 vs. 202 
> 
> 
> I'd like to agree with you too, unfortunately it's a CPIM requirement 
> as 2xx are successful responses. The SIMPLE charter requires CPIM 
> complience. 
> James 
> -----Original Message----- 
> From: [email-masked] 
> [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of Ngo, Dai (c) 
> Sent: 05 October 2001 17:52 
> To: 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg 
> Cc: [email-masked] 
> Subject: RE: [Simple] 200 vs. 202 
> 
> 
> I agree that there is no need to send an immediate, empty NOTIFY after 
> a 202 was sent in the pending case. 
> -- Dai 
> -----Original Message----- 
> From: Moran Tim (NET/Dallas) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Friday, October 05, 2001 10:33 AM 
> To: 'ext Paul Kyzivat'; Jonathan Rosenberg 
> Cc: [email-masked] 
> Subject: RE: [Simple] 200 vs. 202 
> My comments are in line. 
> > -----Original Message----- 
> > From: ext Paul Kyzivat [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > Sent: Friday, October 05, 2001 8:04 AM 
> > To: Jonathan Rosenberg 
> > Cc: Moran Tim (NET/Dallas); [email-masked] 
> > Subject: Re: [Simple] 200 vs. 202 
> > 
> > 
> Seems you are both saying the same thing. I seem to recall an earlier 
> dialogue where it was stated that non-Invite requests are treated 
> differently than Invites in that only one response in sent back to the 
> "Subscriber" in this case.  So it would appear that the PA (with proxy 
> capabilities) will wait some predetermined amount of time to collect 
> all of the responses (or until all are received whichever comes first) 
> and send back the best response. If the best is a 202, then does the 
> proxy wait for the Notify and send the 202+Notify or just the 202 and 
> the Notify later? I guess I don't see the need for a 202 indicating 
> pending followed immediately by another message (Notify with no real 
> status) which adds no value. 
> 
> 
> 
> _______________________________________________ 
> simple mailing list 
> [email-masked] 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
<http://mailman.dynamicsoft.com/mailman/listinfo/simple>