issue-32 MUST support OPTIONS
authorJohn Arwe
Mon, 08 Jul 2013 11:17:22 -0400
changeset 158 8af0b25f2748
parent 152 938e7d21cc10
child 159 e098f668a10d
issue-32 MUST support OPTIONS
ldp.html
--- a/ldp.html	Mon Jul 08 08:59:47 2013 -0400
+++ b/ldp.html	Mon Jul 08 11:17:22 2013 -0400
@@ -563,21 +563,55 @@
 		especially partial replacement, of their resources [[!RFC5789]]. No
 		minimal set of patch document formats is mandated by this document.
 	</div>
+
 	<div id="ldpr-4_7_2" class="rule">4.7.2 LDPR servers 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_1_11">enable simple creation and modification</a> of LPDRs.
 	</div>
+
 	<div id="ldpr-4_7_3" class="rule">4.7.3 LDPR servers SHOULD NOT allow clients to create new resources using PATCH.
 		<a href="#ldpc-HTTP_POST">POST (to an LDPC)</a> and/or <a href="#ldpc-HTTP_PUT">PUT</a> should be used as the standard way to create new LDPRs.
 	</div>
 	
 	<div class="ldp-issue-pending">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
+	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
+	</div>
+
+	<div id="ldpr-4_7_4" class="rule">4.7.4 LDPR servers that support PATCH MUST
+		include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
+		requests, listing patch document media type(s) supported by the server.
+	</div>
+	
+	<div class="ldp-issue-pending">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/17">ISSUE-17</a></div>
 	changesets as a recommended PATCH format
 	</div>
 </section>
 
 <section>
+<h2 id="ldpr-HTTP_OPTIONS">HTTP OPTIONS</h2>
+	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPRs 
+		beyond those in [[!HTTP11]].  Other sections of this specification, for example 
+		<a href="#ldpr-HTTP_PATCH">PATCH</a> and <a href="#ldpr-paging-HTTP_OPTIONS">Paging</a>,
+		add other requirements on <code>OPTIONS</code> responses.
+		</p>
+
+	<div class="ldp-issue-pending">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
+	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
+	</div>
+
+	<div id="ldpr-4_8_1" class="rule">4.8.1 LDPR servers MUST support the HTTP <code>OPTIONS</code> method.</div>
+		
+	<div id="ldpr-4_8_2" class="rule">4.8.2 LDPR servers MUST indicate their support for HTTP Methods by
+		responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
+		Method tokens in the HTTP response header “<code>Allow</code>”.
+	</div>
+		
+</section>
+
+<section>
 <h2 id="ldpr-Paging">Paging</h2>
 <em>Suggest creating a separate "last" section for LDPRs to not clutter everything else</em>
 
@@ -740,9 +774,15 @@
 
 <section>
 <h3 id="ldpr-paging-HTTP_OPTIONS">HTTP OPTIONS</h3>
-<div id="ldpr-4_8_2_1" class="rule">4.8.2.1 LDPR servers MUST indicate their support for client-initiated paging by
-	responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP
-	response header for link relations using the header name of <code>Link</code> and link relation type is <code>first</code> [[!RFC5988]].
+
+	<div class="ldp-issue-pending">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
+	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
+	</div>
+
+<div id="ldpr-4_9_3_1" class="rule">4.9.3.1 LDPR servers MUST indicate their support for client-initiated paging by
+	responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
+	response header for link relations using the header name of <code>Link</code> and link relation type <code>first</code> [[!RFC5988]].
 </div>
 </section>