The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
draft-ietf-simple-xcap-12

[Ballot discuss]
I know this is a big DISCUSS body; I want to make sure, since I wasn't able to follow the entire discussion on these topics, that the WG has considered the points raised in last call comments...

http://www1.ietf.org/mail-archive/web/ietf/current/msg42504.html
http://www1.ietf.org/mail-archive/web/ietf/current/msg42238.html

... as well as the issues I noted during my own review, below.  In some cases I expect an answer from the authors/WG will suffice but I feel these merit discussion.

1.  AUIDs

Both review messages deal with the problems of AUIDs, and I'll add to that.  It's wrong to put a capability identifier in the URL, for two reasons:
  - With this specific approach, many HTTP implementation and deployment choices are debarred.  WebDAV made the mistake of disregarding the likelihood that HTTP servlets (and other extension mechanisms) would define paths within which WebDAV features worked, but outside those paths, WebDAV features would not work.  XCAP needs to accomodate that similarly.
  - It's a poor choice for extensibility and upgrade and a limited way to advertise capabilities.  Application usages will want to extend their functionality in more flexible ways than simply defining a brand-new AUID.

My suggestion for AUIDs is to use MIME types or an HTTP header in which the server can advertise a set of capabilities that aren't exclusive of each other.  Furthermore, this approach will avoid having to define a new registry and syntax.

2.  The use of namespaces is not sufficiently defined.
  - May a server change namespace prefixes, or the location of declarations, from what the client sends?  May it eliminate redundant declarations or remove declarations of prefixes for unused namespaces? Or MUST it preserve some or all of those? 
  - I believe the definition of a default namespace conflicts with the definitions in XML Namespaces.  In that document, a default namespace is declared locally and can be redeclared, changing the default namespace for different pieces of the document. An XCAP default namespace, however, is defined by the server for the whole document.  This conflicting terminology should be fixed.
  - The spec says that the server must accept unrecognized content from other namespaces, but it says nothing about accepting unrecognized content from the application namespace.  MUST the server accept those too?
  - When the client doesn't specify a namespace prefix for a node selector, does that mean that the node MUST match the default application namespace, the default XML namespace, or MAY match any namespace?
  - When a client sends an XML fragment in a PUT, MUST it contain all the declarations for the prefixes used in the fragment?  Or should that be MUST NOT if it can use prefixes that are declared on the server?
  - Same thing when the server returns an XML fragment in GET response, does it rewrite the fragment to contain all the XML namespaces that are necessary to understand, or does the client have to retrieve the whole document or the namespace mapping list to get this inforamtion?  If the former, the spec should note that fragments will frequently not be well-formed.

3. ETags
  - Since eTags are required anyway, the spec should say that servers MUST return ETags in response to write requests and in GET responses. Otherwise, clients will have to download the whole document again.
  - I just can't make sense of section 8.2.6 on ETags and conditional processing.  What does instantiating a resource have to do with determining its ETag?  I believe it would be more clear to talk about the ETag of the document, rather than the ETag of a resource that's been identified with a node selector, and this would remove the need for the language on instantiation.
  - I don't believe that allowing Weak ETags is any use at all except to introduce confusion and inconsistency. This is supported by the experience of implementing Weak ETags in HTTP, where the only place I've seen them used doesn't at all match the description in HTTP spec text and forces clients to implement magic ETag munging that isn't written down in any standard anywhere.  My recommendation is to disallow Weak ETags or at least recommend against; they're subtle.
  - Section 8.5 says that "the response to that operation will convey the entity tag of the resource"... This should be reworded as "The server MUST..."

4. Selector and insertion logic
  - I find the logic of when to insert and when to overwrite a node to be very unclear.  I think it hinges on whether the node selector ends up picking exactly zero or exactly one node, but that's not said early on.  I hate syntaxes that don't differentiate between WRITE and INSERT in the syntax itself, but it's not too late to explain when to know how to do which.
  - I think there may be some bugs in whether insertions happen before or after comments.  I can't tell if the normative text contradicts the example where a node insertion is done before comments, or if the normative text has some conditions on it which don't apply in this example.  If the latter case is true, there should be normative text for the conditions which do apply in the example.

