Lets contrast this to how this need to know all changes plays out
*without* subnot-etags.
If you maintain an unbroken subscription without etags, you will receive
every notification. (In the absence of throttling - see below.) If the
state changes from A to B to A then you will know that. Using etags
makes no sense.
If you instead poll rather than maintaining a subscription, and don't
use etags, then if the state changes from A to B to A and your polls
miss the time when the state is B, you have no way of knowing you missed
anything. Adding etags does not change this. It just minimizes the data
transfer on the second poll.
Note also that in the past this has come up in the context of event
throttling. When event notification is throttled you also can miss
certain states.
So it seems there has never been any intent to support the requirement
to be aware of every state transition.
Paul
[EMAIL PROTECTED] wrote:
> From: Dean Willis <[EMAIL PROTECTED]>
>
> if a watcher misses the "defg" eTag "89" phase at step 2for some
> reason. It sees state 1, then it sees state 3. If the eTag is allowed
> to repeat, it doesn't know it missed a state change.
>
> Well, there is a design question: Is the goal to allow the subscriber
> update its current knowledge of the state to match the current state,
> or do we in addition want the subscriber to know reliably that there
> have been state changes (even if their exact content cannot be known)?
>
> You seem to think that knowing of state changes is essential, whereas
> the draft considers that to not be a design goal.
>
> I think to progress this discussion, we have to determine whether
> reliable knowledge of the existence of state changes is a useful
> feature.
>
> Dale
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [EMAIL PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
