Subject: Re: [Simple] How is the presentity being notified of watcher information for presence authorization when thewatcher is unregistered?

From: "Jeffrey" <[email-masked]>
Date: Mon, 31 Mar 2008 15:32:44 +0800

Thanks for reply.
I knew the WINFO subscription state machine addressed in RFC3857. But if the
situation I want to describe is as followings, after the watcher's (UE1)
subscription to presence state of presentity has been expired or
un-subscribed, then the presentity do the action of WINFO subscription. In
this situation, the WINFO subscription state for that watcher UE1 will not
go into "waiting" state. So the presentity will be not able to know that
watcher UE1 wanted to subscribe his/her presence information before that
watcher UE1 re-subscribe presence to the presentity. 
So how can the presentity know that watcher UE1 ever wanted to subscribe
his/her presence information before that watcher UE1 re-subscribe presence
to the presentity?
Thanks a lot.

BR,
Jeffrey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Froman
Sent: Monday, March 31, 2008 11:08 AM
To: [email-masked]
Subject: Re: [Simple] How is the presentity being notified of watcher
information for presence authorization when thewatcher is unregistered?

The situation you describe is the reason for the "waiting" state in the
WINFO subscription state machine.  Please see RFC3857, section 4.7.1.  The
Subscription State Machine for details.

-Michael.

_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

----- Original Message -----
From: Jeffrey <[email-masked]>
To: [email-masked] <[email-masked]>;
'Simple WG' <[email-masked]>
Subject: [simple] How is the presentity being notified of watcher
information for presence authorization when thewatcher is unregistered?

Dear all, 

We are implementing the SIMPLE-based Presence Server. We implemented the
reactive authorization, that is a presentity who subscribes to watcher
information can authorize a watcher to subscribe to his/her presence
information when the request from that watcher arrives. So the message flow
is as followings,

(step 1) The presentity UE1 registers and subscribes to it own watcher
information 
(step 2) The watcher UE2 registers and subscribes to UE1's presence
information 
(step 3) The presnetity UE1 can get the notification of watcher information
and then do authorization to watcher UE2. 
  
But in our implementation, when an UA de-register, it will un-subscribe all
its subscriptions. So if presentity UE1 registers and subscribes to watcher
information after the watcher  de-register, then the presentity UE1 will be
not able to get the notification of watcher information for authorization.
The presentity will be not able to know there is a watcher UE1 wants to
subscribe his/her presence information this time. Any suggestion of
implementation for this situation? Or any specification or document is
discussed?

Thanks in advance. 

BR, 
Jeffrey  

%;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C
This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Michael Froman <[email-masked]>
Date: Mon, 31 Mar 2008 09:24:52 -0500

Here is the text from RFC3857 that describes your situation and how  
the "waiting" state solves the problem (starts at the bottom of page 9):

	<snip>
    The purpose of the waiting state is so that a user can
    fetch watcherinfo state at any time, and learn of any subscriptions
    that arrived previously (and which may arrive again) which require  
an
    authorization decision.  Consider an example.  A subscribes to B.  B
    has not defined policy about this subscription, so it moves into the
    pending state.  B is not "online", so that B's software agent cannot
    be contacted to approve the subscription.  The subscription expires.
    Let's say it were destroyed.  B logs in, and fetches its watcherinfo
    state.  There is no record of the subscription from A, so no policy
    decision is made about subscriptions from A.  B logs off.  A
    refreshes its subscription.  Once more, the subscription is pending
    since no policy is defined for it.  This process could continue
    indefinitely.  The waiting state ensures that B can find out about
    this subscription attempt.
	</snip>

If you have further questions about how this text applies to your  
problem, you should post them to the sip-implementors list (https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors 
  ).

-Michael.

On Mar 31, 2008, at 2:32 AM, Jeffrey wrote:

> This email may contain confidential information. Please do not use  
> or disclose it in any way and delete it if you are not the intended  
> recipient.