From: Aki Niemi <[EMAIL PROTECTED]>
Can you walk me through an example of how etags won't work, please?
The treacherous aspect is that etags will *work*, technically, but the
nature of the situation will prevent it from achieving any savings
(even though naively one would think that savings could be achived),
and that some attention should be paid to see if we can eliminate this
contradiction.
But let me walk through an example:
The critical fact is that some event types (esp. dialog and
resource-list) contain a "version" attribute. Within any one
subscription, the first value is required to have version 1.
As the value changes, each successive value is required to increment
the version by 1.
(One consequence is that several subscribers to the same resource can
receive values that are logically the same, but which are textually
different, since each subscriber must receive a correct version within
his sequence of values.)
(I suspect that this mechanism was invented to support the "partial
update" facility, so that the subscriber could detect that he'd missed
an intermediate partial update. But it's remarkably troublesome in
practice. E.g., in the sipX open-source system, we have one global
version number for all subscribers to a resource, and just violate the
rule that the first NOTIFY in a subscription must have version 1, and
hope that this won't trigger bad behavior in subscribers.)
(Dialog events have version numbers, but presence events do not. But
resource-list events containing presence events do have version
numbers.)
Consider this sequence of events:
Subscriber establishes a subscription, receives data A with version 1.
Subscriber receives data B with version 2.
Subscriber receives data C with version 3.
Subscriber receives data D with version 4.
Subscriber receives data E with version 5.
Subscriber terminates subscription.
Subscriber establishes a new subscription, receives data E with
version 1.
The problem is that etags does not suppress sending of the data in the
last SUBSCRIBE, even though the subscriber already knows the *data*,
because the *value* contains the version 1, whereas the previous value
contained version 5, and so had a different etag.
One way to circumvent this problem is for the subscriber to always use
poll-type (zero-length) SUBSCRIBEs, so that all NOTIFY bodies would be
required to have version 1. Then if the data is unchanged, the etag
would be unchanged.
IMHO, etags is part of the solution, but it overlaps with the existing
problems of the notification version number, and that a clean solution
is going to require thinking about these in an integrated manner.
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
