Subject: [Simple] Subscription state machine in RFC 3857

From: <[email-masked]>
Date: Mon, 19 Nov 2007 14:19:36 +0530

Hi,
 
  This is regarding the Subscription state machine described in Section
4.7.1 of RFC 3857.
This diagram show events like "approved, giveup, rejected, noresource"
change subscription state from "waiting" to "terminated".
 
How can event "approved" make the subscription state change from
"waiting" to "terminated"??
 
Another thing missing in the Subscription state machine is that there is
no event mentioned for subscription state changing from 
"waiting" to "active".
 
Regards
Ajay Kasam

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

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 19 Nov 2007 15:30:41 -0500

Pl. see inline ..

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Monday, November 19, 2007 3:50 AM
	To: [email-masked]
	Subject: [Simple] Subscription state machine in RFC 3857

	Hi,
	 
	  This is regarding the Subscription state machine described in
Section 4.7.1 of RFC 3857.
	This diagram show events like "approved, giveup, rejected,
noresource" change subscription state from "waiting" to "terminated".
	 
	How can event "approved" make the subscription state change from
"waiting" to "terminated"??
	[Sanjay Sinha (sanjsinh)] Waiting state is when an unauthorized
subscription expires waiting for authorization. When the server grants
authorization for a subscription and if the subscription has expired,
then it has to move to terminated state.  

	Another thing missing in the Subscription state machine is that
there is no event mentioned for subscription state changing from 
	"waiting" to "active".
	[Sanjay Sinha (sanjsinh)] Subscription state can not move from
waiting to active since it has already expired and hence was in waiting
state to begin with. If server has authorized the subscription and so it
moved from waiting to terminated state, then next time when the watcher
sends another subscription for that user, it will remember the previous
authorization and will transition from pending to active state.
	 
	Sanjay
	 
	Regards
	Ajay Kasam

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 14:37:33 +0530

Yeah, you are right, thanks for response.
In pending state (i.e after receiving 202 accepted response for the
SUBSCRIBE), does the client need to refresh the subscription?? 

From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2007 2:01 AM
To: Ajay Kumar kasam (WT01 - MCE-Mobile Devices); [email-masked]
Subject: RE: [Simple] Subscription state machine in RFC 3857

Pl. see inline ..

	Hi,

	 
	Sanjay
	 
	Regards
	Ajay Kasam

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Tue, 20 Nov 2007 17:03:54 -0500

202 indicates the subscription is not yet established, it is pending
because of things like authorization from the notifier etc. So it does
not make sense to refresh the subscription until it is established.
Besides the Notify is supposed to indicate the time left in subscription
and subscriber will not get any while the subscription is still in
pending state.
 
Sanjay 

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Tuesday, November 20, 2007 4:08 AM
	To: [email-masked]
	Subject: RE: [Simple] Subscription state machine in RFC 3857

	Yeah, you are right, thanks for response.
	In pending state (i.e after receiving 202 accepted response for
the SUBSCRIBE), does the client need to refresh the subscription?? 

	From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] 
	Sent: Tuesday, November 20, 2007 2:01 AM
	To: Ajay Kumar kasam (WT01 - MCE-Mobile Devices);
[email-masked]
	Subject: RE: [Simple] Subscription state machine in RFC 3857

	Pl. see inline ..

		Hi,
		 
		  This is regarding the Subscription state machine
described in Section 4.7.1 of RFC 3857.
		This diagram show events like "approved, giveup,
rejected, noresource" change subscription state from "waiting" to
"terminated".
		 
		How can event "approved" make the subscription state
change from "waiting" to "terminated"??
		[Sanjay Sinha (sanjsinh)] Waiting state is when an
unauthorized subscription expires waiting for authorization. When the
server grants authorization for a subscription and if the subscription
has expired, then it has to move to terminated state.  

		Another thing missing in the Subscription state machine
is that there is no event mentioned for subscription state changing from

		"waiting" to "active".
		[Sanjay Sinha (sanjsinh)] Subscription state can not
move from waiting to active since it has already expired and hence was
in waiting state to begin with. If server has authorized the
subscription and so it moved from waiting to terminated state, then next
time when the watcher sends another subscription for that user, it will
remember the previous authorization and will transition from pending to
active state.
		 
		Sanjay
		 
		Regards
		Ajay Kasam

