Subject: Re: [Simple] How is the presentity being notified of watcherinformation for presence authorization when the watcher isunregistered?

From: "Jeffrey" <[email-masked]>
Date: Tue, 1 Apr 2008 11:19:42 +0800

Dear Michael,

Thanks for your answer. Yes, that is what I want to know in my situation
described. Thanks very much.
Besides, I ever tried to post this problem to sip-implementors list twice,
but the email seemed lost somewhere so that I changed to post here. I will
check the email system in my company again.
Many Thanks.

BR,
Jeffrey 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Froman
Sent: Monday, March 31, 2008 10:25 PM
To: [email-masked]
Subject: Re: [Simple] How is the presentity being notified of
watcherinformation for presence authorization when the watcher
isunregistered?

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:

>
> 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] <sip- 
> [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

%;+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