--- a/ldp.html Mon Mar 03 14:14:48 2014 -0500
+++ b/ldp.html Mon Mar 03 14:23:55 2014 -0500
@@ -605,7 +605,6 @@
<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
</p>
- <!-- TODO: Should we move these to LDP-RS section? They are generic enough. -->
<section id="ldpr-put-replaceall"><h2 class="normal">If a HTTP <code>PUT</code> is accepted on an existing resource,
<a title="LDP server">LDP servers</a> MUST
replace the entire persistent state of the identified resource with
@@ -617,7 +616,41 @@
with existing state stored on the server for a resource MUST use HTTP
<code>PATCH</code>, not HTTP <code>PUT</code>.
</h2></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
+
+ <section id="ldpr-put-simpleupdate"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
+ requiring detailed knowledge of server-specific constraints.
+ This is a consequence of the requirement to enable simple creation and modification of LDPRs.
+ </h2></section><!-- Was 4.5.7 / #ldpr-4_5_7 -->
+ <section id="ldprs-put-servermanagedprops"><h2 class="normal">
+ If an otherwise valid HTTP <code>PUT</code> request is received
+ that attempts to change properties the server does not allow clients to modify,
+ <a title="LDP server">LDP servers</a> MUST
+ respond with a 4xx range status code (typically
+ 409 Conflict).
+ <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+ information about which properties could not be
+ persisted.
+ The format of the 4xx response body is not constrained by LDP.
+ </h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
+ <blockquote>
+ Non-normative note: Clients might provide properties equivalent to those already in the resource's state,
+ e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the
+ server-controlled properties are identical on the GET response and the subsequent PUT request.
+ </blockquote>
+
+ <section id="ldprs-put-failed"><h2 class="normal">
+ If an otherwise valid HTTP <code>PUT</code> request is received that contains properties the server
+ chooses not to persist, e.g. unknown content,
+ <a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
+ [[HTTP11]].
+ <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+ information about which properties could not be
+ persisted.
+ The format of the 4xx response body is not constrained by LDP. LDP servers
+ expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
+ </h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
+
<section id="ldpr-put-precond"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
header and HTTP <code>ETags</code> to ensure it isn’t
modifying a resource that has changed since the client last retrieved
@@ -630,11 +663,7 @@
<section id="ldpr-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
</h2></section><!-- Was 4.5.6 / #ldpr-4_5_6 -->
-
- <section id="ldpr-put-simpleupdate"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
- requiring detailed knowledge of server-specific constraints.
- This is a consequence of the requirement to enable simple creation and modification of LDPRs.
- </h2></section><!-- Was 4.5.7 / #ldpr-4_5_7 -->
+
</section>
<section id="ldpr-HTTP_DELETE">
@@ -808,41 +837,6 @@
</section> <!-- ldprs-HTTP_GET -->
-<section id="ldprs-HTTP_PUT">
-<h2>HTTP PUT</h2>
-
-<!-- TODO: Should we make them apply to non-RDF as well? -->
- <section id="ldprs-put-servermanagedprops"><h2 class="normal">
- If an otherwise valid HTTP <code>PUT</code> request is received
- that attempts to change triples the server does not allow clients to modify,
- <a title="LDP server">LDP servers</a> MUST
- respond with a 4xx range status code (typically
- 409 Conflict).
- <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
- information about which triples could not be
- persisted.
- The format of the 4xx response body is not constrained by LDP.
- </h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
- <blockquote>
- Non-normative note: Clients might provide triples equivalent to those already in the resource's state,
- e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the
- server-controlled triples are identical on the GET response and the subsequent PUT request.
- </blockquote>
-
- <section id="ldprs-put-failed"><h2 class="normal">
- If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server
- chooses not to persist, e.g. unknown content,
- <a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
- [[HTTP11]].
- <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
- information about which triples could not be
- persisted.
- The format of the 4xx response body is not constrained by LDP. LDP servers
- expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
- </h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
-
-</section> <!-- ldprs-HTTP_PUT -->
-
</section> <!-- ldprs RDF Source-->
<section id="ldpnr">
@@ -2210,6 +2204,7 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
<ul>
+ <li>2014-03-03 - Tweaked LDPR PUT clauses to better match new defn of LDPR (SS) </li>
<li>2014-03-03 - Folded #ldpclients section into #ldprs (SS) </li>
<li>2014-03-01 - Split out different kinds of LDPRs into their own subsection (SS)</li>
<li>2014-02-28 - Combined rules for container triples (SS) </li>