Re: [Simple] WGLC: XCAP Base

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

Thanks for your comments, Jari. Responses inline.

Jari Urpalainen wrote:

> A few comments/questions.
>
> 8.5 Managing Etags
>
> As Jonathan has interpreted (complying with rfc2616) that a node or even 
> an attribute of an xml-document can be regarded as a resource is it 
> allowable to send the document ETag after partial delete which is then 
> actually an ETag of a different resource ?

I don't know. I fear that the answer is no; after a DELETE, the resource 
is deleted, so by definition THAT resource doesn't have an etag anymore.

> I would certainly prefer that 
> it is still being sent as otherwise you introduce a second deficiency 
> into safe updates of the document (the first one being partial append). 

I'm not sure what ability we have to mandate this. Since we're using 
HTTP, its going to depend on what HTTP says. I looked around for any 
text which talks about etags in DELETE responses, and didnt see anything.

> This would mean that only partial modifies are safe. I can think only 
> ugly solutions to this IMO annoying problem which is mostly due to the 
> fact that partial updates were (naturally) not thought when http was 
> created.

Well, we have what we have. I do think we need to clarify the etag 
behavior in DELETE. If someone can confirm that a DELETE response would 
never contain an etag, that would be helpful.


An alternative that I debated (but discarded) for this whole mess was to 
think of resources in a document as not getting deleted, but rather, 
becoming empty. That is, if element <foo> exists in a document, than any 
child of that element is said to exist, but be empty. Thus, if you did a 
GET against an element whose direct parent existed, you would not get a 
404; you'd get a 204 (No Content). That would include an entity tag, 
since 204 explicitly permits meta-data.

Thus, you would never actually DELETE. To remove an element, you would 
do a PUT against it, and the body of the PUT would be empty.

This has the benefit that an insertion operations morphs into a 
modification. An element gets modified from empty to having the value in 
the PUT.

As a result, entity tags would become meaningful for insertions, 
deletions and modifications as we know them today.

The drawback to this approach is that its clearly a hack. It will 
require the server to be able to create and manage meta-data for an 
infinite number of resources. Clearly this would be done on-the-fly, but 
its ugly. It also adds some complexity, and produces behavior which is 
non-obvious. Furthermore, it might have ugly interactions with other 
mechanisms we might consider down the road, but I'm not sure.

So, I discarded this approach.


> 6.3 Node selector
>
> Although I have already commented on the default namespace issue I'll 
> repeat it here: XPath 1.0 has the interpretation that namespace uri is 
> null if the location step prefix is empty. The upcoming XPath 2.0 seems 
> to use the element context which is the only sane way in XCAP, too. So 
> just clearly state that in the text (otherwise compliant with XPath 1.0).

This is flagged as "todo" in the document. I understand that the default 
namespace for xpath expressions is null (something I have never 
understood the rationale for). I agree this seemed horribly broken. In 
XPath 2.0, help me understand how this works. Lets say the namespace is 
defined as the one from the current element context in which the Xpath 
expression is being evaluated. I have a doc that is like this:

<foo>
  <test:bar xmlns:test="urn:testing:namespace"/>
  <other:bar xmlns:other="urn:testing:other"/>
</foo>

Lets say I want to select the test:bar element, and I'm evaluating an 
expression within the foo context. I can't figure out how to construct 
an xpath expression to do that. The reason is that, if the evaluation 
context is foo, I can't name test:bar or other:bar because the 
namespaces test and other aren't defined in the foo context.

I'm hoping that I've just misunderstood how to construct the namespace 
context for xpath expression evaluations....



> 7 Client Operations
>
> I am sorry to repeat but I still don't understand idempotent delete. 
> What should the server do during "a subsequent DELETE to the same URI 
> should FIND the resource deleted..." ? I don't understand find here.

The server wouldn't do anything different. WHen the second DELETE 
arrives, it would look at the URI, and find that the resource doesn't 
exist, and thus reject the DELETE with a 404.

I reworded the text thusly:

look the same. Similarly, when a client performs a DELETE, if it
succeeds, a subsequent DELETE to the same URI will generate a 404;
the resource no longer exists on the server since it was deleted by
the previous DELETE operation. To maintain this property, the client

Is that better?


> ---------------
> I still miss non-default namespace examples. 

Once I figure out how this works, I will add them. The norm for us will 
include non-default namespaces, so, in fact, I will change all of them 
to use non-defaults.

> Also in all examples where 
> location steps exist there should be more predicates to imply that each 
> step has to point to a single element.

OK, I will do that.

> Also I havn't noticed any discussions in the mailing lists about caching 
> proxies as they will certainly try to cache responses unless 
> Cache-Control or Expires headers are used. So some recommendations are 
> needed in the text.

Good point. Caching responses is OK, I think. If a client is GETing lots 
of different elements within the document, the caching won't be very 
effective. A cache won't know how to relate the URI for the document 
with the URIs for the elements and attributes within the document, but 
thats OK. The caching isn't broken; its just not taking advantage of 
xcap URI interdependencies to improve performance. Putting that aside, 
subsequent requests for the same URI/resource could fetch the content 
from a cache. That would be OK. The server probably wants to set the 
max-age such that the content expires relatively quickly, but this 
probably depends on the application usage.

As long as all of that sounds fine, I will add text explaining this in a 
new section on caching.

-Jonathan R.



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

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple