--- 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>