[Sip] Draft ietf-sip-xcapevent revised, many open questions

[Dean Willis <[e-mail]>]

I have submitted a revised version of the XCAP Event draft based on  
feedback from Lisa Dusseault and that incorporates a vast amount of  
editing by Jean Mahoney, a technical writer who volunteered to help  
clean things up after Lisa pushed the draft back from IESG review.



See:
http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-05.txt

and since tehre are a lot of changes, the side-by-side diff is really  
helpful:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-sip-xcapevent-05

There are a number of questions open in the existing document.



1)  What's the default notification mode supposed to be? "xml- 
patching" is listed as the default and fail-safe in some text, but "no- 
patching" is also described as the singular "must implement" mode. It  
seems to me that if a mode is the default if no mode is specified,  
then that mode had better be the default.
This question is a primary source of confusion in Section 4.3, and I'd  
appreciate some feedback. This whole section got a lot of edits, you  
may want to usea difftool.


2) Aggregating definition

Our current text has this definition; is it right?

    Aggregating:  An XCAP client can update only a single XCAP Component
       at a time using HTTP.  However, a notifier may be able to
       aggregate a series of these modifications into a single
       notification using XML-Patch- Ops semantics encoded in the XCAP-
       Diff format.



3) SUBSCRIBE bodies

Section 4.4 currently says;

    The SUBSCRIBE request MAY contain an Accept header field.  If no  
such
    header field is present, it has a default value of "application/
    xcap-diff+xml".  If the header field is present, it MUST include
    "application/xcap-diff+xml", and MAY include any other types.

This doesn't sound right to me.



4) Error recovery

Section 4.7 says:

    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.,

(note the accidental extra comma here at the end, I just noticed it,  
and it is my fault).

Anyhow, does the "recovery" text make sense?