Subject: RE: [Simple] XCAP proposal on conditional inserts

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 11 Jan 2006 12:05:05 -0000

I concur - we need the fix now and the document back in approval.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of [email-masked]
> Sent: 10 January 2006 23:14
> To: [email-masked]; [email-masked]
> Subject: RE: [Simple] XCAP proposal on conditional inserts
> 
> 
> Hi All,
> 
> Without adding further support for one or the other proposed 
> approach, I
> just want to point out the urgent need to solve this (and other
> outstanding) issue(s) related to XCAP. Specifications in other foras
> (like OMA) are dependent on the simple-xcap draft and waiting for xcap
> to change back to RFC Ed queue status.
> 
> Thanks,
> Krisztian
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] 
> >On Behalf Of ext Aki Niemi
> >Sent: Monday, January 09, 2006 8:03 AM
> >To: ext Jonathan Rosenberg
> >Cc: Simple WG
> >Subject: Re: [Simple] XCAP proposal on conditional inserts
> >
> >Hi Jonathan,
> >
> >ext Jonathan Rosenberg wrote:
> >> It is tempting to take a slightly different approach. Call the 
> >> approach above "approach 1". The idea with approach 2 is 
> to declare 
> >> that, even though a resource doesn't exist, it has an 
> etag, and that 
> >> etag is equal to the document's etag, assuming the document does 
> >> exist. Approach 2 would work much like approach 1, except that:
> >> 
> >> * A GET against a non-existent resource would be a 404, 
> >rather than a 
> >> 200 OK with CL of zero
> >> 
> >> * A DELETE would be allowed
> >> 
> >> Note however, that with approach 2, you still cannot support the 
> >> operation that says, "insert this but only if this element doesn't 
> >> already exist in the document".
> >
> >I think that's OK. The most important thing is the ability to 
> >be safe from modifying an element someone else PUT in the 
> >meantime, by doing an insert. I think clients will in most 
> >cases work with cached copies anyway. And it's enough to be 
> >able to condition changes to the entire document using the 
> >etags, not so much of single elements.
> >
> >> Approach 2 has the problem that it
> >> seriously bends (and possibly breaks), an underlying http 
> assumption 
> >> about the scope and meaning of etags. That might have odd and 
> >> unpredicatable interactions with caching systems and other http 
> >> intermediaries. For this reason, I wouldn't recommend it.
> >
> >But XCAP already instructs clients to use the no-cache 
> >directive, and probably PUTs are anyway authenticated. These 
> >should be quite strong indicators to any HTTP intermediaries 
> >that they should not cache these XCAP requests.
> >
> >> So, I would like to make the concrete proposal of moving to 
> >approach 1. 
> >> The main drawback I see is the loss of the ability to insert an 
> >> element if an element with that same name/attribute already exist.
> >> 
> >> Comments?
> >
> >I like approach 2. In an ideal world, I'd prefer the 
> >node-selector as a query string (as discussed back in Nov 04), 
> >but I can live with approach
> >2 since it demonstrates similar good properties like returning 
> >a 404 for a non-existent node.
> >
> >Cheers,
> >Aki
> >
> >_______________________________________________
> >Simple mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/simple
> >
> 
> _______________________________________________
> 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: "Hu Bo \(Cory\), SLC COM CD/MN R&D Core \(BJ\)" <[email-masked]>
Date: Fri, 13 Jan 2006 16:59:15 +0800

Thanks for response 
I read again and guess my thought was that if the concept "empty
elements" were imported in xcap model, that might confuse the existing
understanding on client side.
Please see some questions inline:

>Jonathan Rosenberg wrote:
>
>Responses inline.
>
>Hu Bo (Cory), SLC COM CD/MN R&D Core (BJ) wrote:
>
>> Hi,Jonathan,
>> 
>> My question is:
>> How could client tell if the state("empty" or "not empty") 
>of an element is synchronized with server?
>> 
>> if a client has a cache like:
>> <test>
>>    <el1>1</el1>
>>    <el1>2</el1>
>> </test>
>> While server has
>> <test>
>>    <el1>1</el1>
>> </test>
>> Then client make a creation for el1[3]
>> PUT test/el1[3] with
>> <el1>3</el1>
>> My understanding is: Without conditional insert, old xcap 
>will fail this attemp. By new definition it will succeed.
>
>In the current model, this request will succeed if it is not 
>conditioned. 

In draft-ietf-simple-xcap-08 page 36 line 14:
   If a position is indicated, the server MUST insert the element so
   that it is in the "earliest nth" position.  Earliest nth position
   means that it MUST be inserted so that there are n-1 elements before
   it with the same element name, and for all insertion positions where
   this is true, it is inserted such that as many sibling elements
   appear after it as possible.
My understanding is the request PUT test/el1[3] will fail, if there's
only one <el1> element under <test> on server side.

>If its conditioned based on a wildcard etag (*) or the 
>current document etag, then in the current model it would fail.
>
>In the proposed model, the request would succeed if it is not 
>conditioned. If it is conditioned based on the wildcard etag or the 
>current document etag, it would succeed. For other etag values 
>it would 
>fail.
>
>
>> Now the server copy is:
>> <test>
>>    <el1>1</el1>     //index 1
>>    <el1>3</el1>     //index 3
>> </test>
>
>No - <el1>2</el1> should still be there.

How come?
Assume we start with server document:
<test>
    <el1>1</el1>
</test>
+ request PUT test/el1[3]
My understanding in the proposed model(approach 1) the result would be
<test>
    <el1>1</el1>  //postion 1
                         //postion 2  there is an empty element
    <el1>3</el1>  //postion 3
</test>

>
>> How to modify the position "3" element?  PUT test/el1[2] OR PUT 
>test/el1[3]?
>
>Assuming you start with the document above (which, as I said, 
>would not 
>be whats there), it would be PUT test/el1[2].
>
>> I propose approach 1 working with some limitation like:
>> For client and server, there shouldn't be an understanding 
>that an empty element is present unless it's the last one 
>under an existing parent.
>> That would mean:
>> 1.Insert of an element after an empty one is not allowed.
>
>Right. This is true in the current spec.
>
>> 2.deletion of an element will shift the index up.
>
>I'm not sure what you mean by "index".

Sorry about the confusing expression, I meant position.

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

---

From: "Anders Lindgren C \(HF/EAB\)" <[email-masked]>
Date: Fri, 13 Jan 2006 16:53:22 +0100

Hi Aki and others,
As I see the main requirement is to be able to use the document's etag ,
when creating a new element inside a document in order to be able to
handle inserts from different clients towards the same document. Another
requirement is as I see it to keep the solution as "understandable" as
possible I therefore like the ideas of approach 2 to keep error messages
like 404 when trying to fetch a non-existing element and to be able to
do DELETE of the element the same way as I do DELETE of a document. 

Cheers
Anders 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Aki Niemi
Sent: den 9 januari 2006 17:03
To: ext Jonathan Rosenberg
Cc: Simple WG
Subject: Re: [Simple] XCAP proposal on conditional inserts

Hi Jonathan,

ext Jonathan Rosenberg wrote:
> approach above "approach 1". The idea with approach 2 is to declare 
> that, even though a resource doesn't exist, it has an etag, and that 
> * A GET against a non-existent resource would be a 404, rather than a 
> 200 OK with CL of zero
> 

I think that's OK. The most important thing is the ability to be safe
from modifying an element someone else PUT in the meantime, by doing an
insert. I think clients will in most cases work with cached copies
anyway. And it's enough to be able to condition changes to the entire
document using the etags, not so much of single elements.

> seriously bends (and possibly breaks), an underlying http assumption 

But XCAP already instructs clients to use the no-cache directive, and
probably PUTs are anyway authenticated. These should be quite strong
indicators to any HTTP intermediaries that they should not cache these
XCAP requests.

> So, I would like to make the concrete proposal of moving to approach
1. 
> element if an element with that same name/attribute already exist.

I like approach 2. In an ideal world, I'd prefer the node-selector as a
query string (as discussed back in Nov 04), but I can live with approach
2 since it demonstrates similar good properties like returning a 404 for
a non-existent node.

Cheers,
Aki