Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2
authorsspeiche
Mon, 08 Jul 2013 17:03:13 -0400
changeset 171 bfb383feed88
parent 170 4bba75f6d0af
child 172 469924f45fb0
Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2
ldp.html
--- a/ldp.html	Mon Jul 08 16:38:49 2013 -0400
+++ b/ldp.html	Mon Jul 08 17:03:13 2013 -0400
@@ -523,6 +523,8 @@
 	<p>This specification imposes the following new requirements on HTTP DELETE 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>
+	<p>Additional requirements on HTTP DELETE of LDPRs within containers can be found in
+	<a href="ldpc-HTTP_DELETE">section 5.6</a>.</p>
 		
 	<div id="ldpr-4_5_1" class="rule">4.5.1 LDPR servers MUST remove the resource identified by the Request-URI.
 		After a successful HTTP DELETE, a subsequent HTTP GET on the same
@@ -545,9 +547,7 @@
 		Thus, implementers should also carefully read the
 		<a href="#ldpr-HTTP_GET">GET section</a>.</p>
 	<div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST support the HTTP HEAD method.</div>
-	<div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MUST indicate their support for HTTP Methods by
-		responding to a HTTP HEAD request on the LDPR’s URL with the HTTP
-		Method tokens in the HTTP response header “<code>Allow</code>”.
+	<div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MUST support the HTTP response headers defined in section <a href="#ldpr-HTTP_OPTIONS">4.8 HTTP OPTIONS</a>.
 	</div>
 </section>
 
@@ -1552,7 +1552,7 @@
 	
 	<div id="ldpc-5_6_4" class="rule">5.6.4 When a LDPC member resource originally created by the LDPC (for example, one whose 
 	representation was HTTP POST'd to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
-	created an associated LDPR (see <a href="ldpc-5_4_12">5.4.12</a>), the LDPC server must also remove the associated LDPR it created.
+	created an associated LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>), the LDPC server must also remove the associated LDPR it created.
 	</div>	
 	
 	
@@ -1563,18 +1563,35 @@
 <h2 id="ldpc-HTTP_HEAD">HTTP HEAD</h2>
 
 	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
-		HEAD responses include the same headers as GET responses.  
+		HEAD responses include the same headers as GET responses. Also LDPR servers must also include HTTP headers
+		on response to OPTIONS, see <a href="#ldpr-4_6_2">4.6.2</a>.
 		Thus, implementers supporting HEAD should also carefully read the
-		<a href="#ldpc-HTTP_GET">GET section</a>.</p>
+		<a href="#ldpc-HTTP_GET">GET section</a> and <a href="#ldpc-HTTP_OPTIONS">OPTIONS section</a>.</p>
+	
+</section>
 
-	<div id="ldpc-5_7_1" class="rule">5.7.1  
+<section>
+<h2 id="ldpc-HTTP_PATCH">HTTP PATCH</h2>
+	<p>This specification imposes the following new requirements on HTTP PATCH 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>
+		
+	<div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as the preferred
+		method for updating LDPC non-membership properties.
+	</div>
+</section>
+
+<section>
+<h2 id="ldpc-HTTP_OPTIONS">HTTP OPTIONS</h2>
+
+	<div id="ldpc-5_9_1" class="rule">5.9.1  
 		LDPC servers SHOULD define a corresponding
 		<a>non-member resource</a>
 		to support requests for information about a LDPC
 		without retrieving a full representation including all of its members; 
 		see section <a href="#ldpc-get_non-member_props">5.1.2 Retrieving Only Non-member Properties</a> for
 		examples. 
-		In responses to <code>GET</code> requests with an LDPC as the Request-URI, 
+		In responses to <code>OPTIONS</code> requests with an LDPC as the Request-URI, 
 		LDPC servers that define a non-member resource SHOULD provide an HTTP <code>Link</code>
 		header whose target URI is the <a>non-member resource</a>, and whose link relation type is 
 		<code>http://www.w3.org/ns/ldp#non-member-resource</code> [[!RFC5988]]. 
@@ -1588,23 +1605,11 @@
 		would be <code>Link: &lt;?nonMemberProperties&gt;;rel="http://www.w3.org/ns/ldp#non-member-resource"</code>
 	</div>
 	
-	<div id="ldpc-5_7_2" class="rule">5.7.2 When a LDPC member non-LDPR (e.g. binary) originally created by the LDPC (for example, one whose 
+	<div id="ldpc-5_9_2" class="rule">5.9.2 When a LDPC member non-LDPR (e.g. binary) originally created by the LDPC (for example, one whose 
 	representation was HTTP POST'd to the LDPC and then referenced by a membership triple) it might have created an associated LDPR to contain data about the 
-	non-LDPR (see <a href="ldpc-5_4_12">5.4.12</a>).  For non-LDPRs that have this associated LDPR, an LDPC server provide an HTTP <code>Link</code>
+	non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-LDPRs that have this associated LDPR, an LDPC server provide an HTTP <code>Link</code>
 	header whose target URI is the <a>associated LDPR</a>, and whose link relation type is 
 	<code>meta</code> [[!RFC5988]]</div>
-	
-</section>
-
-<section>
-<h2 id="ldpc-HTTP_PATCH">HTTP PATCH</h2>
-	<p>This specification imposes the following new requirements on HTTP PATCH 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>
-		
-	<div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as the preferred
-		method for updating LDPC non-membership properties.
-	</div>
 </section>
 </section>
 
@@ -1692,6 +1697,7 @@
 <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
 -->
 <ul>
+	<li>2013-07-08 - Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2 (SS)</li>
 	<li>2013-07-08 - ISSUE-15 Inserted 5.4.12, 5.6.4, 5.7.2 to describe link-relation meta usage (SS)</li>
 	<li>2013-07-08 - ISSUE-79 ldp:contains  (JA)</li>
 	<li>2013-07-08 - ISSUE-80 Accept-Post (JA)</li>