RE: [Simple] Update to xcap package

[hisham.khartabil at nokia.com]

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 28.February.2004 00:22
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: CBoulton@ubiquity.net; simple@ietf.org
> Subject: Re: [Simple] Update to xcap package
> 
> 
> 
> inline.
> 
> hisham.khartabil@nokia.com wrote:
> 
> > 
> >> -----Original Message----- From: ext Jonathan Rosenberg
> >> [mailto:jdrosen@dynamicsoft.com] Sent: 25.February.2004 18:28 To:
> >> Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: CBoulton@ubiquity.net;
> >> simple@ietf.org Subject: Re: [Simple] Update to xcap package
> 
> >> Can you provide some motivating cases for 1 and 2? Is there 
> >> something in CPCP?
> > 
> > 
> > In CPCP, you might need to replace a resource in the ACL, or change
> > its access-type from allowed to blocked. The way XCAP is specified
> > now, as we discussed, you need to know the exact position for the
> > resource you want replace (they don't have unique IDs 
> besides the URI
> > they carry). This might be ok, if we always assume that the client
> > has an exact copy of what is on the server. I.e. The client MUST
> > always know the number of elements present and provide the position
> > where to insert the new element as the last element, and therefore
> > knows the exact position of the element to replace.
> 
> This is really an important assumption to verify or reject.
> 
> Things can get a lot easier and more flexible if we can 
> generally assume 
> that the client has a copy of the data its modifying, so that 
> it can use 
> position to effect insertions and modifications.
> 
> If its not possible, then I think we need to insist on unique 
> attributes 
> or it just gets really out of hand.
> 
> 
> > 
> > If that can't be guaranteed then we need 1 and 2 above for CPCP.
> > 
> > My proposal is:
> > 
> > a. If there is an attribute that uniquely identifies an 
> element, then
> > the client uses that to insert and/or replace. b. If there is no
> > attribute that uniquely identifies an element, then the client can
> > only insert an element as the last one in a list.
> 
> In both cases, I think that insertion should take place at the end of 
> the list. This vastly simplifies subsequent position based 
> operations on 
> the document.
> 
> > 
> > It would also be nice if, for a, the client can indicate 
> the position
> > it wants to insert, for hashing reasons.
> 
> This appears hard to do. I was unable to come up with a 
> specific reason 
> it would be needed. What do you mean by hashing?

In the xcap package NOTIFY, there is a hash. The problem is, as we have been discussion, in that a server can insert an element in different positions. Mandating the client to specify the position is one way of solving the hashing problem (of course, the other way is to mandate that a server always appends at the end. I'm not sure how feasible that is since we want to make use of currently existing http servers)..

/Hisham


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

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