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

[Jari Urpalainen <[e-mail]>]

On Wed, 2009-05-27 at 02:35 +0200, ext Dean Willis wrote:
> 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.
> 
> 
Thanks Dean, Sean and Lisa.
> 
> 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.
> 
for implementers this is no big deal, although you MUST know which is
the default if the parameter is missing, anyways it can be anyone of
those, so i'm fine with this technical change.

> 
> 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.
> 
> 
looks fine ;-)

> 
> 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.
> 
the part was stolen from rfc3856, section 6.5. If you refer to default
behavior, i personally agree that it's a bit weird, but there are much
better sip experts here...

> 
> 
> 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?
> 
I must admit that it's a bit difficult to follow the sentence starting
with "Recovery ..." but it shouldn't still be _wrong_...

Section 5 example has a missing angle bracket, and there's bug in
whitespace usage, take the example from the previous version.

Similar bugs also in example on page 21.

thanks Dean,
Jari