On Mar 10, 2008, at 10:58 AM, [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'm thinking that it might be essential for some applications, and that if the mechanism doesn't support it, then we simply need to document that the mechanism doesn't support it because there is an easy workaround by encoding version labels in the object itself. > > > I think to progress this discussion, we have to determine whether > reliable knowledge of the existence of state changes is a useful > feature. Well, that would help, but only if we think we need to change the spec to support the feature. I'm currently thinking that we do NOT need to change the spec to get this behavior -- we just need to clarify in the spec that it does not. This may be as simple as a one-sentence add (although I suspect it's more like a paragraph). -- dean _______________________________________________ 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
