inline On Wed, 2003-11-05 at 14:05, Tolga Asveren wrote: <snip> > > As I posted in reply to the previous message in this thread, > > this is an odd situation. If authorization on the right > > side of this ladder has been removed (note that I am not > > saying revoked, I'm saying approval has been removed), then > > the right side would almost certainly have issued a NOTIFY > > terminated before the refresh subscription. If, for some > > reason it chose not to do so, and on refresh returns the > > NOTIFY you show here, then the state of the subscription is > > pending. > [TOLGA]IMO, there is a difference between subscription state and state of a > specific SUBSCRIBE(whether it is accepted or pending).
The Subscription-State header describes the state of the subscription, NOT anything about a particular SUBSCRIBE request. > Even if the second > SUBSCRIBE is not accepted yet, > subscription created with the first SUBSCRIBE > should still be valid, > it was approved for a certain amount of time, and > this time has not expired yet. A NOTIFY/pending says that the subscription has entered a pending state. One can come at any time, though it would be exceptionally odd to see one in any subscription after a state of "active" has been entered. As I've said, it will be more often the case that IF authorization information is removed, existing subscriptions dependent on that authorization will be terminated in such a way that the watcher will attempt to resubscribe. But, in the case you seem to be exploring, where authorization is lost and the presentity has to be contacted again for approval on the refresh SUBSCRIBE, the subscription enters a state of pending. That's what the NOTIFY/pending says. It does NOT SAY "I haven't gotten permission for this SUBSCRIBE request". It says "I currently have no knowledge of whether you are authorized to subscribe or not". The state of the subscription has changed at the notifier to pending. It would be non-sensical for the watcher to continue to think it had an active subscription after receiving a NOTIFY/pending. (It would be even more non-sensical for the notifier to think it had an active subscription, but I don't think that's what you are trying to suggest). > So, till that time expires, subscriber should > be able to receive possible state chnages on the subscribed entty/resource. > I would agree that if approval has beeen removed, notifier would send > NTFY(terminated) but it might be the case that approval for the original > SUBSCRIBE is still valid, just the referesh is not approved. Here is the essence of what's causing us to have this conversation I think. How can you be in a state where a watcher has sufficient authorization for a subscription to enter the active state and have the refresh SUBSCRIBE _NOT_ be approved? The only way I can think of is if the presentity has removed approval, in which case the subscription is no longer active. > > > | | > > > |----200(NOTIFY3)--------->| > > > | | > > > | .... | > > > | | > > > NOTIFY <----|<---NOTIFY4(x)------------| > > > because of | | > > > state change | | > > > of the | | > > > subscribed entity/resource | > > This NOTIFY would not be sent at all. The subscription > > is still pending. > [TOLGA]IMO, subscription is not pending, because initial subscription time > as negotiated with SUBSCRIBE1/200(SUBSCRIBE1)/NOTIFY1 is not expired yet. The server is saying with the NOTIFY/pending that subscription is no longer active. This is analgous to a NOTIFY/terminated telling you the subscription has been terminated. You can receive a NOTIFY/terminated long before the original expiration time has passed. > > > | | > > > | | > > > NOTIFY | | > > > because <---|<---NOTIFY5(terminated)---| > > > SUBSCRIBE2 not | | > > > allowed | | > > > | | > > > | | > > > | | > > > > > > Let's assume, when NOTIFY4 was sent, SUBSCRIBE2 was not accepted yet by > > > notifier. What should be "Subscription-Status"? I would expect it to be > > > "active". But in such a case, how to distinguish between > > NOTIFY(active) sent > > > to confirm SUBSCRIBE2 and a NOTIFY(active) sent as a result of > > state changed > > > of the subscribed entity? One possible could argue, that the former one > > > SHOULD have "expires" parameter in the "Subscription-State" header, but > > > including it is a SHOULD, not a MUST, and as explained in RFC3265, more > > > usefull for forking scenarios, so might be not used, if forking is not > > > possible. If we want to rely on it, I would expect it to be a > > MUST, because > > > not putting it would break the protocol. So, if it is not > > present, I don't > > > see a way to decide on the subscriber side, for what reason this > > > NOTIFY(active) is sent. Furthermore, NOTIFY4(active) also brings some > > > confusion about the semantics of "Subscription-State". > > Sometimes, it shows > > > the status about a specific SUBSCRIBE (for example NOTIFY1(active) shows > > > that SUBSCRIBE1 was accepted, and NOTIFY3(pending) shows that > > SUBSCRIBE2 is > > > pending), and sometimes the status of the overall subscription > > relationship > > > (for example NOTIFY4(active) ) -whose deatils in the RFC3265 are not > > > defined, it just "exists" or "does not exist"-. > > > A similar situation is present for NOTIFY5(terminate). But at least, it > > > seems like looking to "reason" parameter might save us. If it > > is "rejected" > > > than it is sent for the last sent/received SUBSCRIBE, and it it > > is "expired" > > > it is for the whole subscription. > > > > > > Now, if one decides to send NOTIFY4(pending) in the above scenario, then > > > there is no need to rely on existence of "expires" field. But the mixed > > > semantics of "Subscription-State" still exists because of > > > NOTIFY5(terminated), it shows SUBSCRIBE acceptance state or subscription > > > state, depending on "reason" parameter. > > > > > > So, what should be "Subscription-State" in NOTIFY4? > > > > > > Tolga > > > > > > > > > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
