An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources
Note: This ballot was opened for revision 14 and is now closed.
(Robert Sparks) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Ralph Droms) No Objection
Comment (2009-08-25 for -** No value found for 'p.get_dochistory.rev' **)
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?
(Lisa Dusseault) No Objection
(Lars Eggert) (was Discuss) No Objection
(Pasi Eronen) No Objection
(Russ Housley) No Objection
(Cullen Jennings) No Objection
Alexey Melnikov No Objection
Comment (2009-08-27 for -** No value found for 'p.get_dochistory.rev' **)
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.
(Tim Polk) (was No Record, Discuss) No Objection
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?
(Dan Romascanu) (was Discuss) No Objection
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.