---

From: Robert Sparks <[email-masked]>
Date: Tue, 20 Nov 2007 16:11:54 -0600

This is not correct.

A 202 _does_ establish a subscription, and the immediate NOTIFY that  
you _will_ get will have a Subscription-State header in it reflecting  
when the subscription will expire.
(That header will also probably say the subscription is in the  
pending state, but there are cases were it will say otherwise).
If that time elapses and you don't refresh the subscription, the  
subscription will terminate.

202 is a legacy response. When we were developing SIP events, we  
thought we needed to say something about whether the subscription was  
authorized in the response to the SUBSCRIBE.
After we understood the ramifications of SUBSCRIBE being a non-INVITE  
request (it can't pend and you don't get all the final responses back  
when it forks), we moved that information into the Subscription-State  
header in the NOTIFY and make an initial immediate NOTIFY mandatory -  
even for pending subscriptions. When we made that move, we could  
(probably should) have gone back and removed 202 from the spec.

For any practical purpose, receiving a 200 and a 202 to a SUBSCRIBE  
means exactly the same thing.

RjS

On Nov 20, 2007, at 4:03 PM, Sanjay Sinha (sanjsinh) wrote:

> 202 indicates the subscription is not yet established, it is  
> pending because of things like authorization from the notifier etc.  
> So it does not make sense to refresh the subscription until it is  
> established. Besides the Notify is supposed to indicate the time  
> left in subscription and subscriber will not get any while the  
> subscription is still in pending state.
>
> Sanjay
>
> subscription expires waiting for authorization. When the server  
> grants authorization for a subscription and if the subscription has  
> expired, then it has to move to terminated state.
>
> waiting to active since it has already expired and hence was in  
> waiting state to begin with. If server has authorized the  
> subscription and so it moved from waiting to terminated state, then  
> next time when the watcher sends another subscription for that  
> user, it will remember the previous authorization and will  
> transition from pending to active state.
>
> Sanjay
>
> Regards
> Ajay Kasam
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Nov 2007 17:36:46 -0500

> and subscriber will not get any while the subscription is still in 

 From RFC 3265 section 3.1.4.1:

    This SUBSCRIBE request will be confirmed with a final response.
    200-class responses indicate that the subscription has been accepted,
    and that a NOTIFY will be sent immediately.  A 200 response indicates
    that the subscription has been accepted and that the user is
    authorized to subscribe to the requested resource.  A 202 response
    merely indicates that the subscription has been understood, and that
    authorization may or may not have been granted.

    The "Expires" header in a 200-class response to SUBSCRIBE indicates
    the actual duration for which the subscription will remain active
    (unless refreshed).

Note that a "200-class response" includes both 200 and 202.

So a 202 does say that a subscription has been accepted, and that a 
NOTIFY will be sent immediately. The 202 will contain an Expires header. 
If you do nothing more, and authorization is neither granted nor denied, 
this subscription will presumably last until it expires, and then will 
go away. (The UAS should send a final NOTIFY at that time.)

If the UAC wants to keep that subscription active longer (hoping that 
authorization will be granted) then it MAY send a reSUBSCRIBE in hopes 
of extending the expiration time.

If you *don't* do that, then when the subscription goes away there is a 
fair chance that the UAS will no longer remember that you had requested 
authorization so you may not get it. In particular, if the subscriber is 
in one time zone and the notifier is in a time zone with non-overlapping 
working hours, and the subscriber only tries to establish the 
subscription when there is a user connected, then without refreshing the 
subscription you may never get authorized.

	Paul

> Sanjay 
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *Sent:* Tuesday, November 20, 2007 4:08 AM
>     *To:* [email-masked]
>     *Subject:* RE: [Simple] Subscription state machine in RFC 3857
> 
>     ------------------------------------------------------------------------
>     *From:* Sanjay Sinha (sanjsinh) [mailto:[email-masked]]
>     *Sent:* Tuesday, November 20, 2007 2:01 AM
>     *To:* Ajay Kumar kasam (WT01 - MCE-Mobile Devices); [email-masked]
>     *Subject:* RE: [Simple] Subscription state machine in RFC 3857
> 
>     Pl. see inline ..
> 
>         ------------------------------------------------------------------------
>         *From:* [email-masked] [mailto:[email-masked]]
>         *Sent:* Monday, November 19, 2007 3:50 AM
>         *To:* [email-masked]
>         *Subject:* [Simple] Subscription state machine in RFC 3857
> 
>         Hi,
>          
>         grants authorization for a subscription and if the subscription
>         subscription and so it moved from waiting to terminated state,
>         then next time when the watcher sends another subscription for
>         that user, it will remember the previous authorization
>         and will transition from pending to active state.
>          
>         Sanjay
>          
>         Regards
>         Ajay Kasam
>          
>          
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Tue, 20 Nov 2007 18:47:22 -0500

