An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources
draft-ietf-simple-xcap-diff-14

1.  Introduction

   The Extensible Markup Language (XML) Configuration Access Protocol
   (XCAP) [RFC4825] is a protocol that allows clients to manipulate XML
   documents stored on a server.  These XML documents serve as
   configuration information for application protocols.  As an example,
   resource list [RFC4662] subscriptions (also known as presence lists)
   allow a client to have a single SIP subscription to a list of users,
   where the list is maintained on a server.  The server will obtain
   presence for those users and report it back to the client.  This
   application requires the server, called a Resource List Server (RLS),
   to have access to the list of presentities.

I think the first use of a term like "presentity" needs an Informative Reference.


3.  Structure of an XCAP Diff Document

   The <document> element has one mandatory attribute, "sel", and a two
   optional attributes, "new-etag" and "previous-etag".  The "sel"
   attribute of the <document> element identifies the specific document
   within the XCAP root for which changes are indicated.  Its content
   MUST be a relative path reference, with the base URI being equal to
   the XCAP root URI.  The "new-etag" attribute provides the entity tag
   (ETag) for the document after the application of the changes,
   assuming the document exists after those changes.  The "previous-
   etag" attribute provides an identifier for the document instance
   prior to the change.  If the change being reported is the removal of
   a document, the "previous-etag" MUST only be included and the "new-
   etag" attribute will not be present.

I suggest rewording the last sentence:

"If the change being reported is the removal of
a document, only the "previous-etag" MUST be included and the "new-
etag" attribute MUST NOT be present."

   In a corner case where the
   content of this element cannot be presented for some reason, although
   it exists in the XCAP document, the <element> element MUST NOT have
   any child nodes.

Can you please elaborate more on the corner case?

   Each <attribute> element indicates the existing attribute content of
   an XCAP document.  It has one mandatory attribute, "sel", and one
   optional attribute, "exists".  The "sel" attribute of the <attribute>
   element identifies an XML attribute of an XCAP document.  It is a
   percent endoced relative URI following XCAP conventions when

typo: encoded

   selecting attributes.

1. The OPS review asked about the need for a mechanism to specify which levels of related configurations must be present similar to the one in configuration control systems. This diff format specification does not provide a mechanism for doing versioning and coordination of incremental changes. Although it is not clear that this is a mandatory requirement for xcap it is certainly good practice, and it would be good to have this addressed (or explain why it is not needed).

2. The XCAP and XCAP-diff documents do not specify how to manage the underlying XML documents, or how to reflect incremental changes in a management interface. 

XCAP is a type of application-specific HTTP, and the XCAP spec discusses the difficulty of differentiating XCAP traffic from other HTTP traffic, such as at a firewall. As a result, it would seem to be difficult to monitor XCAP-specific faults and performance by doing stream analysis; this would seem to call for having the server and client include support for providing management information, since the XCAP server and XCAP client CAN easily determine which traffic is XCAP related.

An information model describing the data needed for monitoring the XCAP protocol, measuring protocol performance, measuring any impact on network performance, and standardization of operational configuration for the XCAP protocol are simply not discussed. There is no discussion in the XCAP spec or the XCAP-diff spec that explains why management is not needed for XCAP or XCAP-diff.

I am not satisfied with the response provided by one of the editor that this is an implementation issue. It may be true that manageability may be addressed in a different place but some reference that the issues were considered and how they are addressed or why they need not be addressed would be useful to be included.

Figure 1 isn't entirely clear to me.  What do the "-" and "*" symbols mean?

In the sentence immediately before Figure 1, s./how corresponding/how the corresponding/ ?

There are no instructions to IANA in section 7.1.  Will IANA know what to do with that section?

I greatly appreciated the thorough treatment of the semantics for previous-etag and
new-etag when they appear in combination and when each appears alone.  I am afraid
I missed something subtle with respect to new-etag appearing alone, though.  I understand
the scenario where the document was just created, but when would the "document exists"
scenario be invoked?  In this case, the document hasn't changed, so why would there
be a diff document at all?