Subject: [Simple] updated core XCAP spec

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 22 Oct 2004 02:40:29 -0400

I've just submitted an update to the core xcap spec. Until it appears in 
the archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-xcap-04.txt

The update addresses comments received during WGLC. Changes are below. 
There are no open issues or todos. I believe that the document is now 
ready to go to IESG.

Changes:

* added XCAP client to definitions section

* clarified that elements can have namepsace attributes, you just can't
select them based on that

* clarified that a document can have comments and text content, you
just can't select based on that

* fixed the bug in DELETE, which was not doing an idempotency check.
Now, the client has to make sure that, after deletion of an element,
the URI points to nothing. THe server will verify this too. Added the
"cannot-delete" error code when the server cannot perform the
deletion.

* fixed references to validation sub-section in server DELETE processing,
which pointed to the wrong sub-section

* line-folded long lines in the examples

* added section on caching

* clarified that DELETE can only delete a single element or attribute

* added usage of xcap-diff+xml documents in 200 OK responses to DELETE
and 201 reponses to PUT. The former allows the client to track the
entity tag of a document through deletions of elements. The latter
allows the client to discover if it clobbered someone elses changes
when doing an insertion (remember that insertions cannot be
conditioned).

* defined how matching is done with namespaces in the picture. The
namespace bindings which are in scope are those of the element tested
at each step. Documented the primary limitation of this approach.

* updated references

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 22 Oct 2004 16:35:21 +0300

ext Jonathan Rosenberg wrote:

> I've just submitted an update to the core xcap spec. Until it appears 
> in the archives, you can pick it up at:
>

Great, this is looking good and i agree that the document is ready to 
go. However, there are some minor issues that i like to comment.

First during partial append and delete appication/xcap-diff+xml is used 
to carry either previous or new ETag. Although the format will fulfill 
the task well, i still see this a bit too verbose for the task, would 
you consider defining simpler content-type(s) ?

in Chapter "Client operations" the definition for idempotency (with put) 
is given like get(put(x))=x. While i'll agree the request is certainly 
idempotent if that requirement is statisfied i'll have a practical 
problem that will contradict with that statement given the r-uri will 
remain the same. Consider the "old" example
current resource <foo id="bar"> , then put request foo[@id="bar"] with 
content <foo id="blah"> is imo idempotent, i.e. you can repeat this 
request as many times as you want and the resource in the server will 
always remain the same after 1..N request. Of course the first request 
really succeeds and the rest won't but idempotency doesn't break. But 
this get(put(x))=x behavior will break provided that exactly the same 
r-uri is used. There's still Location header in http that could be used 
here. This situation was doomed before because of idempotency but now i 
am asking do we still have to satisfy this get(put(x))=x always or could 
we relax with this (provided that the request is of course unambiguos) ?

in chapter XCAP server capabilities <namespaces> are sibling of <auids>. 
i am inclined to see them related to <auid> elements so they might be 
children of  <auid> elements. Then it might be so that some of them are 
repeated, but it would be more human readable.

br,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 23 Oct 2004 13:22:03 -0400

thanks for the comments, Jari. Responses inline.

> you consider defining simpler content-type(s) ?

I'd rather not. I don't think its all that verbose:

<?xml version="1.0" encoding="UTF-8"?>
    <xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff">
     <document doc-selector="resource-lists/users/joe/friends"
      new-etag="7hahsd" previous-etag="7hahsd"/>
     </document>
    </xcap-diff>

Not such a big deal.

The other reason is that I don't think this information should be 
represented differently because you get it from the xcap server through 
an http response, or because it came in a NOTIFY from that server. Its 
the same exact semantic, and the syntax should be the same.

> really succeeds and the rest won't but idempotency doesn't break.

In your example, subsequent PUT requests fail only because the server is 
actually checking that GET(PUT(X))=x. If this check is removed, a 
subsequent PUT would work, and create second copy of the <foo id="blah"> 
element; the server would think its an insertion, and add the element in 
the body.

> But 

I don't see how. I'll also note that this hardly constitutes a "minor" 
change to the document, as it changes a fairly fundamental piece of 
protocol behavior. This one feels to me to be in the category of "adding 
a feature" as opposed to fixing a bug, and I'd really like to stop any 
feature creep at this point. Do you think something is broken per se in 
the current specification?

> repeated, but it would be more human readable.

Having them as children would mean that, even if a document for a 
particular AUID arrived, and it contained elements from schemas that the 
server understands but are NOT listed as children of that auid, that the 
server would not validate the document with those schemas. I don't think 
that is the case. As such, understanding of schemas and AUID should be 
thought of as separate things.

-Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Mon, 25 Oct 2004 11:10:14 +0300

ext Jonathan Rosenberg wrote:

>>> I've just submitted an update to the core xcap spec. Until it 
>>> appears in the archives, you can pick it up at:
>>>
>>> The update addresses comments received during WGLC. Changes are 
>>> below. There are no open issues or todos. I believe that the 
>>> document is now ready to go to IESG.
>>
>>
>>
>> First during partial append and delete appication/xcap-diff+xml is 
>> used to carry either previous or new ETag. Although the format will 
>> fulfill the task well, i still see this a bit too verbose for the 
>> task, would you consider defining simpler content-type(s) ?
>
>
> represented differently because you get it from the xcap server 
> through an http response, or because it came in a NOTIFY from that 
> server. Its the same exact semantic, and the syntax should be the same.
>
>>
>> in Chapter "Client operations" the definition for idempotency (with 
>> put) is given like get(put(x))=x. While i'll agree the request is 
>> certainly idempotent if that requirement is statisfied i'll have a 
>> practical problem that will contradict with that statement given the 
>> r-uri will remain the same. Consider the "old" example
>> current resource <foo id="bar"> , then put request foo[@id="bar"] 
>> with content <foo id="blah"> is imo idempotent, i.e. you can repeat 
>> this request as many times as you want and the resource in the server 
>> will always remain the same after 1..N request. Of course the first 
>> request really succeeds and the rest won't but idempotency doesn't 
>> break.
>
>
> In your example, subsequent PUT requests fail only because the server 
> is actually checking that GET(PUT(X))=x. If this check is removed, a 
> subsequent PUT would work, and create second copy of the <foo 
> id="blah"> element; the server would think its an insertion, and add 
> the element in the body.
>
>
>
>> But this get(put(x))=x behavior will break provided that exactly the 
>> same r-uri is used. There's still Location header in http that could 
>> be used here. This situation was doomed before because of idempotency 
>> but now i am asking do we still have to satisfy this get(put(x))=x 
>> always or could we relax with this (provided that the request is of 
>> course unambiguos) ?
>
>
> protocol behavior. This one feels to me to be in the category of 
> "adding a feature" as opposed to fixing a bug, and I'd really like to 
> stop any feature creep at this point. Do you think something is broken 
> per se in the current specification?
>
Sorry, i'll clarify. I really did not meant to remove this GET(PUT(X))=x 
constraint when new data is being added with put. The example is only 
about modify behavior of put when we'll have an existing content that is 
going to be replaced with a really unambiguous request. So i don't see 
this as an idempotency constraint but as something else (also as modify 
request can be truly conditional, idempotency is not an issue here). So 
for delete and append/insert (put) we'll have clear rules that are easy 
to implement, but this modify seems confusing (at least to me). Looking 
from the implementation pov I would like to allow it. However, if it 
isn't allowed it should be clearly expressed in the text, as it 
certainly confuses those doing implementations. An example would be 
good, too.

>>
>> in chapter XCAP server capabilities <namespaces> are sibling of 
>> <auids>. i am inclined to see them related to <auid> elements so they 
>> might be children of  <auid> elements. Then it might be so that some 
>> of them are repeated, but it would be more human readable.
>
>
> particular AUID arrived, and it contained elements from schemas that 
> the server understands but are NOT listed as children of that auid, 
> that the server would not validate the document with those schemas. I 
> don't think that is the case. As such, understanding of schemas and 
> AUID should be thought of as separate things.
>
> -Jonathan R.

br,
Jari