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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
