[EMAIL PROTECTED] wrote:
> My impression was that while a notifier could *terminate* a
> subscription before the previously promised expiration time, it could
> not otherwise decrease the promised expiration time. (And it is not
> clear why it would want to.)
>
> Skimming RFC 3265, I have to argue from the absence of any positive
> statement allowing it to do so. But there is one ambiguous passage:
>
> 3.2.2 The notifier MAY use this mechanism [the Subscription-State
> expires param] to shorten a subscription; however, this mechanism
> MUST NOT be used to lengthen a subscription.
>
> I argue that the "shorten a subscription" applies only to accepting a
> shorter extension of a subscription than was requested in a SUBSCRIBE,
> not shortening a subscription duration that has already been promised
> in a Subscription-State.
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.
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.
Regards,
Michael Procter
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
