Subject: [Simple] diffs in xcap

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 18:19:05 -0500

Folks,

Based on discussion during the meeting, I have updated the core xcap 
spec to disallow idempotent requests which are idempotent using 
properties besides GET(PUT(x))=x. This change has showed up in the 
following places:

Section 7, next to last paragprah before section 7.1. New paragraph reads:

<t> HTTP also specifies that PUT and DELETE requests are
idempotent. This means that, if the client performs a PUT on a
document and it succeeds, it can perform the same PUT, and the
resulting document will look the same. Similarly, when a client
performs a DELETE, if it succeeds, a subsequent DELETE to the same URL
will generate a 404; the resource no longer exists on the server since
it was deleted by the previous DELETE operation. To maintain this
property, the client SHOULD construct its URLs such that, after the
modification has taken place, the URL in the request will point to the
resource just inserted for PUT (i.e., the body of the request), and
will point to nothing for DELETE. If this property is maintained, it
is the case that GET to the URL in the PUT will return the same
content (i.e., GET(PUT(X)) == x). This property implies
idempotency. Although a request can still be idempotent if it does not
possess this property, XCAP does not permit such requests. If the client's
request does not have this property, the server will reject the
request with a 409 and indicate a cannot-insert error condition. </t>

Section 7.4, first full paragraph on page 24. New text:

<t>To be certain that element insertions have the GET(PUT(x))==x
property, the client can check that the attribute predicates in the
final path segment of the URL match the attributes of the element in
the body of the request. As an example of an request that would not
have this property and therefore not be idempotent, consider the
following PUT request (URLs are line-folded for readability): </t>

Section 7.7, first full paragraph on page 26. New text:

<t>To be certain that attribute insertions have the GET(PUT(x))==x
property, the client can check that any attribute predicate in the
path segment that selects the element into which the attribute is
inserted, matches a different attribute than the one being inserted by
the request. As an example of a request that would not have this
property and therefore not be idempotent, consider the following PUT
request (URLs are line folded for readability): </t>

Section 8.2.3, fourth paragraph. New text:

<t> It is possible that the element cannot be inserted such that the
request URI, when evaluated, returns the content provided in the
request. Such a request is not allowed for PUT. This happens when the
element in the body is not described by the expression in the target
selector. An example of this case is described in <xref
target="sec:crel"/>. If this happens the server MUST NOT perform the
insertion, and MUST reject the request with a 409 response. The body
of the response SHOULD contain a detailed conflict report containing
the &lt;cannot-insert&gt; element. It is important to note that schema
compliance does not play a role while performing the insertion. That
is, the decision of where the element gets inserted is dictated
entirely by the structure of the request-URI, the current document,
and the rules in this specification.  </t>

Section 10.1, definition of <cannot-insert>:

<t hangText="&lt;cannot-insert&gt;:">This indicates that the requested
PUT operation could not be performed because a GET of that resource
after the PUT would not yield the content of the PUT request.</t>

(this was updated in the XML schema as well)

The updated version with these changes can be found at:
http://www.jdrosen.net/papers/draft-ietf-simple-xcap-05.txt

which should appear in the archives shortly. This version also fixes a 
BNF bug which resulted in the production for AUID only containing a 
single character.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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: [email-masked]
Date: Wed, 17 Nov 2004 10:56:20 +0200

The changes below will be in the version of the draft that will be sent to IESG. A WGLC for the whole draft will not be issued again. So, if you have any comments about those changes, please speak up now and before the end of the week.

Thanks,
Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 17.November.2004 01:19
> To: Simple WG
> Subject: [Simple] diffs in xcap
> 
> 
> Folks,
>