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

[Dean Willis <[e-mail]>]

Please follow this discussion on the SIP list.

Begin forwarded message:

> From: Dean Willis <[e-mail]>
> Date: May 26, 2009 7:35:21 PM CDT
> To: "[e-mail] List" <[e-mail]>
> Cc: Robert Sparks <[e-mail]>
> Subject: [Sip] Draft ietf-sip-xcapevent revised, many open questions
>
>
> 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?
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
>