5. Authentication
  - The spec requires servers to implement Digest authentication, but this isn't helpful unless servers are also required to always use Digest authentication.  If that's the case, servers should also be allowed to use more secure mechanisms if such are defined.  It makes more sense to require that clients MUST implement Digest and TLS, because that allows servers to put a reasonably secure security policy in place and be sure of interoperating.

6. XML Whitespace
  - I can't see how the requirements on whitespace are quite met in the examples.  Some examples include the addition of CRLF whitespace before the inserted fragment, and some don't.
  - Overall, I recommend that whitespace, comments and directives be dealt with in the same way, with the same language.

7. Spec formatting
  - As a favour, please number or name the examples.  I can't refer to examples effectively since there are multiple examples (plus variations) in most sections.

[Ballot discuss]
Although discussions and the technical write-up led me to the conclusion that XCAP was not designed as a general purpose protocol, this is not specified clearly in the document. In order to avoid confusion some explicit text should be added in the Introduction section (at the end).

NEW:

XCAP was not designed a general purpose XML search protocol or a XML database update protocol or a general purpose XML-based configuration protocol for network elements.

[Ballot discuss]
Please deal with the comments in
http://www1.ietf.org/mail-archive/web/ietf/current/msg42504.html
http://www1.ietf.org/mail-archive/web/ietf/current/msg42238.html

1.  AUIDs

Both review messages deal with the problems of AUIDs, and I'll add to that.  It's wrong to put a capability identifier in the URL, for two reasons:
  - With this specific approach, many HTTP implementation and deployment choices are debarred.  WebDAV made the mistake of disregarding the likelihood that HTTP servlets (and other extension mechanisms) would define paths within which WebDAV features worked, but outside those paths, WebDAV features would not work.  XCAP needs to accomodate that similarly.
  - It's a poor choice for extensibility and upgrade and a limited way to advertise capabilities.  Application usages will want to extend their functionality in more flexible ways than simply defining a brand-new AUID.

My suggestion for AUIDs is to use MIME types or an HTTP header in which the server can advertise a set of capabilities that aren't exclusive of each other.  Furthermore, this approach will avoid having to define a new registry and syntax.

2.  The use of namespaces is not sufficiently defined.
  - May a server change namespace prefixes, or the location of declarations, from what the client sends?  May it eliminate redundant declarations or remove declarations of prefixes for unused namespaces? Or MUST it preserve some or all of those? 
  - I believe the definition of a default namespace conflicts with the definitions in XML Namespaces.  In that document, a default namespace is declared locally and can be redeclared, changing the default namespace for different pieces of the document. An XCAP default namespace, however, is defined by the server for the whole document.  This conflicting terminology should be fixed.
  - The spec says that the server must accept unrecognized content from other namespaces, but it says nothing about accepting unrecognized content from the application namespace.  MUST the server accept those too?
  - When the client doesn't specify a namespace prefix for a node selector, does that mean that the node MUST match the default application namespace, the default XML namespace, or MAY match any namespace?
  - When a client sends an XML fragment in a PUT, MUST it contain all the declarations for the prefixes used in the fragment?  Or should that be MUST NOT if it can use prefixes that are declared on the server?
  - Same thing when the server returns an XML fragment in GET response, does it rewrite the fragment to contain all the XML namespaces that are necessary to understand, or does the client have to retrieve the whole document or the namespace mapping list to get this inforamtion?  If the former, the spec should note that fragments will frequently not be well-formed.

3. ETags
  - Since eTags are required anyway, the spec should say that servers MUST return ETags in response to write requests and in GET responses. Otherwise, clients will have to download the whole document again.
  - I just can't make sense of section 8.2.6 on ETags and conditional processing.  What does instantiating a resource have to do with determining its ETag?  I believe it would be more clear to talk about the ETag of the document, rather than the ETag of a resource that's been identified with a node selector, and this would remove the need for the language on instantiation.
  - I don't believe that allowing Weak ETags is any use at all except to introduce confusion and inconsistency. This is supported by the experience of implementing Weak ETags in HTTP, where the only place I've seen them used doesn't at all match the description in HTTP spec text and forces clients to implement magic ETag munging that isn't written down in any standard anywhere.  My recommendation is to disallow Weak ETags or at least recommend against; they're subtle.
  - Section 8.5 says that "the response to that operation will convey the entity tag of the resource"... This should be reworded as "The server MUST..."

