Subject: [Simple] Changes to XCAP

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Oct 2003 10:00:45 -0500

Folks,

As you may have noticed, I (finally) submitted a rev of the xcap spec. 
The changes are based on discussions on the list since the last IETF. 
To summarize the changes:

* aligned this with a pure http usage. This means there is no POST, 
only PUT, and the spec tries to be clear that its all about how to map 
URIs to XML resources

* Came up with a concrete rule for how a server inserts an element or 
attribute. The rule is simple:

   - if the r-uri evaluates to an element or attribute that exists in 
the document, its replaced by the content of the request (which must 
contain an element or attribute, respectively)
   - if the r-uri doesnt match anything that exists in the document, 
this is an insertion. The content of the request is inserted in such a 
way that, after insertion, the r-uri evaluates to the element or 
attribute which was just inserted

This is semantically equivalent to how a regular file gets inserted 
with PUT, but has clearer meaning in the context of XML components. 
Most importantly, this rule gives you the ability to control how 
insertion is done. FOr example:

PUT http://<doc-uri>?xml-root/foo/bar[2]

<bar>
   this will be inserted as the SECOND bar in
   the doc if there is only one bar
</bar>

* I added a grammar for AUIDs

* No longer using xpath directly. Instead, there is a section in the 
doc which defines syntax and semantics for a subset of the xpath 
functionality. Expressiosn compliant to this syntax are a proper xpath 
expression, though.

* vendor specific AUIDs are represented using the java-style naming 
convention of reverse domains.

* As suggested by Scott, I am using Etags now, not modification times.

* Explicitly mention that batching isnt provided. Instead, you have to 
design your schema so that you can maintain useful and meaningful 
documents after each single read/modify/write operation

* Specify that servers need to be aware of all namespaces used in 
documents they manage.

* Clarified a bit on how authorization is done - that application 
usages can specify that their authorization is handled by an existing 
or even a future application usage

* Updated the examples

* Eliminated the open issue on error content. No new error reporting 
is provided. If the client tries to PUT or DELETE and this results in 
an invalid document, the server returns 409, thats it. No more detail 
than that. My reasoning here is that, in most cases, an automata in 
the client would not be able to recover from such an error in any case...

I am pretty happy with where this landed up. THere is only really one 
explicitly mentioned open issue, which is MIME types. The question 
there is, what do we say (if anythng) about the specific MIME types 
that need to be present in request and resposnes? i.e., 
application/xml, text/xml, text/plain, or the mime type specific to 
the applicatoin usage?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple