inline: On Fri, 2003-10-31 at 14:03, Tolga Asveren wrote: > I also am a bit confused about the semantics of "Subscription-State" header > in NOTIFY. It seems to me, it has some different meaning depending on, when > NOTIFY is sent (but in most practical sceanarios, probably those two > meanings will overlap) > For example consider the following scenario: > > > | | > |-------SUBSCRIBE1-------->| > | | > |<---200(SUBSCRIBE1)-------| > | | > |<---NOTIFY1(active)-------| > | | > |-----200(NOTIFY1)-------->| > | | > | ..... | > NOTIFY <----|<---NOTIFY2(active)-------| > because of | | > state change |----200(NOTIFY2)--------->| > of the | | > subscribed entity/resource.... | > | | > | | > refresh <----|------SUBSCRIBE2--------->| > before subscription | | > expires |<---200(SUBSCRIBE2)-------| > | | > |<---NOTIFY3(pending)------|
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. > | | > |----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. > | | > | | > 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
