XCAP Specification Version -02 (February 2004)

Date:      Sun, 15 Feb 2004 02:43:43 -0500
From:      Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To:        Simple WG <simple@ietf.org>
Subject:   [Simple] Updated XCAP specification

Folks,
I've just submitted an update to the main xcap spec. Until it appears in 
the archives, you can pick up a copy at:
http://www.jdrosen.net/papers/draft-ietf-simple-xcap-02.txt
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
jdrosen@dynamicsoft.com                     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

XCAP Specification Version -02 (February 2004)

Updated XCAP Specification (draft-ietf-simple-xcap-02)