4. Selector and insertion logic
  - I find the logic of when to insert and when to overwrite a node to be very unclear.  I think it hinges on whether the node selector ends up picking exactly zero or exactly one node, but that's not said early on.  I hate syntaxes that don't differentiate between WRITE and INSERT in the syntax itself, but it's not too late to explain when to know how to do which.
  - I think there may be some bugs in whether insertions happen before or after comments.  I can't tell if the normative text contradicts the example where a node insertion is done before comments, or if the normative text has some conditions on it which don't apply in this example.  If the latter case is true, there should be normative text for the conditions which do apply in the example.

5. Authentication
  - The spec requires servers to implement Digest authentication, but this isn't helpful unless servers are also required to always use Digest authentication.  If that's the case, servers should also be allowed to use more secure mechanisms if such are defined.  It makes more sense to require that clients MUST implement Digest and TLS, because that allows servers to put a reasonably secure security policy in place and be sure of interoperating.

6. XML Whitespace
  - I can't see how the requirements on whitespace are quite met in the examples.  Some examples include the addition of CRLF whitespace before the inserted fragment, and some don't.
  - Overall, I recommend that whitespace, comments and directives be dealt with in the same way, with the same language.

7. Spec formatting
  - As a favour, please number or name the examples.  I can't refer to examples effectively since there are multiple examples (plus variations) in most sections.

[Ballot comment]
The following questions and comments were raised by Andy Bierman.

1) Is this intended only for use with SIP?

2) Is there any access control model for securing data?
    (What is the security model?)

3) Is there a persistence model for data?
    (IMO there are problems with trying to abstract a NE device
    configuration as an XML document, and this is one of them)

4) The examples would be easier to read if the XML was pretty-printed.

5) In a general sense there is clearly overlap between NETCONF and XCAP.
    I think NETCONF tries to be more content and transport independent,
    and the RPC-based architecture is more suited to standard and vendor
    "specialized RPC" extensions, which provide a more natural
    programming paradigm than a model based on XML document manipulation.

I realize that this document is returning from the RFC queue after having been approved by the IESG and these questions may have been already debated and answered. Yet, it would be good if the editor would review and address them prior to publication.

[Note]: 'Note that this document was pulled from the RFC Editor queue and is returning with some changes, which are recorded in the tracker.' added by Jon Peterson

IANA Last Call Comments:

Uppon approval of this document IANA will create a new
registry "XCAP Application Unique IDs" to be located at:
TBD


The initaial values in this registry will be
Value {max 20) Description Reference
--------------- -------------------------------- -----------
AUID Capabilites of an XCAP server [RFC-ietf-simple-xcap-11.txt]

We understand that IETF standards action is required for future
registrations.

Uppon approval of theis document IANA will make the following assignments
in the Application Media-Types registry located at:
http://www.iana.org/assignments/media-types/application/
Value Reference
------------- -------------------
xcap-att+xml [RFC-ietf-simple-xcap-11.txt]
xcap-caps+xml [RFC-ietf-simple-xcap-11.txt]
xcap-el+xml [RFC-ietf-simple-xcap-11.txt]
xcap-error+xml [RFC-ietf-simple-xcap-11.txt]
xcap-ns+xml [RFC-ietf-simple-xcap-11.txt]


Uppon approval of this document IANA will make the following assignments
in the "XML Schema" registry located at:
http://www.iana.org/assignments/xml-registry/schema.html
ID URI Filename Reference
xcap-caps urn:ietf:params:xml:schema:xcap-caps xcap-caps RFC-ietf-simple-xcap-
11.txt
xcap-error urn:ietf:params:xml:schema:xcap-error xcap-error RFC-ietf-simple-xcap-
07.txt


Note: most of the registration in the two last registries have been made by
versio 07 of this document.

IANA Last Call Comments:

Uppon approval of this document IANA will create a new
registry "XCAP Application Unique IDs" to be located at:
TBD


The initaial values in this registry will be
Value {max 20) Description Reference
--------------- -------------------------------- -----------
AUID Capabilites of an XCAP server [RFC-ietf-simple-xcap-11.txt]

We understand that IETF standards action is required for future
registrations.

