First, a reply, but after that, I've tried to think through these
issues again:
From: "Michael Procter" <[EMAIL PROTECTED]>
I'm not convinced by this argument. This would imply that only certain
NOTIFYs can shorten the duration (namely ones immediately following
SUBSCRIBEs) but not others, which seems odd.
I'm modeling things differently than you are. I expect NOTIFYs to
always report the *notifier's* idea of when the subscription ends.
When the notifier receives a SUBSCRIBE, it can increase the end-time
as far as it likes, up to the time allowed by the SUBSCRIBE.
The exception is that the notifier is allowed to reduce the
subscription time to zero, that is, to terminate the subscription, and
immediately send a NOTIFY. (As well as a SUBSCRIBE that terminates
the subscription.)
>From this point of view, NOTIFYs (other than termination NOTIFYs)
never shorten the duration -- or rather, never report a shortening of
the duration.
Indeed, I think the crucial question is "Who is the authoritative
keeper of the subscription duration?" I take it that it is the
notifier. Others seem to assume that it is the subscriber. I model
that the subscriber is attempting to remotely manipulate the
subscription duration, and receives occasional updates as to what the
subscription duration *is*.
My model does get us out of the quandary of how to resolve multiple
updates of the subscription -- take the max of the values seen in
NOTIFYs so far. The only race condition is if a re-SUBSCRIBE is in
flight at the same time a NOTIFY is received that terminates the
subscription. But the subscriber then knows that the subscription is
ended, as the notifier has sent word that it has ended, and a late
re-SUBSCRIBE can never revive a terminated subscription.
Secondly, in section 3.2.4, the behaviour of the recipient of the NOTIFY
is defined, which includes:
If the header also contains an "expires" parameter, the subscriber
SHOULD take it as the authoritative subscription duration and adjust
accordingly.
There are no qualifiers about which NOTIFYs should be taken as
authoritative, suggesting that all NOTIFYs are created equal in this
respect, and should be treated as such by the subscriber.
Finally, there is the difficulty in identifying when the duration has
actually been shortened, rather than an apparent change due to clock
drift.
I think that on balance, we can only assume that the phrase 'shorten a
subscription' means just that - to shorten it. No further
qualifications seem to be implied or can safely be inferred.
I've read through Michael's and Paul's messages, and I think I need to
change my position. But that interacts with some issues that are
obscuring the discussion as well.
First, we need to keep our terminology straight. I think everyone
agrees that the real keeper of the expiration time of the subscription
is the notifier. The subscriber proposes new expiration times, and
attempts to remain aware of what the current expiration time is. This
point is just linguistic, but I think that in a few places people have
been getting confused by not keeping these distinctions in mind.
E.g., a NOTIFY can never "shorten a subscription time", it can only
report a subscription time that has been shortened, and it can reduce
the subscriber's idea of the subscription time.
My position has been that the notifier can terminate the subscription
at any time, and that it can extend the subscription upon processing a
re-SUBSCRIBE, but cannot otherwise modify the subscription time, in
particular, it can't shorten it without terminating it. Going back
and reading 3.2.2, I think that RFC 3265 disagrees from me.
But as people have pointed out, if the notifier can shorten a
subscription, processing a NOTIFY that is close in time to the
response to a re-SUBSCRIBE is ambiguous. (Whereas if a notifier
cannot shorten a subscription, then processing is not ambiguous.)
Hmmm, and there is the further problem of a re-SUBSCRIBE that requests
less time than the current expiration time.
The underlying problem is that the subscriber is receiving a series of
notifications of a remote state (the subscription time), and the
transport is not ordering the notifiactions (viz., the 2xx responses
to SUBSCRIBEs vs. the NOTIFYs). Such situations always lead to race
conditions unless the time-evolution of the state is arranged so that
notifications can be unambiguously composed regardless of the order in
which they are received.
My proposal is to narrow RFC 3265 so that the composition rule is
"take the max, but termination dominates all", which requires that the
expiration time never be reduced. I admit that is not what RFC 3265
says, but without a rule like that, eliminating the race condition
cannot be done.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
