Subject: RE: [Simple] 200 vs. 202

From: Robert Sparks <[email-masked]>
Date: Tue, 6 Nov 2001 09:49:15 -0500

inline

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

Proxies will fork SUBSCRIBEs - most of those won't happen to also
be presence servers.

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

This will cause the composed document to be different before
and after the first refresh (RR will prevent all but the
notifier whos 2xx we received from being refreshed).

> 
> 
> 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
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple