On to, 2008-03-06 at 16:10 -0500, ext [EMAIL PROTECTED] wrote: > > This is particularly unfortunate because the version attribute does > > not carry information that is important to the application; it is > > control information that is largely redundant with the ETags mechanism > > itself. > > Um, the 'version' parameter is largely redundant with the CSeq. > > Unfortunately it's not. But that isn't relevant. The 'version' > parameter is *mandatory* for some event packages, and it makes ETags > (as they are now defined) nearly useless for those packages.
Huh? I don't understand. Let's say I subscriber to some resource's dialog state. The first NOTIFY carries the current state, and comes with an etag. I refresh the subscription, and use Suppress-If-Match with that etag. If the state has not changed, I won't get a notification. If I choose to poll, the same thing will happen. I.e., I won't get a NOTIFY but a 204 response to the SUBSCRIBE. It seems I'm constantly paraphrasing the draft as we discuss this; there are example message flows in the draft that show exactly how this works. Can you walk me through an example of how etags won't work, please? Cheers, Aki _______________________________________________ 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
