ldp.html
changeset 393 8197019f4604
parent 389 f1dbb042137b
child 395 0408e1e5bbf8
--- a/ldp.html	Tue Oct 22 16:30:30 2013 -0400
+++ b/ldp.html	Fri Oct 25 10:04:31 2013 -0400
@@ -2,6 +2,7 @@
 <!-- 
  Editor TODO:
    - Once companion documents have URLs, link to them.  Search on "companion".
+   - In #ldpr-HTTP_POST, move "Clients can create LDPRs via" content into an intro/overview section and add PATCH.
    - Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
      and see if there is a friendlier way to phrase it.
    - The word "canonical" is used twice in the document. Since we do not deal with URI 
@@ -520,6 +521,7 @@
 	<div id="ldpr-4_2_8" class="rule">4.2.8 <a title="LDP server">LDP server</a> responses MUST use entity tags (either weak or strong 
 ones) as response <code>ETag</code> header values.
 	</div>
+	<!-- Action-110 removed this 2013-10-25
 	<div id="ldpr-4_2_9" class="rule">4.2.9 LDPR
 		servers SHOULD enable simple creation and modification of LDPRs.
 		It is
@@ -531,6 +533,7 @@
 		that can modify resources. For some server applications, excessive
 		constraints on modification of resources may be required.
 	</div>
+	-->
 	<div id="ldpr-4_2_10" class="rule">4.2.10 <a title="LDP server">LDP servers</a>
 		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
 		with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
@@ -555,6 +558,19 @@
 		<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results 
 		in the creation of a new resource.
 	</div>
+	<div id="ldpr-4_2_13" class="rule">4.2.13 <a title="LDP server">LDP servers</a> MUST 
+		publish any constraints on <a title="LDP client">LDP clients’</a> ability to 
+		create or update LDPRs, by adding a Link header with <code>rel='describedby'</code> 
+		[[!POWDER-DR]] to all responses to requests which fail due to violation of 
+		those constraints.  For example, a server that refuses resource creation 
+		requests via HTTP PUT, POST, or PATCH would return this <code>Link</code> header on its 
+		4xx responses to such requests.
+		The same <code>Link</code> header MAY be provided on other responses.  LDP neither 
+		defines nor constrains the representation of the link's target resource; 
+		as stated in [[POWDER-DR]], the target might (or might not) be a POWDER 
+		document.  Natural language constraint documents are therefore permitted, 
+		although machine-readable ones facilitate better client interactions.
+	</div>
 
 </section>
 
@@ -565,7 +581,7 @@
 	<div id="ldpr-4_3_2" class="rule">4.3.2 <a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in 
 		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
 	</div>
-	<div id="ldpr-4_3_3" class="rule">4.3.3 <a title="LDP server">LDP servers</a> SHOULD provide a <code>text/turtle</code>
+	<div id="ldpr-4_3_3" class="rule">4.3.3 <a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
 		representation of the requested LDPR [[!TURTLE]].
 	</div>
 	<!-- Action-108 removed this 2013-10-22
@@ -588,17 +604,23 @@
 <h2>HTTP POST</h2>
 	<p>This specification adds no new requirements on HTTP <code>POST</code> for LDPRs 
 		even when the LDPR supports that method.  This specification does not impose any
-		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
-	<p>Creation of LDPRs can be done via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) or
+		new requirement to support that method, and [[!HTTP11]] makes it optional.
+	</p>
+	<p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) or
 		<code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef"></a>) to a LDPC, see those 
-		sections for more details.</p>
+		sections for more details.  Any server-imposed constraints on LDPR creation or update  
+		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
+	</p>
 </section>
 
 <section id="ldpr-HTTP_PUT">
 <h2>HTTP PUT</h2>
 	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPRs 
 		only when the LDPR supports that method.  This specification does not impose any
-		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+		new requirement to support that method, and [[!HTTP11]] makes it optional.
+		Any server-imposed constraints on LDPR creation or update  
+		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
+	</p>
 		
 	<div id="ldpr-4_5_1" class="rule">4.5.1 If a HTTP <code>PUT</code> is accepted on an existing resource, 
 		<a title="LDP server">LDP servers</a> MUST
@@ -708,19 +730,18 @@
 <h2>HTTP PATCH</h2>
 	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPRs 
 		only when the LDPR supports that method.  This specification does not impose any