Uppon approval of theis document IANA will make the following assignments
in the Application Media-Types registry located at:
http://www.iana.org/assignments/media-types/application/
Value Reference
------------- -------------------
xcap-att+xml [RFC-ietf-simple-xcap-11.txt]
xcap-caps+xml [RFC-ietf-simple-xcap-11.txt]
xcap-el+xml [RFC-ietf-simple-xcap-11.txt]
xcap-error+xml [RFC-ietf-simple-xcap-11.txt]
xcap-ns+xml [RFC-ietf-simple-xcap-11.txt]


Uppon approval of this document IANA will make the following assignments
in the "XML Schema" registry located at:
http://www.iana.org/assignments/xml-registry/schema.html
ID URI Filename Reference
xcap-caps urn:ietf:params:xml:schema:xcap-caps xcap-caps RFC-ietf-simple-xcap-
11.txt
xcap-error urn:ietf:params:xml:schema:xcap-error xcap-error RFC-ietf-simple-xcap-
07.txt


Note: most of the registration in the two last registries have been made by
versio 07 of this document.

Changes since previous IESG review:

Subsequent to approval by IESG, several issues were raised by SDOs
looking to use XCAP, and in particular, OMA. The primary problem had to
do with the handling of namespaces in the specification. When a client
performs a PUT operation to insert or modify a portion of a document,
the document fragment they are PUTting needs to use XML namespace
prefixes that are defined higher up in the XML document. There is no
problem if the client already knows these namespace prefixes, typically
because it has the document cached. However, if the client doesn't have
the document cached, there was no way to learn the namespace prefix
bindings. A change was introduced that allowed a client to query the
server to return the namespace bindings in scope at any point in the
document.

Related to this, the specification was underspecified in terms of future
extensibility (such as adding an extension to learn namespace prefixes).
The document was updated so that the grammar explicitly called out
points of extension, and the specification talked about how extensions
would be done.

The final substantive change was in the procedures for conditional
operations. Previously, conditional operations were only permitted for
modifications to elements or attributes, not insertions. The lack of
conditional operations for insertions meant that clients needed to be
prepared for write collisions, which would be discovered only after they
occured. The client then needed to back out the change. This proved
incredibly hard to implement, as one might imagine. This was changed so
that all operations could be conditional. A consequence of this change
is that it was no longer necessary to include xcap-diff documents in 200
OK responses, as these were needed to detect mismatches in document
versions between client and server.

All other changes were minor, fixing bugs reported since publication of
the document. These include clarifying the rules on whitespace and
element ordering on insertion, updated URI reference to 3986,
clarification on when to use the 200 vs. 201 response code,
clarification on URI escaping rules for the ~~, ABNF reference update to
4234, and XML bugs.

[Ballot discuss]
I have removed my first two questions based on follow-on discussion.  However, I am still concerned about this one:

In the NETCONF WG, we are running an XML based configuration protocol over SSH.  In that case, it was considered important that we run the protocol on a NETCONF-specific port (not the standard SSH port), so that configuration traffic could be filtered without filtering other SSH traffic.  Should a similar mechanims  (an XCAP-specific port) be used for this protocol, so that firewalls can filtering encrypted XCAP traffic while allowing other HTTP traffic?

Has this tradeoff been discussed in the WG?  What are the security implications of allowing a configuration protocol to run on the standard HTTP port?  I'd at least like to see this decision justified in the Security Considerations section.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

His review:

I had reviewed the immediately-previous versions of these documents (reviews available at http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-simple-xcap-050106-dawkins.txt). The updated IDs address every issue I raised, and I agree with the changes since the previous version.

From a General Area perspective, these are good to go as Proposed
Standard.

Thanks, Jonathan, for quick and thorough editing.

[Ballot discuss]
The security considerations need to include a discussion of
  authorization.  Read, write, modify, and delete operations
  need to be controlled.  Section 5.7 contains some discussion
  of this topic, but a pointer is not sufficient.  It is not
  clear to me how the client or the server determines whether
  an operation is associated with a user's home directory.

[Ballot discuss]
I have a few questions about this document.  These may not be blocking issues, but I have entered a discuss because I want to discuss this document before it goes forward.

(1) What was the reason for choosing to define a configuration protocol specifically for "applications"?  Do applications have specific configuration requirements (that differ from routing protocols, for example) that would justify a separate management protocol?

