More on xcapevent -06

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