--- a/ldp.html Fri Oct 25 10:09:43 2013 -0400
+++ b/ldp.html Fri Oct 25 14:35:31 2013 -0400
@@ -5,6 +5,8 @@
- 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.
+ - Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
+ Maybe also insert HEAD on base as new first example instead of relying on text alone.
- The word "canonical" is used twice in the document. Since we do not deal with URI
canonicalization in the specification, I would remove the word and the meaning of
the sentences is the same.
@@ -224,13 +226,13 @@
</ol>
<p>This specification discusses standard HTTP and RDF techniques that you
should use when constructing clients and servers that
- read and write <a title="Linked Data Platform Resource">Linked Data Platform Resources</a>.
+ create, read, and write <a title="Linked Data Platform Resource">Linked Data Platform Resources</a>.
A companion document discusses best practices that you
should use, and anti-patterns you should avoid, when constructing these clients and servers.
</p>
- <p>This specification also provides a widely re-usable pattern to deal with large RDF resources.
- Depending on the server’s capabilities, a GET request on a <a>Linked Data Platform Resource</a> can
- return a subset of the resource (one page), that provides access to subsequent pages
+ <p>This specification provides a widely re-usable pattern to deal with large resources.
+ Depending on the server’s capabilities, a GET request on a <a title="Paged resource">resource</a> can
+ return a <a title="Single-page resource">subset of the resource (one page)</a>, that provides access to subsequent pages
(see <a href="#ldpr-Paging" class="sectionRef"></a>). </p>
<p>This specification defines a special type of <a>Linked Data Platform Resource</a>: a
<a title="Linked Data Platform Container">Container</a>. Containers are very useful
@@ -265,7 +267,7 @@
patterns and conventions in <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
<dt><dfn>Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
- <dd>An LDPR representing a collection of same-subject, same-predicate triples which is uniquely identified by a URI
+ <dd>An LDPR representing a collection of <a title="Membership triples">membership triples</a> which is uniquely identified by a URI
that responds to client requests for creation, modification, and enumeration of its members.
<p></p></dd>
@@ -315,9 +317,28 @@
<dd>The predicate of all a LDPC's <a title="Membership triples">membership triples</a>.
<p></p></dd>
- <dt><dfn>Page resource</dfn></dt>
- <dd>A type of LDPR that is associated with another LDPR <var>R</var>, whose representation
- includes a subset of the triples in <var>R</var>.
+ <dt><dfn>Paged resource</dfn></dt>
+ <dd>A resource whose representation may be too large to fit in a single HTTP response, for which an
+ LDP server offers a sequence of single-page resources. When the representations of the sequence's resources
+ are combined by a client, the client has a (potentially incomplete) copy of the paged resource's
+ state. If a paged resource <var>P</var> is an LDPR and is broken into a sequence of pages
+ (single-page resources) <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
+ the representation of each <var>P<sub>i</sub></var> contains
+ a subset of the triples in <var>P</var>.
+ LDP allows paging of resources other than LDPRs, but does not specify how clients combine
+ their representations. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
+ <p></p></dd>
+
+ <dt><dfn>Single-page resource</dfn></dt>
+ <dd>One of a sequence of related resources <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
+ each of which contains a subset of the state
+ of another resource <var>P</var>. <var>P</var> is called the paged resource.
+ </p><p>
+ Note: the choice of terms was designed to help authors and readers clearly differentiate between
+ the <a title="Paged resource"><em>resource being paged</em></a>, and the
+ <a title="Single-page resource"><em>individual page resources</em></a>,
+ in cases where both are mentioned in
+ close proximity. Both are resources in both the HTTP and RDF senses.
<p></p></dd>
<dt><dfn>Non-member resource</dfn></dt>
@@ -474,7 +495,7 @@
<li>Are there some typical vocabularies that should be reused?</li>
</ul>
<p>The following sections define the conformance rules for LDP servers when serving LDPRs.
- This document also explains how to paginate an LDPR's representation if it gets too big.
+ This document also explains <a href="#ldpr-Paging">how to paginate an LDPR's representation</a> if it gets too big.
Companion documents describe additional guidelines for use when interacting with LDPRs.
</p>
@@ -542,11 +563,11 @@
to the resource's HTTP <code>Request-URI</code>. This is notionally equivalent to the
presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in the resource.
The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification in a way
- that clients can introspect dynamically at run-time. Conservative clients should note that
+ that clients can inspect dynamically at run-time. Conservative clients should note that
<a href="#ldpr-4_2_3">a server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
that LDP support advertised on one HTTP <code>Request-URI</code> means that other
resources on the same server are also LDPRs. Each HTTP <code>Request-URI</code> needs to be
- individually introspected by a conservative client, in the absence of outside information.
+ individually inspected by a conservative client, in the absence of outside information.
</div>
<div id="ldpr-4_2_11" class="rule">4.2.11 <a title="LDP server">LDP servers</a>
MUST NOT require LDP clients to implement inferencing in order to recognize the subset
@@ -560,7 +581,7 @@
</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>
+ 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
@@ -571,6 +592,14 @@
document. Natural language constraint documents are therefore permitted,
although machine-readable ones facilitate better client interactions.
</div>
+ <div id="ldpr-page-large" class="rule">4.2.14 <a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
+ pages.
+ See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
+ </div>
+ <div id="ldpr-split-any" class="rule">4.2.15 <a title="LDP server">LDP servers</a> MAY
+ treat any resource (LDPR or not) as a <a title="Paged resource">paged resource</a>.
+ See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
+ </div>
</section>
@@ -719,7 +748,7 @@
<section id="ldpr-HTTP_HEAD">
<h2>HTTP HEAD</h2>
- <p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
+ <p>Note that certain LDP mechanisms, such as <a href="#ldpr-Paging">paging</a>, rely on HTTP headers, and HTTP generally requires that
<code>HEAD</code> responses include the same headers as <code>GET</code> responses.
Thus, implementers should also carefully read sections <a href="#ldpr-HTTP_GET"></a>
and <a href="#ldpr-HTTP_OPTIONS"></a>.</p>
@@ -776,8 +805,9 @@
<p>It sometimes happens that a
resource is too large to reasonably transmit its representation in a
single HTTP response. This will be especially true if the resource
- representation includes many triples both from its own representation and
- from the representations of any of the member resources. A client could anticipate that a resource will be too large -
+ is a container whose
+ representation includes many triples both from itself and
+ from its member resources. A client could anticipate that a resource will be too large -
for example, a client tool that accesses defects may assume that an
individual defect will usually be of sufficiently constrained size
that it makes sense to request all of it at once, but that the
@@ -785,11 +815,11 @@
Alternatively, a server could recognize that a resource that has been
requested is too big to return in a single message.</p>
<p>
- To address this problem, LDPRs should support a technique called Paging. Paging can be achieved with a
- simple RDF pattern. For each resource, <code><resourceURL></code>, we define a new
+ To address this problem, resource should support a technique called Paging. Paging can be achieved with a
+ simple pattern. For each resource, <code><resourceURL></code>, we define a new
'first page' resource. In this example, its URL will be <code><resourceURL>?firstPage</code>,
but servers are free to construct the URL as they see fit.
- The triples in the representation of the each page
+ The triples in the representation of the each page of an LDPR
are typically a subset of the triples in the resource
- same subject, predicate and object.
</p>
@@ -797,21 +827,27 @@
resource by returning the first page resource –
using a <a href="#status-code-related-content"><code>209 Related Content</code></a> response
with a <code>Location</code> header containing the URL for the page
- resource. Alternatively, clients may introspect the resource for a paged representation
+ resource. Alternatively, clients may inspect the resource for a paged representation
and use it preferentially when available.</p>
<p>
Looking at an example resource representing Example Co.'s customer
- relationship data, we’ll split the response across two pages.
- To find the URL of the first page, the client makes a <code>OPTIONS</code> request
- to the resource's URL, and in the response looks for a HTTP <code>Link</code>
+ relationship data, identified by the URI <code>http://example.org/customer-relations</code>,
+ we’ll split the response across two pages.
+ To find out if the resource supports paging, and if it does the URL of the first page,
+ the client makes a <code>OPTIONS</code> or <code>HEAD</code> request
+ to <code>http://example.org/customer-relations</code>, and in the response looks for a HTTP <code>Link</code>
header with <code>rel="first"</code>; the target URI in the header is the URL
of the first page resource.
The client then
- requests the first page as <code>http://example.org/customer-relations?firstPage</code>:
+ requests the first page as <code>http://example.org/customer-relations?firstPage</code>, and
+ the server responds with the following representation:
</p>
<pre class="example"># The following is the representation of
# http://example.org/customer-relations?firstPage
+# Requests on the ?firstPage URI will result in responses that include the following HTTP header
+# Link: <http://example.org/customer-relations?p=2>; rel="next"
+# This Link header is how clients discover the URI of the next page in sequence.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@@ -823,11 +859,6 @@
dcterms:title "The customer information for Example Co.";
o:client <client#JohnZSmith>, <client#BettyASmith>, <client#JoanRSmith>.
-<http://example.org/customer-relations?firstPage>
- a ldp:Page;
- ldp:pageOf <http://example.org/customer-relations>;
- ldp:nextPage <http://example.org/customer-relations?p=2>.
-
<client#JohnZSmith>
a foaf:Person;
o:status o:ActiveCustomer;
@@ -843,7 +874,7 @@
<p>
The server determines the size of the pages using application specific methods not defined
- within this specificiation. Note also, the actual name for the query parameter (such as ?p=2) is also
+ within this specificiation. The value of the page URI is also
defined by the server and not this specification.
</p>
<p>
@@ -853,6 +884,9 @@
<pre class="example"># The following is the representation of
# http://example.org/customer-relations?p=2
+#
+# There is no "next" Link in the server's response, so this is the final page.
+#
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@@ -862,11 +896,6 @@
<http://example.org/customer-relations>
o:client <client#GlenWSmith>, <client#AlfredESmith>.
-<http://example.org/customer-relations?p=2>
- a ldp:Page;
- ldp:pageOf <http://example.org/customer-relations>;
- ldp:nextPage rdf:nil.
-
<client#GlenWSmith>
a foaf:Person;
o:status o:ActiveCustomer, o:GoldCustomer;
@@ -878,67 +907,120 @@
foaf:name "Alfred E. Smith".</pre>
<p>
In this example, there are only two customers provided in the
- final page. To indicate this is the last page, a value of <code>rdf:nil</code> is used for the <code>ldp:nextPage</code>
- predicate of the page resource.
+ final page. To indicate this is the last page, the server omits the <code>Link rel="next"</code>
+ header in its response.
</p>
</section>
<section id="ldpr-PagingGET">
<h3>HTTP GET</h3>
-<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, <a title="LDP server">LDP servers</a> that support paging must also follow the requirements in this section</p>
+ <p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>,
+ <a title="LDP server">LDP servers</a> that support paging must
+ also follow the requirements in this section for all <a title="Paged resource">paged resources</a>
+ and their associated <a title="Single-page resource">single-page resources</a>.
+ </p>
- <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 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.
+ <div id="ldpr-pagingGET-first-reqd-onbase" class="rule">4.10.2.1 <a title="LDP server">LDP servers</a> MUST
+ provide an HTTP <code>Link</code>
+ header whose target URI is the <em>first</em> <a title="Single-page resource">single-page resource</a>, and whose link relation type is <code>first</code> [[!RFC5988]]
+ in responses to <code>GET</code> requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the URL of the first page.
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>.
- 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>
- <div id="ldpr-pagingGET-2" class="rule">4.10.2.2 <a title="LDP server">LDP servers</a> MAY split the response representation of any LDPR.
- See <a href="#ldpr-Paging" class="sectionRef"></a> for
- additional details.
- </div>
- <div id="ldpr-pagingGET-3" class="rule">4.10.2.3 <a title="LDP server">LDP servers</a>
- that initiate paging MUST respond to requests for a LDPR
- by returning the first page resource using a <code>209 Related Content</code> response
- with an HTTP <code>Location</code> header providing the first page resource URL.
- </div>
- <div id="ldpr-pagingGET-4" class="rule">4.10.2.4 <a title="LDP server">LDP servers</a> that support paging MUST include a representation for the page resource.
+ would be <code>Link: <?theFirstPage>;rel="first"</code>.
+ If no such <code>Link</code> header is present,
+ then clients have no LDP-defined way to discover that the resource supports paging or the
+ URI of the first page.
</div>
- <div id="ldpr-pagingGET-4_1" class="rule">4.10.2.4.1 The page resource representation MUST have one triple with the subject
- of the page, predicate of <code>ldp:nextPage</code> and
- object being the URL for the subsequent page.
-<pre class="example"><http://example.org/customer-relations?firstPage>
- ldp:nextPage <http://example.org/customer-relations?p=2> .</pre>
+ <div id="ldpr-pagingGET-first-allowed-onpages" class="rule">4.10.2.1.1
+ <a title="LDP server">LDP servers</a> MAY provide
+ a <a href="#ldpr-pagingGET-first-reqd-onbase">first page link</a> when responding to
+ requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
</div>
- <div id="ldpr-pagingGET-4_2" class="rule">4.10.2.4.2 The last page resource representation MUST have one triple with the subject of the
- last page, predicate of <code>ldp:nextPage</code> and object being <code>rdf:nil</code>.
-<pre class="example"><http://example.org/customer-relations?p=2>
- ldp:nextPage rdf:nil .</pre>
+ <div id="ldpr-pagingGET-last-allowed-onbase" class="rule">4.10.2.1.2 <a title="LDP server">LDP servers</a> MAY
+ provide an HTTP <code>Link</code>
+ header whose target URI is the final <a title="Single-page resource">single-page resource</a>,
+ and whose link relation type is <code>last</code> [[!RFC5988]]
+ in responses to <code>GET</code> requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code> and/or
+ requests with a <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the URL of the final page without
+ following a potentially long sequence of next links.
+ If no such <code>Link</code> header is present,
+ then clients can only find the final page using LDP-defined means
+ by following the <code>next</code> links to the end.
</div>
- <div id="ldpr-pagingGET-4_3" class="rule">4.10.2.4.3 The page resource representation SHOULD have one triple to indicate its
- type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page</code>.
- It also SHOULD have 1 triple to indicate the resource it is paging,
- whose subject is the URL of the page, predicate is <code>ldp:pageOf</code>,
- and object is the URL of the LDPR.
-<pre class="example"><http://example.org/customer-relations?firstPage>
- rdf:type ldp:Page;
- ldp:pageOf <http://example.org/customer-relations>.</pre>
+ <div id="ldpr-pagingGET-last-allowed-onpages" class="rule">4.10.2.1.3 <a title="LDP server">LDP servers</a> MAY
+ provide a <a href="#ldpr-pagingGET-last-allowed-onbase">last page link</a>
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
+ </div>
+ <div id="ldpr-pagingGET-next-reqd" class="rule">4.10.2.2 <a title="LDP server">LDP servers</a> MUST
+ provide an HTTP <code>Link</code>
+ header whose target URI is the next page resource, and whose link relation type is <code>next</code> [[!RFC5988]]
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
+ <em>other than the final page</em>
+ as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the URL of the next page.
+ </div>
+ <div id="ldpr-pagingGET-lastnext-prohibited" class="rule">4.10.2.2.1 <a title="LDP server">LDP servers</a> MUST NOT
+ provide a <a href="#ldpr-pagingGET-next-reqd">next page link</a>
+ in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a>
+ as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the end of the page sequence.
+ </div>
+ <div id="ldpr-pagingGET-prev-allowed" class="rule">4.10.2.2.2 <a title="LDP server">LDP servers</a> MAY
+ provide an HTTP <code>Link</code>
+ header whose target URI is the previous page resource, and whose link relation type is <code>prev</code> [[!RFC5988]]
+ in responses to <code>GET</code> requests with any page resource <em>other than the first page</em>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients can discover the URL of the previous page.
+ </div>
+ <div id="ldpr-pagingGET-firstprev-prohibited" class="rule">4.10.2.2.3 <a title="LDP server">LDP servers</a> MUST NOT
+ provide a <a href="#ldpr-pagingGET-prev-reqd">previous page link</a>
+ in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients can discover the beginning of the page sequence.
+ </div>
+ <div id="ldpr-pagingGET-next-reqd" class="rule">4.10.2.2.4 <a title="LDP server">LDP servers</a> MUST
+ provide an HTTP <code>Link</code>
+ header whose target URI is the <a title="Paged resource">paged resource</a>, and whose link relation type is <code>collection</code> [[!RFC5988]]
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
+ as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the URL of the resource whose representation
+ has been broken into pages, in cases where some other actor gives the client
+ a <a title="Single-page resource">single-page resource</a> URL.
+ </div>
+ <div id="ldpr-pagingGET-redirect" class="rule">4.10.2.3 <a title="LDP server">LDP servers</a>
+ that initiate paging for a LDPR MUST respond
+ by returning the first page resource using a <code>209 Related Content</code> response
+ with an HTTP <code>Location</code> header providing the first <a title="Single-page resource">single-page resource</a> URL.
+ </div>
+ <div id="ldpr-pagingGET-page-type-reqd" class="rule">4.10.2.4 <a title="LDP server">LDP servers</a> MUST
+ provide an HTTP <code>Link</code>
+ header whose target URI is <code>http://www.w3.org/ns/ldp#Page</code>, and whose link relation type is <code>type</code> [[!RFC5988]]
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients know that the resource is one of a sequence of pages.
</div>
</section>
<section id="ldpr-paging-HTTP_OPTIONS">
<h3>HTTP OPTIONS</h3>
-<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 <a title="LDP server">LDP servers</a> MUST indicate their support for 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>
+ <p>In addition to the requirements set forth in
+ <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a> on HTTP <code>OPTIONS</code>,
+ <a title="LDP server">LDP servers</a> that support paging must also
+ follow the requirements in this section for all <a title="Paged resource">paged resources</a>.
+ Note that LDP only requires enough from <code>OPTIONS</code>
+ for discovery of paging support on a resource, which is considerably
+ less than is required for HTTP <code>GET</code>.
+ This lowers server implementation effort.
+ </p>
+
+ <div id="ldpr-4_10_3_1" class="rule">4.10.3.1 <a title="LDP server">LDP servers</a> MUST indicate their support for paging by
+ providing a <a href="#ldpr-pagingGET-first-reqd-onbase">first page link</a> when responding to HTTP <code>OPTIONS</code>
+ requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code>.
+ </div>
+
</section> <!-- h3 -->
</section> <!-- h2 -->
@@ -1532,8 +1614,8 @@
</div>
<div id="ldpc-5_4_3" class="rule">5.4.3 <a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations for
- creation of any kind of resource, for example binary resources. See <a href="#ldpc-5_4_13">5.4.13</a> for introspection
- details.
+ creation of any kind of resource, for example binary resources. See <a href="#ldpc-5_4_13">5.4.13</a> for
+ details on how clients can discover whether a LDPC supports this behavior.
</div>
<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, <a title="LDP server">LDP servers</a> MUST create an LDPR from a
RDF representation in the request entity body. The newly created LDPR could also be a LDPC, therefore servers MAY
@@ -1680,7 +1762,8 @@
<section id="ldpc-HTTP_HEAD">
<h2>HTTP HEAD</h2>
- <p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
+ <p>Note that certain LDP mechanisms, such as <a href="#ldpr-Paging">paging</a>,
+ rely on HTTP headers, and HTTP generally requires that
<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also <a title="LDP server">LDP servers</a> must also include HTTP headers
on response to <code>OPTIONS</code>, see <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
Thus, implementers supporting <code>HEAD</code> should also carefully read the
@@ -2037,6 +2120,7 @@
<!-- <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-105 ACTION-105: Update spec to reflect 9/30 resolution moving Paging links to HTTP headers (JA)</li>
<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>