Subject: RE: [Simple] data manipulation protocol: XML Configuration Access Protocol (XCAP) -> comments

From: [email-masked]
Date: Fri, 13 Jun 2003 15:43:37 +0300

Hi all,

First of all: I found the new solution for data manipulation very good.

Please find below some initial comments to the XCAP base protocol draft.

* More exact wording could be used in the chapter 6 "Client Operations". It is difficult to know if some operation affects only a _value_ of some XML item (either XML attribute or XML element), or the whole content between the start and end tag of an XML element, or if only an XML element with its value is managed instead of also the XML attributes with their values etc.

E.g., it is said in the chapter 6.5 "Creating a new element" that the Node-Selector identifies the point in the document where the new element is to be added. --> it's unclear whether all the contents between the start and end tags of the new element (incl. lower level XML elements and XML attributes) are also added and not just the new element and its value, or whether the attributes of the created element are also included or not.

The same comment applies also to the replace operation (CH 6.6): it is said that the Node-Selecor identifies the element whose value is to be replaced --> is it really only the value of the XML element or also the whole content between the start and end tags?

The last chapter of 6.6. says that the operation modifies the value of an element, but cannot modify the attributes of the element --> how about the XML attributes of the lower level elements? And why not to include the whole content of the element (also attributes at the same time)? I think that the examples had also some attributes added within the addition of the element (?). How about the case when an XML attribute is mandatory for the created XML element?

The term "element" in the chapter 6.7 "Delete an Element" seems to mean the XML element itself, its XML attributes and its "nested" content.

* Basically the same comment applies also to the chapter 7.

* In the example (of the chapter 8) the PL of "Friends" is created before the first entry to the list. Would it have been possible to include also some entries in the body at the same time as the Friends list was created? (This is just a question for clarification.)

To make clearer mapping between the specification part of the draft and the example it'd be good to use the same names for operations in the examples than used in the chapter 6.

* An example about having the AUID specific authorisation policy could be added.

BR, Eva

-----Original Message-----
From: ext Jonathan Rosenberg [mailto:[email-masked]]
Sent: 26 May, 2003 11:27
To: [email-masked]
Subject: [Simple] data manipulation protocol: XML Configuration Access
Protocol (XCAP)

Folks,

I've just submitted three I-Ds to the archives, which provide a 
concrete protocol meeting the data manipulation requirements. This 
protocol is called XCAP - the XML Configuration Access Protocol. This 
is an evolution of the SEACAP proposal discussed in 
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-acap-data-00.txt, 
which I presented at the last IETF.

This new protocol is quite different than the SEACAP concept. It is no 
longer based on acap (though it borrows some good ideas from it). 
Instead, things like buddy lists and authorization policies are 
represented using XML documents. XCAP allows a client to manipulate 
those documents through HTTP GET, POST, and DELETE operations. The big 
idea is that the URIs used with HTTP can refer not just to a whole 
document, but to elements, attributes, and other components of the 
document itself. This is done using XPath addressing as part of the 
HTTP URI. Thus, to add a buddy to a list, you would do an HTTP POST to 
the XML element containing the list, and the body of the request is 
the XML document fragment describing that buddy.

In addition, a SIP event package is used to allow a client to get 
notified of changes in a document, to deal with the multi-client 
synchronization problem. That package provides an indication of 
exactly what changed, so the client can reconstruct the document on 
the server. The package also uses canonical XML to provide a hash so 
that the client can verify that it has the same document as the 
server. This should help a lot on wireless.

I am really happy with where this has gone. XCAP is really, really 
simple. No acap, not even SOAP. Just vanilla HTTP, and some Xpath. I 
also really like the usage of XML to specify the buddy lists and 
authorization policy, rather than ACAP dataset classes (the SEACAP 
proposal), since it nicely separates the data from the way we move it 
around. It will also allow us to unify the authorization policy work 
here with the filtering work, by allowing us to share a common XML 
document.

Until the drafts hit the archives, you can pick them up here:

http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-00.txt
http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-package-00.txt
http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-list-usage-00.txt 

The first one is the core XCAP protocol. The second is the SIP event 
package. The third is the XML schema for buddy lists. I havent 
finished the XML schema for authorization policy yet, but I wanted to 
put these documents in front of the group as soon as I finished them, 
so as to provide maximum review time before the interim. I apologize 
for missing the 22nd deadline for interim documents, but both work and 
personal issues in particular added to the delay for this work.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             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
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Fri, 13 Jun 2003 15:43:37 +0300

Hi all,

BR, Eva

-----Original Message-----
From: ext Jonathan Rosenberg [mailto:[email-masked]]
Sent: 26 May, 2003 11:27
To: [email-masked]
Subject: [Simple] data manipulation protocol: XML Configuration Access
Protocol (XCAP)

Folks,

Thanks,
Jonathan R.