Re: [Simple] WGLC: XCAP Base

[Miguel Garcia <Miguel.An.Garcia at nokia.com>]

Jonathan Rosenberg wrote:

> 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.

Although I agree, one can think of a few tricks that would help to 
transport the new etag of the new version of the document. For instance, 
 you can think of first allocating a new etag to the resource to be 
deleted, then executing the delete operation. The 200 OK for the DELETE 
contains the etag of the resource right before its deletion. This 
happens to be the etag of the new remaining document.

I also found that RFC 2616 says:

"In order to be legal, a strong entity tag MUST change whenever the 
associated entity value changes in any way."

Does "in any way" include "when the resource is deleted? I am trying to 
find if it is fine to create a new entity value for a deleted resource.


> > 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.

I looked around and I didn't see that is forbidden. On the other hand, I 
suspect that in an XCAP server modeled as a layer of an HTTP stack and 
an XCAP application, the XCAP application will choose the etag value and 
pass it through an internal API to the HTTP stack; the HTTP stack will 
encod it in a Etag header according to HTTP. In other words, since the 
value of the Etag is selected by the XCAP application and pass to the 
HTTP stack, we don't break HTTP by including it in a 200 OK for a DELETE 
response. Comments?

Regards,

     Miguel
--
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland


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