(2) Is it considered wise to allocate permanent AUIDs based on reverse-order domain names when a company does not have permanent ownership of their domain name?  What happens if a company's domain name expires and is taken on by another company?

(3) In the NETCONF WG, we are running an XML based configuration protocol over SSH.  In that case, it was considered important that we run the protocol on a NETCONF-specific port (not the standard SSH port), so that configuration traffic could be filtered without filtering other SSH traffic.  Should a similar mechanims  (an XCAP-specific port) be used for this protocol, so that firewalls can filtering encrypted XCAP traffic while allowing other HTTP traffic?

[Ballot discuss]
I have a few questions about this document.  These may not be blocking issues, but I have entered a discuss because I want to discuss this document before it goes forward.

First, is it considered wise to allocate permanent AUIDs based on reverse-order domain names when a company does not have permanent ownership of their domain name?  What happens if a company's domain name expires and is taken on by another company?

Also, in the NETCONF WG, we are running an XML based configuration protocol over SSH.  In that case, it was considered important that we run the protocol on a NETCONF-specific port (not the standard SSH port), so that configuration traffic could be filtered without filtering other SSH traffic.  Should a similar mechanims  (an XCAP-specific port) be used for this protocol, so that firewalls can filtering encrypted XCAP traffic while allowing other HTTP traffic?

[Ballot discuss]
I have a few questions about this document.  These may not be blocking issues, but I have entered a discuss because I want to discuss this document before it goes forward.

First, is it considered wise to allocate permanent AUIDs based on reverse-order domain names when a company does not have permanent ownership of their domain name?  What happens if a company's domain name expires and is taken on by another company?

IANA Comments:
Upon approval of this document the IANA will create a new registry for XCAP Application Unique IDs (with 1 initial entry), register 4 MIME Media Types, register 2 XML Namespace registrations, and register 2 XML Schema registrations.

Last Call comments sent to the IESG:

From Tim Bray:

A few comments:

The term "URL" is used heavily in this document.  For current applications, this should be URI, with a normative reference to RFC2396bis.  Hmm, URI and URL are both used.  Which is weird.

Section 6.3  I quote "The Node Selector is based on a subset of XPath".  Subsetting widely-implemented specifications is questionable.  It may be the case, as argued, that XPath has more power than this spec needs, but that may come for free given that full XPath implementations are widely available for free.  Second, interoperability failures may ensue should someone use a tool to generate conformant XPaths for use in this protocol which however fall outside of the blessed subset.  Also, the spec is bulked up considerably the (error-prone) work of replicating the description of the syntax and semantics of XPath.

Section 7.3 There's nothing in HTTP that says that when you do a PUT and then do a GET, you get the same thing back that you PUT.  I assume this is the desired behavior here, so it should be specififed.

Sections 6.2 & 6.3 would be immensely improved by the inclusion of some examples.

There's a lingering [Todo: ] in section 8.5

There's quite a substantial overlap between this and the Atom Publishing Protocol, see http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-02.txt

-Tim

From Lisa Dusseault:

ince XCAP is going to last call, I thought I'd forward this attempt to explain why I think there's a minefield ahead with respect to HTTP interoperability and compatibility, and particularly compatibility with other extensions to HTTP (such as but not limited to WebDAV).  Fundamentally, my proposal is to modify XCAP slightly to put the XPATH-derived element selection syntax in the query part of the HTTP URL, so as not to alter HTTP's resource model.   

In the responses to this email there were a fair number of reasonable responses, however most of these consisted of quibbles with details and theoretical concerns (yes, in *theory* HTTP's resource model should be extensible in this way).  So far my gut feeling of unease around messing with HTTP's resource model has not been allayed much.  I do realize that a gut feeling of unease from one HTTP implementor isn't enough to block or even delay XCAP, I just wanted to feed this into the IESG's hopper.

Thanks,
Lisa Dusseault

Begin forwarded message:

From: Lisa Dusseault
Date: November 21, 2004 6:58:47 PM PST
To: HTTP working group , "'simple@ietf.org'"
Cc: Subject: [Simple] Some thoughts on XCAP's resource architecture

During the DC IETF, I expressed some reservations about XCAP to Ted and Jonathan. Jonathan asked me to send a message to the SIMPLE list with my comments, so here it is...

Based on the mailing list on the traffic, it appears that  XCAP is supposed to be an extension or profile of HTTP, rather than just a protocol that mimics the HTTP interaction style, and that as such it is intended to be compatible with other extensions of HTTP.  I'm concerned that the current architecture of XCAP makes this difficult.  In particular the XCAP resource ontology and the URL addressing style that goes with it shifts the HTTP design along two major axes:

1) Resource granularity
2) Dependency between resource