-		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>	
+		new requirement to support that method, and [[!HTTP11]] makes it optional.
+		Any server-imposed constraints on LDPR creation or update  
+		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
+	</p>	
 	<!-- Action-108 removed this 2013-10-22
 	<div id="ldpr-4_8_1" class="rule">4.8.1 <a title="LDP server">LDP servers</a> MAY implement HTTP <code>PATCH</code> to allow modifications,
 		especially partial replacement, of their resources [[!RFC5789]]. No
 		minimal set of patch document formats is mandated by this document.
 	</div>
 	-->
-	<div id="ldpr-4_8_2" class="rule">4.8.2 <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 <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
-	</div>
 	<div id="ldpr-4_8_3" class="rule">4.8.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
-		<a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpc-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
+		<a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpr-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
 	</div>
 	<div id="ldpr-4_8_4" class="rule">4.8.4 <a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
 		include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
@@ -868,13 +889,13 @@
 
 	<div id="ldpr-pagingGET-1" class="rule">4.10.2.1 <a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
 		pages. In responses to <code>GET</code> requests with an LDPR as the <code>Request-URI</code>, 
-		<a title="LDP server">LDP servers</a> that support paging SHOULD provide an HTTP <code>Link</code>
+		<a title="LDP server">LDP servers</a> that support paging MUST provide an HTTP <code>Link</code>
 		header whose target URI is the first page resource, and whose link relation type is <code>first</code> [[!RFC5988]]. 
 		This is the mechanism by which clients discover the URL of the first page.  If no such <code>Link</code>
 		header is present, then conservative clients will assume that the LDPR does not support paging.
 		For example, if there is a LDPR with URL <code>&lt;resourceURL&gt;</code> that supports paging and whose
 		first page URL is <code>&lt;resourceURL&gt;?theFirstPage</code>, then the corresponding link header
-		would be <code>Link: &lt;?theFirstPage&gt;;rel="first"</code>.
+		would be <code>Link: &lt;?theFirstPage&gt;;rel='first'</code>.
 		The representation for any page, including the first, will include
 		the URL for the next page. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
 	</div>
@@ -1491,7 +1512,10 @@
 <h2>HTTP POST</h2>
 	<p>This specification imposes the following new requirements on HTTP <code>POST</code> for LDPCs 
 		only when an LDPC supports that method.  This specification does not impose any
-		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+		new requirement to support that method, and [[!HTTP11]] makes it optional.
+		Any server-imposed constraints on creation or update  
+		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
+	</p>
 		
 	<div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create member resources by submitting a representation as
 		the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, <a title="LDP server">LDP servers</a> MUST
@@ -1591,7 +1615,10 @@
 <h2>HTTP PUT</h2>
 	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPCs 
 		only when an LDPC supports that method.  This specification does not impose any
-		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+		new requirement to support that method, and [[!HTTP11]] makes it optional.
+		Any server-imposed constraints on creation or update  
+		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
+	</p>
 		
 	<div id="ldpc-5_5_1" class="rule">5.5.1 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>membership triples</a>; 
 		if the server receives such a request, it SHOULD respond with a 409
@@ -1664,7 +1691,10 @@
 <h2>HTTP PATCH</h2>
 	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPCs 
 		only when a LDPC supports that method.  This specification does not impose any
-		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+		new requirement to support that method, and [[!HTTP11]] makes it optional.
+		Any server-imposed constraints on LDPR creation or update  
+		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
+	</p>
 		
 	<div id="ldpc-5_8_1" class="rule">5.8.1 <a title="LDP server">LDP servers</a> are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
 		method for updating LDPC non-membership properties.
@@ -2005,8 +2035,9 @@
 public draft it has been changed from.
 </p>
 
-<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote>  -->
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
 <ul>
+    <li>2013-10-25 - Resolve ACTION-110 Update spec to reflect 10/21 resolution for normative changes to align vanilla/chocolate (JA)</li>
     <li>2013-10-22 - Resolve ACTION-109 Update spec to reflect 10/21 resolution for ignoring triples on PUT (JA)</li>
     <li>2013-10-22 - Resolve ACTION-107 Update spec to reflect 10/07 resolution on 5.6.2 LDPC deletion (JA)</li>
     <li>2013-10-22 - Resolve ACTION-102 Make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete. (JA)</li>