Subject: RE: [Simple] XCAP - Idempotent Delete

From: [email-masked]
Date: Mon, 2 Aug 2004 19:17:54 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 01.August.2004 20:17
> To: Joel M. Halpern
> Cc: [email-masked]
> Subject: Re: [Simple] XCAP - Idempotent Delete
> 
> 
> 
> 
> Joel M. Halpern wrote:
> 
> > I noticed in reading the recent XCAP draft that in making 
> everything 
> > Idempotent, certain restrictions were introduced.
> > 
> > Given a document
> >    <foo>
> >      <bar> contenta </bar>
> >      <bar> contentb </bar>
> >      <bar> contentc </bar>
> >    </foo>
> > one can replace the second bar with a path of the form /foo/bar[2].
> > However, one can not delete that second element with /foo/bar[2], 
> > because that delete, if applied a second time, would 
> produce a different 
> > document (i.e. it is not idempotent.)
> 
> That's not the intent. The intent is that it is allowed.
> 
> The definition of idempotent is that a series of N operations 
> have the 
> same effect as 1. If I do N DELETE operations to foo/bar[2], 
> the first 
> causes the delete, and the rest generate 404. The net result 
> is that N 
> of the operations have the same result as 1, and thus the 
> operation is 
> idempotent.

If I do the first DELETE on foo/bar[2], I end up with

    <foo>
      <bar> contenta </bar>
      <bar> contentc </bar>
    </foo>

If I do a second DELETE on foo/bar[2], I end up with

    <foo>
      <bar> contenta </bar>
    </foo>

Since the <bar> with value "contectc" is now the <bar> element in the second position. Is the idempotent?

Regards,
Hisham

> 
> 
> > 
> > I can live with this restriction.
> > But it does awkward.
> > Also, the server is require to check the condition, which 
> makes for some 
> > interesting error checking code.
> 
> Jari had a similar impression, so clearly there is text in 
> here that is 
> conveying an intent that I am not seeing. Can you point to 
> the specific 
> text that is leading you to this conclusion?
> 
> 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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 02 Aug 2004 14:18:34 -0400

inline.

> Since the <bar> with value "contectc" is now the <bar> element in the second position. Is the idempotent?

No, it is not. My bad. I had missed this case. I think Jari has been 
trying to point this out but somehow I could not get it into my head.

In this context, yes, I think we need to prohibit this. The server would 
need to check that, after the DELETE, the URI in the r-uri does not 
evaluate to an existing resource.

This problem only arises with positional deletions. Using absolute ones 
(i.e,. using an index), or even positional+attribute, you will never run 
into this problem, and I think its a good idea to note this. Its the 
same kind of problem as insertion - the URI needs to be built to satisfy 
TWO properties - it identifies the resource after insertion, but doesnt 
exist before. Deletion is just the opposite, it identifies the resource 
before deletion, and nothing afterwards. THus, its the inverse of the 
insertion constraint.

So, I will document this further restriction and the workarounds.

-Jonathan R.