The first shift is in size and number of resources.  Because the path part of the URL allows for XML node selection, there are many more resources for a given volume of content material.  This affects us in a number of ways.

1a) HTTP intermediaries and scaling: caches aren't designed to cache huge numbers of tiny resources.  It would probably be wise to disable caching on XCAP responses.

1b) HTTP servers aren't designed for that many small resources.  There's a certain amount of overhead to maintaining the metadata (at a minimum, the ETag) for so many small resources.  An HTTP server might have to be rearchitected to do a scalable job of supporting XCAP, which increases the XCAP implementation costs in the long run.

1c) Performance: HTTP is designed to batch requests in a certain way based on the granularity assumptions.  Recall that latency is a much bigger problem than bandwidth above a certain (low) bandwidth, and in modern Internet applications it's usually the latency that kills you.  A more granular approach to resources doesn't in itself kill performance but it does if you stay with HTTP's request granularity.  What XCAP is saving in bandwidth it will lose, in many use cases, in latency costs.

1d) Extensions to HTTP have also been designed with HTTP's current granularity in mind.  RFC2518, RFC3253, RFC3229, RFC3744 all extend HTTP in useful ways, and they're all written with the assumption that the granularity of resources is pretty much what it is today.  Access control, in particular, has a lot of overhead per resource

2)  Dependencies:  HTTP servers are designed such that static resources are handled independently of each other. Their ETag management is stand-alone, the request and response handling and concurrency are designed for that independence.  By contrast, XCAP contemplates a large number of resources which really map to parts of the same underlying file.  As far as I can tell, that introduces dependencies between resources (for example that a PUT to one URL would require the ETag of another URL to change).

2a) HTTP implementation barriers.  The last HTTP server I developed would have to be rearchitected in several places to handle XCAP's interdependencies, work beyond what you'd expect from adding XCAP support.  Throughout the server, the code uses exact matching of URLs to figure out what to do -- not URL pattern matching. So for example:
- The way ETags were generated and stored and changed would have to be thrown out because ETags were generated independently for every resource.
- Since resources were independent, write requests for different resources could be handled concurrently with ease, but that would have to change.

2b) How interdependencies work within existing HTTP extensions: For one, somebody would have to write a specification for how the existing access control standard (RFC 3744) might work with XCAP.  Since XCAP can have two different URLs that point to the same underlying piece of data, what does it mean to apply certain access control settings to either or both of those URLs?

I haven't examined every feature of HTTP and its extensions to see how well it deals with interdependencies, but that's a sampling.

So, what to do? It doesn't seem to me that XCAP is going to go back to the drawing board (or needs to), but it would be sufficient for most of the above concerns to simply make the definition of "resource" stay with the root XML documents that XCAP deals with.  The existing extensions to HTTP work a lot better on that size resource.  Part of this change involves putting the XPATH-like part of the XCAP URL out of the path part of the URL.  It could go in a header or even in the URL after the query delimiter (the question mark).  There is a theoretical problem with using query parameters on HTTP URLs in PUT requests if write-through caches don't know how to handle those, but there aren't a lot of write-through caches and overall it's a smaller problem and less work to deal with.

Full disclosure: I'm partially responsible for the current design because I pointed out the write-through cache problem with a previous design that used query params in PUT URLs. Unfortunately, I think that on balance the problems with the current architecture are worse.

Lisa

From Pete Cordell (cc'ed to Simple wg)

I haven't followed XCAP, but I wonder if the following XML schema types
should be empty elements (e.g. ) rather than ur-type (e.g.
blahetc)?

   
   
   
   
   
   

If some of them are meant to be empty, then the syntax is:

   
     
   
   
     
   
   
     
   

Regards,

Pete.