Gen-ART Review of draft-ietf-sip-xcapevent-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sip-xcapevent-03
Reviewer: Spencer Dawkins
Review Date: 2008-09-19
IETF LC End Date: 2008-10-02
IESG Telechat date:  not known

Summary: this document is on the right track for publication as a Proposed
Standard but a few changes are required before publication. The document has
a number of 2119 issues. There are a few areas where I thought I understood
the text but had to guess at its meaning. I flagged these as clarity
comments unless I thought they were disguising a technical issue.

Comments: "clarity" comments included here are for the editor's convenience
and are not actually part of the Gen-ART review.

Abstract

   This document describes an "xcap-diff" SIP event package for the SIP
   Event Notification Framework, with the aid of which clients can

Spencer (clarity): s/with the aid of which clients can/which clients can use
to/

   receive notifications of the partial changes of Extensible Markup
   Language (XML) Configuration Access Protocol (XCAP) resources.  The
   initial synchronization and document updates are based on using the
   XCAP-Diff format.

Spencer (technical): Is this "are based on the XCAP-Diff format"? If not, I
don't understand.

1.  Introduction

   While the XCAP protocol allows several authorized users or devices to
   modify the same XML document, XCAP does not provide an effective
   synchronization mechanism (except polling) to keep resources

Spencer (clarity): s/except polling/beyond polling/

   equivalent between a server and a client.  This memo defines an
   "xcap-diff" event package that, together with the SIP event
   notification framework [RFC3265] and the XCAP-diff format
   [I-D.ietf-simple-xcap-diff], allows a user to subscribe to changes in
   an XML document, and to receive notifications whenever a change in an
   XML document takes place.

   There are three basic features that this event package enables with
   the XCAP-Diff [I-D.ietf-simple-xcap-diff] change notification format.

   Firstly, it can list a collection [RFC4918] content of an XCAP

Spencer (clarity): "a collection content" reads oddly, unless this is a
technical term.

   server, which means in practice listing the URI references of XCAP
   documents from a collection.  This is important when a subscriber is
   doing an initial synchronization or a comparison of existing server
   resources to the locally cached XCAP documents, for example.  The
   version-history of document comparisons are based on the strong
   entity tag (ETag) values of XCAP documents which are also indicated
   with the XCAP-Diff format.

   Secondly, this event package can signal whenever a change is
   happening in those resources.  The changes can be reported with three
   ways.  The simplest model is that only document creations, updates
   and removals are indicated.  The actual contents of those documents
   are not shown and the subscriber uses the (HTTP) RFC 2616 [RFC2616]

Spencer (clarity): s/shown/included in the notification/?

   protocol for a retrieval of document contents.  The two more complex
   modes allow the changes of documents to be indicated straightaway
   with the XML-Patch-Ops [I-D.ietf-simple-xml-patch-ops] semantics
   inside the XCAP-Diff [I-D.ietf-simple-xcap-diff] format.  A client
   can then apply a conditional patch to locally cached documents based
   on the strong ETag values of documents.  The most complex model
   produces the smallest documents but it doesn't necessarily show the
   full HTTP version-history information unlike the other, but typically

Spencer (clarity): s/but//

   more verbose one.

   Lastly, XML element or attribute contents (XCAP components) can be
   received "in-band", that is straight within the XCAP-Diff
   notification format.  For example, an XCAP element content can be
   requested and indicated without the need of a separate HTTP GET
   request.  If this requested node either exists or is later created or
   modified, the notification body indicates its content.  And
   similarly, the removals of subscribed XCAP components are reported,
   for example after a successful HTTP DELETE request.


4.  XCAP-Diff Event Package

4.1.  Overview of Operation With Basic Requirements

   The first notification of the subscription MUST always contain the
   URI references of the subscribed, existing documents and/or SHOULD
   contain the subscribed XCAP element content(s) and/or MUST contain

Spencer (technical): "MUST and/or SHOULD and/or MUST" seems complex - and
why is the SHOULD a SHOULD? As stated, you can violate the SHOULD and do
none of the three, and things should still work - is that the intent? If
they were "MUST and/or MUST and/or MUST", you could require one of the three
choices...

   the subscribed XCAP attribute content(s).  The notifier MUST thus

Spencer (technical): this MUST seems strange... is it really derived from
the previous sentence?

   always support XCAP component subscriptions.  The subsequent
   notifications MAY contain patches to these documents.  The notifier
   MUST support the simplest change notification model, but the XML-
   Patch-Ops diff-generation is RECOMMENDED to implement.  The
   subscriber MAY control how the notifier will signal the changes of

Spencer (technical): almost certainly not a 2119 MAY.

   documents.  How this can be done, will be shown later in this
   document.

   Whenever a change in a resource or an XCAP component content is
   indicated inside the XCAP-Diff [I-D.ietf-simple-xcap-diff] format,
   the subscriber MUST have read privilege to that particular resource.

4.3.  'diff-processing' Event Package Parameter

   With aid of the optional "diff-processing" event header parameter the
   subscriber directs the notifier how to apply the "XML diffing
   process" or in other words, how the notifier SHOULD indicate change
   notifications of documents.  The possible values are "no-patching",
   "xcap-patching" and "aggregate" with the increasing complexity order.

Spencer (clarity): s/with the/in/

   If the subscription does not contain this additional "diff-
   processing" parameter, the notifier SHOULD send all individual
   changes so that the client receives the full (HTTP) ETag change
   history of a document.  In other words, "xcap-patching" is the
   default operational mode of a notifier.  Note that the "no-patching"
   mode does not necessarily either indicate the full HTTP ETag change

Spencer (technical): s/either//?

   history.

4.4.  SUBSCRIBE Bodies

   It is anticipated that the XCAP server will be collocated with the
   SIP notifier, so the subscriber MAY use relative XCAP R-URIs.  This
   means that the notifier has then been provisioned somehow the XCAP

Spencer (clarity): s/somehow/with/

   Root URI value, for example.  A future specification(s) MAY be

Spencer (technical): not a 2119 MAY

   written for the more complex use-cases, this memo describes only the
   most simple one.

4.7.  Notifier Generation of NOTIFY Requests

   During the initial subscription the notifier MUST first resolve the
   requested XCAP resources.  If the subscribed body contains elements
   or attributes that it doesn't understand, they MUST be ignored by the
   notifier.  If there are superfluous resource selections in the
   requested URI-list, the notifier SHOULD NOT provide overlapping
   similar responses for these resources.  Only the resources where the
   authenticated user has read privilege, MUST be included in the XCAP-

Spencer (technical): I'm not sure whether this is saying "MUST NOT include
if authenticated user does not have read privilege" or not - could you
invert the sentence, if that's what it IS saying?

   Diff format.  Note that for example, an XCAP component which could
   not be located with XCAP semantics, does not produce an error.
   Instead, the request remains in a "pending" state, that is, waiting
   for this resource to be created.  Subscriptions to collections have a
   similar property: once a new document is created into the subscribed
   collection, the creation of a new resource is notified with the next
   NOTIFY request.

   While with the most complex patching mode "aggregate" the bandwidth
   usage is the most efficient, it introduces other challenges.  The
   initial synchronization MAY fail with rapidly changing resources,
   because the "aggregate" mode doesn't necessarily indicate the full
   version-history of a document and the base XCAP protocol does not
   support version-history retrievals of documents.  Secondly, when new
   documents are created into the subscribed collections and the
   notifier is "aggregating" patches, the same issue MAY occur.  In a

Spencer (technical): probably not 2119 MAY...

   corner-case, the notifier may not be able to provide patches with the
   XML-Patch-Ops [I-D.ietf-simple-xml-patch-ops] 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.

4.8.  Subscriber Processing of NOTIFY Requests

   During re-subscriptions the received state of all previous resources
   MUST be stamped as stale except when a conditional

Spencer (clarity): s/except when/until/?

   [I-D.ietf-sip-subnot-etags] re-subscription is successful.  Then the
   current state of resources MUST be preserved unless the subscribed
   URI-list has changed, i.e. the resource's state MUST then be fetched
   for example from some local cache.


7.  Security Considerations

   Denial-of-Service attacks against the notifiers deserve a special
   mentioning.  Subscriptions to a long list of URIs MAY be too process-
   intensive.  The "pending" subscriptions to un-existing documents or

Spencer (clarity): s/un-existing/non-existent/?

   XCAP components impose the same challenge as well as the diff-
   generation algorithms, at least when they try to optimize the
   required bandwidth usage to extremes.


_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]