--- 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><resourceURL></code> that supports paging and whose
first page URL is <code><resourceURL>?theFirstPage</code>, then the corresponding link header
- would be <code>Link: <?theFirstPage>;rel="first"</code>.
+ would be <code>Link: <?theFirstPage>;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>