The error I thought I had made, dropping out a change in 4.7 didn't
happen; rather, the tools page lags behind posting, so I went to
double-check that the change had made it in, I got a -05 draft back
instead of a -06 (even though I typed -06, perhaps we have a bug).
Anyhow, the correct -06 draft is at:
http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-06.txt
and will presumably show up on tools eventually.
Here's a note on the change I made, based on Jari's input that the
revised paragraph didn't make sense even to him.
The -05 text:
While the "aggregate" mode uses bandwidth most efficiently, it
introduces other challenges. The initial synchronization might fail
with rapidly changing resources, because the "aggregate" mode
messages might not include the full version-history of a document
and
the base XCAP protocol does not support version-history retrievals
of
documents. When new documents are created in subscribed collections
and the notifier is aggregating patches, the same issue can occur.
In a corner case, the notifier may not be able to provide patches
with the XML-Patch-Ops [RFC5261] semantics. Therefore, if the
notifier has to temporarily disable diff generation and send only
the
URI references of some changed documents to the subscriber, it MUST
continue with the "xcap-patching" mode afterwards for these
resources, if the initial subscription also started with the "xcap-
patching" mode. Recovery from this error condition therefore means
that the subscriber must refresh to a "known good" state by
downloading the current document if it has lost track of the
patching
operations as indicated by mismatching ETags
became (note changes to last sentence, making it a couple of sentences).
While the "aggregate" mode uses bandwidth most efficiently, it
introduces other challenges. The initial synchronization might fail
with rapidly changing resources, because the "aggregate" mode
messages might not include the full version-history of a document
and
the base XCAP protocol does not support version-history retrievals
of
documents. When new documents are created in subscribed collections
and the notifier is aggregating patches, the same issue can occur.
In a corner case, the notifier may not be able to provide patches
with the XML-Patch-Ops [RFC5261] semantics. Therefore, if the
notifier has to temporarily disable diff generation and send only
the
URI references of some changed documents to the subscriber, it MUST
continue with the "xcap-patching" mode afterwards for these
resources, if the initial subscription also started with the "xcap-
patching" mode. In other words, if the subscriber loses track of
the
patching operations, the subscriber must refresh to a "known good"
state by downloading the current document. Once it has done so, it
can resume using xcap-patching.
--
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
