Subject: RE: [Simple] 200 vs. 202

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 6 Nov 2001 00:10:29 -0500

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, November 01, 2001 1: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

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

This is an excellent point. I have been on the fence about NOTIFY after 202,
but am now convinced that a PA sends a NOTIFY immediately after the 202, and
that this NOTIFY has no body.

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

The sip-events draft is due out shortly; I will align presence with it when
that happens.

Unfortunately, there are still issues with forking. Consider this case: A
subscribes to B. It forks, and hits two PA, B1 and B2. B1 responds with a
202 first. This hits the proxy, which forwards the 202 upstream. B2 then
responds with a 200, which is absorbed at the proxy. A gets the 202, which
establishes tags for the subscription. Next, it gets a NOTIFY from B2, but
its rejected, since the tags don't match. Then, its subscription is rejected
at B1, which sends a NOTIFY indicating such. As a result, no subscriptions
are established at all, even though B2 did allow it.

The problem is really this; unless each PA is identical, in terms of its
presence state and authorization policies, forking is going to interact
badly with it. The reason is rooted in the fact that the subscriber is
supposed to reject all NOTIFY's except the one matching the 2xx thats
returned. I have long advocated this, since I think presence composition
belogns on the presentity side, not the watcher side. However, if there is
forking, this means, by definition, that there is no presentity-side
composition function.

So, my proposal is the following:

 * there can be multiple PUA for a presentity, of course. If any of them can
act as presence agents for the subset of presence data they know of, they
can register with the presence server indicating that (methods=SUBSCRIBE)

 * if a presence server is aware of multiple PUA for a presentity, the
presence server SHOULD act as a PA (and therefore not fork subscriptions)

 * a subscriber SHOULD accept all NOTIFY requests generated by a particular
subscription (i.e., not reject all but the one matching the 2xx to
SUBSCRIBE), and then compose the presence data from each notification into a
complete presence document

The third bullet above is the big change. It is my hope to avoid forking of
subscriptions with the second bullet above, but if they do happen, we are at
least prepared for it in a reasonable way with bullet three.

Comments? Hopefully I am making some sense...

-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: 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 

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