Yeah you are right. I forgot that an immediate Notify will be sent even
for a pending subscription.
 
Thanks

	From: Robert Sparks [mailto:[email-masked]] 
	Sent: Tuesday, November 20, 2007 5:12 PM
	To: Sanjay Sinha (sanjsinh)
	Cc: [email-masked]; [email-masked]
	Subject: Re: [Simple] Subscription state machine in RFC 3857

	This is not correct. 

	A 202 _does_ establish a subscription, and the immediate NOTIFY
that you _will_ get will have a Subscription-State header in it
reflecting when the subscription will expire. 
	(That header will also probably say the subscription is in the
pending state, but there are cases were it will say otherwise). 
	If that time elapses and you don't refresh the subscription, the
subscription will terminate.

	202 is a legacy response. When we were developing SIP events, we
thought we needed to say something about whether the subscription was
authorized in the response to the SUBSCRIBE.
	After we understood the ramifications of SUBSCRIBE being a
non-INVITE request (it can't pend and you don't get all the final
responses back when it forks), we moved that information into the
Subscription-State header in the NOTIFY and make an initial immediate
NOTIFY mandatory - even for pending subscriptions. When we made that
move, we could (probably should) have gone back and removed 202 from the
spec.

	For any practical purpose, receiving a 200 and a 202 to a
SUBSCRIBE means exactly the same thing.

	RjS

		202 indicates the subscription is not yet established,
it is pending because of things like authorization from the notifier
etc. So it does not make sense to refresh the subscription until it is
established. Besides the Notify is supposed to indicate the time left in
subscription and subscriber will not get any while the subscription is
still in pending state.
		 
		Sanjay 

			From: [email-masked]
[mailto:[email-masked]] 
			Sent: Tuesday, November 20, 2007 4:08 AM
			To: [email-masked]
			Subject: RE: [Simple] Subscription state machine
in RFC 3857

			Yeah, you are right, thanks for response.
			In pending state (i.e after receiving 202
accepted response for the SUBSCRIBE), does the client need to refresh
the subscription?? 

			From: Sanjay Sinha (sanjsinh)
[mailto:[email-masked]] 
			Sent: Tuesday, November 20, 2007 2:01 AM
			To: Ajay Kumar kasam (WT01 - MCE-Mobile
Devices); [email-masked]
			Subject: RE: [Simple] Subscription state machine
in RFC 3857

			Pl. see inline ..

				From: [email-masked]
[mailto:[email-masked]] 
				Sent: Monday, November 19, 2007 3:50 AM
				To: [email-masked]
				Subject: [Simple] Subscription state
machine in RFC 3857

				Hi,
				 
				  This is regarding the Subscription
state machine described in Section 4.7.1 of RFC 3857.
				This diagram show events like "approved,
giveup, rejected, noresource" change subscription state from "waiting"
to "terminated".
				 
				How can event "approved" make the
subscription state change from "waiting" to "terminated"??
				[Sanjay Sinha (sanjsinh)] Waiting state
is when an unauthorized subscription expires waiting for authorization.
When the server grants authorization for a subscription and if the
subscription has expired, then it has to move to terminated state.  

				Another thing missing in the
Subscription state machine is that there is no event mentioned for
subscription state changing from 
				"waiting" to "active".
				[Sanjay Sinha (sanjsinh)] Subscription
state can not move from waiting to active since it has already expired
and hence was in waiting state to begin with. If server has authorized
the subscription and so it moved from waiting to terminated state, then
next time when the watcher sends another subscription for that user, it
will remember the previous authorization and will transition from
pending to active state.
				 
				Sanjay
				 
				Regards
				Ajay Kasam