XCAP Specification Version -02 (February 2004)
Updated XCAP Specification (draft-ietf-simple-xcap-02)
Date: Sun, 15 Feb 2004 02:43:43 -0500 From: Jonathan Rosenberg <firstname.lastname@example.org> To: Simple WG <email@example.com> Subject: [Simple] Updated XCAP specification
I've just submitted an update to the main xcap spec. Until it appears in the archives, you can pick up a copy at:
Here are the differences from the previous version:
* MIME type for element PUTs and GETs is now defined as application/xml-fragment-body. Did not include proposed "root" type - wasnt clear why it was needed. The root is known by the requesting client.
* MIME type for attribute PUT and GETs is now defined as application/xml-attribute-value and is just the value, not the attribute name.
* combined the create and replace document, element and attribute sections into one section each
* when the server gets a PUT request to create a new element, clarified that, if the parent of that element does not exist, the server returns a 409. Similarly for an attribute creation. This case was formerly described as "if the server needs to create additional content in order to perform the insertion, return a 409". This was too vague.
* defined the default authorization policy for resources in the global tree - read can be done by all users, write only by priviledged administrators.
* clarified that you cannot select comments, processing instructions, text content or namespace attributes with a URI.
* clarified that the response to a PUT is a 200 OK with no content.
* Etag behavior has completely changed. Now, the server maintains a single etag for the document. Any sub-component will share that etag.
* Add text to clarify that, in the case of data dependencies, if the client wants to find out the data computed by the server, it needs to do a subsequent GET, or use the xcap event package. Also clarified that the server is responsible for computing this data after a PUT, and responsible for changing the etag.
* In the introduction, clarified that resource lists were useful for list subscriptions as one example use case, and another use case was to allow a user to log in to different clients and still have access to their buddy list.
* Clarified that the URI hierarchy defined in the spec is a MUST to implement by servers. I.e., its not a recommended document storage structure.
* Defined an XML body that can be included in a 409 that indicates specific details about the reason for the conflict. This body is optional. One of the cases it covers is if the users is trying to create an element or document that requires a URI within the document to be unique (for example, a resource list URI), but the proposed URI exists. The error body indicates the URI(s) which exist, and can also suggest alternates.
* The client behavior sections now detail error handling procedures. These are provided only for the 409 case, and in particular, it states that the body of the 409 may be there, providing additional information to assist the client in a retry.
* The XCAP URI no longer separates the document URI from the node selector through a query ("?"). Rather, the path of the URI extends naturally from the document down into the content of the document. As per discussion in Minneapolis, this was done since it was anticipated that HTTP server infrastructure would have trouble handling HTTP GET operations for resources containing query strings.
* Restructured the section on application usages
* Added a discussion of how to extend the schema for an application usage. It is now possible for a server to process a document without understanding all of its namespaces and schemas; it only needs to understand the application usage. The equivalent of the SIP "Require" functionality is now defined through an XML element called "mandatory-ns" that is optionally included in a document. When present, it indicates the namespaces that must be understood by the server in order to process the document.
Comments and questions welcome. In particular, I'd like to know whether people are happy with the two most major changes, (1) the usage of the XML document in 409, (2) the ability of the server to process documents without understanding all of its namespaces.
There arent any major open issues at this point. The following are the minor open issues I am aware of:
* For the XML fragment body and XML attribute value MIME types - do they need to use the +xml convention in RFC 3023? Neither of these are valid XML documents per se. I think the answer is no. Other opinions welcome.
* The specification requires that a server uses the same etag across all resources that point to the same document. Whilst this is allowed per se by HTTP 1.1, it feels ugly. Is there anything we can do about it?
* Knowing the contents of a directory - how to do it? Separate package? This is being discussed in a separate thread.
* Is there a more efficient way to find out server assigned URIs? Right now, its a separate GET after the PUT completes.
Thanks, Jonathan R.
-- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft firstname.lastname@example.org FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com
Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple
Prepared by Robin Cover for The XML Cover Pages archive.