Re: [Simple] Subscription state machine in RFC 3857

[Paul Kyzivat <pkyzivat at cisco.com>]

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.

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:* ajay.kasam at wipro.com [mailto:ajay.kasam at wipro.com]
>     *Sent:* Tuesday, November 20, 2007 4:08 AM
>     *To:* simple at ietf.org
>     *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:sanjsinh at cisco.com]
>     *Sent:* Tuesday, November 20, 2007 2:01 AM
>     *To:* Ajay Kumar kasam (WT01 - MCE-Mobile Devices); simple at ietf.org
>     *Subject:* RE: [Simple] Subscription state machine in RFC 3857
>
>     Pl. see inline ..
>
>         ------------------------------------------------------------------------
>         *From:* ajay.kasam at wipro.com [mailto:ajay.kasam at wipro.com]
>         *Sent:* Monday, November 19, 2007 3:50 AM
>         *To:* simple at ietf.org
>         *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
>          
>          
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple