Subject: [Simple] Re: Conflict in draft-ietf-simple-xcap-12

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 15:44:28 -0500

Correct, this is a bug in the spec. Section 7.11 is incorrect. The 
behavior in this area changed later in the evolution of the spec, and 
the text in 7.11 is leftover. I will correct in auth48.

-Jonathan R.

[email-masked] wrote:

> Hello, 
> 
> I have a problem with draft-ietf-simple-xcap-12. In my opinion following
> parts of the draft are in conflict:
> 
> 7.11 Conditional operations
> ...
> In another example, a client may wish to insert a new element into a
>    document, but wants to be sure that the insertion will only take
>    place if that element does not exist.  In other words, the client
>    wants the PUT operation to be a creation, not a replacement.  To
>    accomplish that, the client can insert the If-None-Match header field
>    into the PUT request, with a value of *.  This tells the server to
>    reject the request with a 412 if resource exists.
> ...
> 
> 8.2.6.  Conditional Processing
> 
>    A PUT request for an XCAP resource, like any other HTTP resource, can
>    be made conditional through usage of the If-Match and If-None-Match
>    header fields.  For a replacement, these are processed as defined in
>    [6].  For an insertion of an element or attribute, conditional
>    operations are permitted.  The entity tag that is used for the
>    procedures in [6] is the one for all of the resources within the same
>    document as the parent of the element or attribute being inserted.
>    One way to think of this is that, logically speaking, on receipt of
>    the PUT request, the XCAP server instantiates the etag for the
>    resource referenced by the request, and then applies the processing
>    of the request.  Because of this behavior, it is not possible to
>    perform a conditional insert on an attribute or element conditioned
>    on the operation being an insertion and not a replacement.  In other
>    words, a conditional PUT of an element or attribute with an If-None-
>    Match: * will always fail.
> 
> 
> The former part says that I can use "If-None-Match: *" in PUT request to
> ensure creation. The latter says that PUT request with "If-None-Match:
> *" always fails.
> 
> Could you please comment on this?
> 
> Thank you, 
> 
> Silvestr Peknik
> Software Specialist
> TietoEnator Czech s.r.o.
> 

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

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

---

From: "Eduardo Martins" <[email-masked]>
Date: Mon, 26 Feb 2007 22:52:53 +0000

Also, a little error in page 39:

    <el1 att="second"/><el1 att="third">

should be

    <el1 att="second"/><el1 att="third"/>

Best regards,

Eduardo Martins

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 18:05:05 -0500

OK, I'll fix.

Thanks,
Jonathan R.

Eduardo Martins wrote:

> On 2/26/07, *Jonathan Rosenberg* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     [email-masked]
>     <mailto:[email-masked]> wrote:
> 
>      > Hello,
>      >
>     [email-masked]
>     <mailto:[email-masked]>                              FAX:   (973)
>     952-5050
>     [email-masked] <mailto:[email-masked]>

---

From: "Eduardo Martins" <[email-masked]>
Date: Wed, 28 Feb 2007 00:05:27 +0000

Hi Jonathan, found another error, this time in Section 7.7:

               As with element insertions and replacements, the
GET(PUT(x))==x
               property introduces limitations on attribute insertions and
               replacements.  It will not be possible to replace the
attribute value
               of an attribute, when that attribute is the sole unique
element
               identifier, and the URI contains a node selector that uses
the
               previous value of the attribute to select the affected
element.  This
               is the use case in the example above.  Instead, the element
can be
               selected positionally, or its entire parent replaced.

It should be "on attribute replacements" only.

Regards,

Eduardo Martins