Changed Paging Spec to NOTE
authorAshok Malhotra <Ashok.Malhotra@Oracle.com>
Mon, 01 Jun 2015 12:09:45 -0400
changeset 970 295c847870d9
parent 969 df17601347b7
child 971 33b18d1dfa8c
Changed Paging Spec to NOTE
ldp-paging-norespec 1.0.htm
ldp-paging-norespec 1.0_files/W3C-NOTE.css
ldp-paging-norespec 1.0_files/w3c_home.png
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-paging-norespec 1.0.htm	Mon Jun 01 12:09:45 2015 -0400
@@ -0,0 +1,2120 @@
+<!DOCTYPE html>
+<html dir="ltr" typeof="bibo:Document w3p:NOTE" prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#" lang="en"><head><meta property="dc:language" content="en" lang="">
+    <title>Linked Data Platform Paging 1.0</title>
+    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    <!-- 
+      === NOTA BENE ===
+      For the three scripts below, if your spec resides on dev.w3 you can check them
+      out in the same tree and use relative links so that they'll work offline,
+     -->
+     
+    
+    <style type="text/css">
+    	div.rule {padding-top: 1em;}
+    	div.ldp-issue-open {
+	    	border-color: #E05252;
+			background: #FBE9E9;
+			padding: 0.5em;
+			margin: 1em 0;
+			position: relative;
+			clear: both;
+			border-left-width: .5em;
+			border-left-style: solid;
+    	}
+    	div.ldp-issue-pending {
+	    	border-color: #FAF602;
+			background: #F7F6BC;
+			padding: 0.5em;
+			margin: 1em 0;
+			position: relative;
+			clear: both;
+			border-left-width: .5em;
+			border-left-style: solid;
+    	}
+    	div.ldp-issue-closed {
+	    	border-color: #009900;
+			background: #BCF7CF;
+			padding: 0.5em;
+			margin: 1em 0;
+			position: relative;
+			clear: both;
+			border-left-width: .5em;
+			border-left-style: solid;
+    	}
+    	div.ldp-issue-title {
+    	    color: #E05252;
+    	    padding-right: 1em;
+            min-width: 7.5em;
+    	}
+		.atrisk {
+			padding:    1em;
+			margin: 1em 0em 0em;
+			border: 1px solid #f00;
+			background: #ffc;
+		}
+		.atrisktext {
+			/* content:    "Feature At Risk"; */
+			display:    block;
+			width:  150px;
+			margin: -1.5em 0 0.5em 0;
+			font-weight:    bold;
+			border: 1px solid #f00;
+			background: #fff;
+			padding:    3px 1em;
+		}
+		.normal { 
+			font-weight: normal;
+			font: normal 100% sans-serif;
+		}
+		.indented { 
+			margin-left: +3em;
+		}
+		tr:nth-of-type(odd),.oddrow { 
+			background:#F2F2F2; /* light grey, just enough to differentiate from white */
+		}
+		td { 
+			padding:0 +1ex 0 +1ex; /* add a bit of space from rule/edge to text */
+		}
+		
+    </style>
+    <style type="text/css" media="all">
+    	code {
+    	    font-weight:bold;
+			font-size:larger;
+    	}
+		 /* ReSpec uses color ff4500 for code elements, which does not print well on some black & white printers
+		    and is a little hard to read for some folks even on-line. 
+			The default code font size was also somewhat too small/hard to read.
+		*/
+    </style>
+  <style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 { 
+    text-transform:     lowercase;
+    font-variant:       small-caps;
+    font-style:         normal;
+    color:              #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+    border: none;
+}
+
+dfn {
+    font-weight:    bold;
+}
+
+a.internalDFN {
+    color:  inherit;
+    border-bottom:  1px solid #99c;
+    text-decoration:    none;
+}
+
+a.externalDFN {
+    color:  inherit;
+    border-bottom:  1px dotted #ccc;
+    text-decoration:    none;
+}
+
+a.bibref {
+    text-decoration:    none;
+}
+
+cite .bibref {
+    font-style: normal;
+}
+
+code {
+    color:  #C83500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+    text-decoration:    none;
+}
+
+a .secno, a .figno {
+    color:  #000;
+}
+
+ul.tof, ol.tof {
+    list-style: none outside none;
+}
+
+.caption {
+    margin-top: 0.5em;
+    font-style:   italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+    border-spacing: 0;
+    border-collapse:    collapse;
+    border-bottom:  3px solid #005a9c;
+}
+
+.simple th {
+    background: #005a9c;
+    color:  #fff;
+    padding:    3px 5px;
+    text-align: left;
+}
+
+.simple th[scope="row"] {
+    background: inherit;
+    color:  inherit;
+    border-top: 1px solid #ddd;
+}
+
+.simple td {
+    padding:    3px 10px;
+    border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+    background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+    margin-top: 0;
+}
+
+.section dd > p:last-child {
+    margin-bottom: 0;
+}
+
+.section dd {
+    margin-bottom:  1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+    margin-bottom:  0;
+}
+
[email protected] print {
+    .removeOnSave {
+        display: none;
+    }
+}
+</style><style>/* --- EXAMPLES --- */
+div.example-title {
+    min-width: 7.5em;
+    color: #b9ab2d;
+}
+div.example-title span {
+    text-transform: uppercase;
+}
+aside.example, div.example, div.illegal-example {
+    padding: 0.5em;
+    margin: 1em 0;
+    position: relative;
+    clear: both;
+}
+div.illegal-example { color: red }
+div.illegal-example p { color: black }
+aside.example, div.example {
+    padding: .5em;
+    border-left-width: .5em;
+    border-left-style: solid;
+    border-color: #e0cb52;
+    background: #fcfaee;
+}
+
+aside.example div.example {
+    border-left-width: .1em;
+    border-color: #999;
+    background: #fff;
+}
+aside.example div.example div.example-title {
+    color: #999;
+}
+</style><link href="ldp-paging-norespec%201.0_files/W3C-NOTE.css" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+<body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
+  <p>
+      
+        
+            <a href="http://www.w3.org/"><img src="ldp-paging-norespec%201.0_files/w3c_home.png" alt="W3C" height="48" width="72"></a>
+        
+      
+  </p>
+  <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Paging 1.0</h1>
+  
+  <h2 id="w3c-working-group-note-11-december-2014"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time property="dcterms:issued" class="dt-published" datetime="2014-12-11">11 December 2014</time></h2>
+  <dl>
+    
+      <dt>This version:</dt>
+      <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-paging-20141211/">http://www.w3.org/TR/2014/NOTE-ldp-paging-20141211/</a></dd>
+      <dt>Latest published version:</dt>
+      <dd><a href="http://www.w3.org/TR/ldp-paging/">http://www.w3.org/TR/ldp-paging/</a></dd>
+    
+    
+      <dt>Latest editor's draft:</dt>
+      <dd><a href="http://www.w3.org/2012/ldp/hg/ldp-paging.html">http://www.w3.org/2012/ldp/hg/ldp-paging.html</a></dd>
+    
+    
+    
+      <dt>Implementation report:</dt>
+      <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/paging/ldp-paging.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/paging/ldp-paging.html</a></dd>
+    
+    
+    
+    
+      <dt>Previous version:</dt>
+      <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2014/WD-ldp-paging-20140909/">http://www.w3.org/TR/2014/WD-ldp-paging-20140909/</a></dd>
+    
+    
+    <dt>Editors:</dt>
+    <dd class="p-author h-card vcard" property="bibo:editor" resource="_:editor0"><span property="rdf:first" typeof="foaf:Person"><meta property="foaf:name" content="Steve Speicher"><a class="u-url url p-name fn" property="foaf:homepage" href="http://stevespeicher.blogspot.com/">Steve Speicher</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
+<span property="rdf:rest" resource="_:editor1"></span>
+</dd>
+<dd class="p-author h-card vcard" resource="_:editor1"><span property="rdf:first" typeof="foaf:Person"><meta property="foaf:name" content="John Arwe"><a class="u-url url p-name fn" property="foaf:homepage" href="https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7">John Arwe</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
+<span property="rdf:rest" resource="_:editor2"></span>
+</dd>
+<dd class="p-author h-card vcard" resource="_:editor2"><span property="rdf:first" typeof="foaf:Person"><meta property="foaf:name" content="Ashok Malhotra"><a class="u-url url p-name fn" property="foaf:homepage" href="mailto:[email protected]">Ashok Malhotra</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com/">Oracle Corporation</a></span>
+<span property="rdf:rest" resource="rdf:nil"></span>
+</dd>
+
+    
+    
+  </dl>
+  
+  
+  
+  
+    
+      <p class="copyright">
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+        2014
+        
+        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>). 
+        
+        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+        
+          <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+        
+        rules apply.
+      </p>
+    
+  
+  <hr>
+</div>
+<section property="dc:abstract" class="introductory" id="abstract"><h2 resource="#h-abstract" id="h-abstract"><span property="xhv:role" resource="xhv:heading">Abstract</span></h2><p>
+This document describes a HTTP-based protocol for clients and servers to
+ be able to efficiently retrieve large Linked Data Platform
+Resource representations by splitting up the responses into separate 
+URL-addressable page resources.
+</p></section><section id="sotd" class="introductory"><h2 resource="#h-sotd" id="h-sotd"><span property="xhv:role" resource="xhv:heading">Status of This Document</span></h2>
+  
+    
+      
+        <p>
+          <em>This section describes the status of this document at the time of its publication.
+          Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
+          latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
+          http://www.w3.org/TR/.</em>
+        </p>
+        
+        
+   <p>
+		The Working Group has addressed all
+		raised issues, and other substantive changes have been made, including the decision to separate LDP Paging
+		from the Linked Data Platform [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].  A test suite has also been made available [<cite><a href="#bib-LDP-PAGING-TESTSUITE" class="bibref">LDP-PAGING-TESTSUITE</a></cite>]. 
+   </p>
+   <p>
+   Due to lack of sufficient implementations, this specification is being published as a W3C NOTE.
+  
+          This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Working Group Note.
+          
+          
+            If you wish to make comments regarding this document, please send them to 
+            <a href="mailto:[email protected]">[email protected]</a> 
+            (<a href="mailto:[email protected]?subject=subscribe">subscribe</a>,
+            <a href="http://lists.w3.org/Archives/Public/public-ldp-comments/">archives</a>).
+          
+          
+          
+          
+          
+            
+            All comments are welcome.
+            
+          
+        </p>
+        
+          <p>
+            Please see the Working Group's  <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/paging/ldp-paging.html">implementation
+            report</a>.
+          </p>
+        
+        
+        
+          <p>
+            Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
+            Membership. This is a draft document and may be updated, replaced or obsoleted by other
+            documents at any time. It is inappropriate to cite this document as other than work in
+            progress.
+          </p>
+        
+        
+        
+        <p>
+          
+            This document was produced by a group operating under the 
+            <a id="sotd_patent" property="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
+            Policy</a>.
+          
+          
+          
+            
+              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
+              disclosures</a> 
+            
+            made in connection with the deliverables of the group; that page also includes
+            instructions for disclosing a patent. An individual who has actual knowledge of a patent
+            which the individual believes contains
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
+            Claim(s)</a> must disclose the information in accordance with
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+          
+          
+        </p>
+        
+          <p>
+            This document is governed by the  <a id="w3c_process_revision" href="http://www.w3.org/2005/10/Process-20051014/">14 October 2005 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
+          </p>
+        
+        
+      
+    
+  
+</section><section id="toc"><h2 resource="#h-toc" id="h-toc" class="introductory"><span property="xhv:role" resource="xhv:heading">Table of Contents</span></h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#intro"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a class="tocxref" href="#terms"><span class="secno">2. </span>Terminology</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#terms-from-ldp"><span class="secno">2.1 </span>Terms re-used from the Linked Data Platform</a></li><li class="tocline"><a class="tocxref" href="#terms-from-paging"><span class="secno">2.2 </span>Terms normatively defined by this specification</a></li><li class="tocline"><a class="tocxref" href="#conventions"><span class="secno">2.3 </span>Conventions Used in This Document</a></li></ul></li><li class="tocline"><a class="tocxref" href="#conformance"><span class="secno">3. </span>Conformance</a></li><li class="tocline"><a class="tocxref" href="#ldpp-ex-mx"><span class="secno">4. </span>Example paging message exchanges</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#ldpp-ex-no-paging"><span class="secno">4.1 </span>Traditional flow without paging</a></li><li class="tocline"><a class="tocxref" href="#ldpp-ex-paging-303"><span class="secno">4.2 </span>Simple paging flow using redirects</a></li><li class="tocline"><a class="tocxref" href="#ldpp-ex-paging-other-links"><span class="secno">4.3 </span>Optional paging links</a></li></ul></li><li class="tocline"><a class="tocxref" href="#ldppclient"><span class="secno">5. </span>Linked Data Platform Paging Clients</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#general-requirements"><span class="secno">5.1 </span>General requirements</a><ul class="toc"></ul></li><li class="tocline"><a class="tocxref" href="#ldpp-hints"><span class="secno">5.2 </span>Client preferences</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#ldpr"><span class="secno">6. </span>Linked Data Platform Resources</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#ldpr-PagingIntro"><span class="secno">6.1 </span>Paging considerations</a></li><li class="tocline"><a class="tocxref" href="#ldpr-PagingGET"><span class="secno">6.2 </span>HTTP GET</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#ldpc"><span class="secno">7. </span>Linked Data Platform Containers</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#ldpc-general"><span class="secno">7.1 </span>Requirements when paging LDP Containers</a><ul class="toc"></ul></li><li class="tocline"><a class="tocxref" href="#ldpc-informative"><span class="secno">7.2 </span>Ordering of container members across pages</a><ul class="toc"></ul></li><li class="tocline"><a class="tocxref" href="#ldpc-HTTP_GET"><span class="secno">7.3 </span>HTTP GET requirements for member ordering across pages</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#security"><span class="secno">8. </span>Security Considerations</a></li><li class="tocline"><a class="tocxref" href="#ldpr-impl"><span class="secno">A. </span>Paging <abbr title="Linked Data Platform Resources">LDPRs</abbr> without maintaining server-side session state</a></li><li class="tocline"><a class="tocxref" href="#acks"><span class="secno">B. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#history"><span class="secno">C. </span>Change History</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">D. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#normative-references"><span class="secno">D.1 </span>Normative references</a></li><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">D.2 </span>Informative references</a></li></ul></li></ul></section>
+ 
+ 
+ 
+<section property="bibo:hasPart" resource="#intro" typeof="bibo:Chapter" class="informative" id="intro">
+
+<!--OddPage--><h2 resource="#h-intro" id="h-intro"><span property="xhv:role" resource="xhv:heading"><span class="secno">1. </span>Introduction</span></h2><p><em>This section is non-normative.</em></p> 
+	<p>
+		This specification provides a widely re-usable pattern to make the state of a large <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged HTTP resource</a>
+		available as a list of smaller subset resources (<a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">pages</a>) whose 
+		representations are less burdensome for servers to form.
+		<a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">Paged resources</a> must be LDP Resources (<abbr title="Linked Data Platform Resources">LDPRs</abbr>) [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+		Any <abbr title="Linked Data Platform Resource">LDPR</abbr> can be paged, but certain aspects of paging like ordering are only well-defined for 
+		particular sub-classes of <abbr title="Linked Data Platform Resources">LDPRs</abbr>, like
+		LDP-RSs or <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+	</p>
+	<p>
+		When a client attempts to retrieve a <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>, the server either redirects the client to 
+		a "first page" <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">resource</a> or provides the 
+		representation of the "first page" <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">resource</a> in its response, 
+		depending on the client's request preferences and the server's capabilities.  
+		The response 
+		includes links to other page(s) in the sequence, as do subsequent pages.
+		<a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">Paging-aware clients</a>
+		know how to combine pages of an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>, and possibly (via other specifications) other <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+		LDP Paging defines a mechanism by which clients can learn that the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> has been changed 
+		so that they can, for example, abandon a page traversal as early as possible.
+		A detailed example of paging is provided in <a href="#ldpp-ex-mx" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Example paging message exchanges</span></a>.
+	</p>
+	<p>
+		When a <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> is also an <abbr title="Linked Data Platform Container">LDPC</abbr>, some additional efficiencies become possible in cases
+		where the server predictably assigns members to pages and is able to communicate its assignment
+		algorithm to clients.  The <a href="#ldpc" class="sectionRef sec-ref">section <span class="secno">7.</span> <span class="sec-title">Linked Data Platform Containers</span></a> defines a facility to communicate 
+		the sort order of member-to-page assignments, to handle that common implementation algorithm.
+	</p>
+	<p>
+		For context and background, it could be useful to read <a href="#bib-LDP-UCR">Linked Data Platform Use Case and Requirements</a> [<cite><a href="#bib-LDP-UCR" class="bibref">LDP-UCR</a></cite>]. 
+	</p>
+</section>
+	
+<section property="bibo:hasPart" resource="#terms" typeof="bibo:Chapter" id="terms">
+<!--OddPage--><h2 resource="#h-terms" id="h-terms"><span property="xhv:role" resource="xhv:heading"><span class="secno">2. </span>Terminology</span></h2>
+
+<section property="bibo:hasPart" resource="#terms-from-ldp" typeof="bibo:Chapter" id="terms-from-ldp">
+<h3 resource="#h-terms-from-ldp" id="h-terms-from-ldp"><span property="xhv:role" resource="xhv:heading"><span class="secno">2.1 </span>Terms re-used from the Linked Data Platform</span></h3>
+
+<p>This section is non-normative.  It summarizes a subset of terms formally defined in [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] for the reader's convenience.
+</p>
+  <dl class="glossary">	
+
+	<dt><dfn id="dfn-ldp-server">LDP server</dfn></dt>
+	<dd>A conforming HTTP server [<cite><a href="#bib-RFC7230" class="bibref">RFC7230</a></cite>] that follows the rules defined by [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>]
+	    when it is serving <abbr title="Linked Data Platform Resources">LDPRs</abbr> and 
+		<abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+	<p></p></dd>	
+
+	<dt><dfn id="dfn-ldp-client">LDP client</dfn></dt>
+	<dd>A conforming HTTP client [<cite><a href="#bib-RFC7230" class="bibref">RFC7230</a></cite>] that follows the rules defined by [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] when
+	    interacting with a <a class="internalDFN" href="#dfn-ldp-server">LDP server</a>.
+	<p></p></dd>	
+
+	<dt><dfn id="dfn-linked-data-platform-resource">Linked Data Platform Resource</dfn> (<abbr title="Linked Data Platform Resource">LDPR</abbr>)</dt>
+	<dd>A HTTP resource whose state is represented in any way that conforms to the 
+		patterns and conventions in [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].<p></p></dd>
+		
+	<dt><dfn id="dfn-linked-data-platform-rdf-source">Linked Data Platform RDF Source</dfn> (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>)</dt>
+	<dd>An <a class="internalDFN" href="#dfn-linked-data-platform-resource" title="Linked Data Platform Resource"><abbr title="Linked Data Platform Resource">LDPR</abbr></a> whose state is fully represented in RDF [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+	<p></p></dd>	
+
+	<dt><dfn id="dfn-linked-data-platform-container">Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
+	<dd>A <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> representing a collection of <a class="internalDFN" href="#dfn-linked-data-platform-resource" title="Linked Data Platform Resource"><abbr title="Linked Data Platform Resources">LDPRs</abbr></a> linked by
+	<a class="internalDFN" href="#dfn-membership-triples">membership triples</a> and <a class="internalDFN" href="#dfn-containment-triples">containment triples</a> [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-membership-triples">Membership triples</dfn></dt>
+	<dd>A set of triples that lists an <a class="internalDFN" href="#dfn-linked-data-platform-container" title="Linked Data Platform Container"><abbr title="Linked Data Platform Container">LDPC</abbr>'s</a> members [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-containment-triples">Containment triples</dfn></dt>
+	<dd>
+	A set of triples, maintained by an <abbr title="Linked Data Platform Container">LDPC</abbr>, that lists documents created by the <abbr title="Linked Data Platform Container">LDPC</abbr> but not yet deleted [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+	<p></p></dd>
+
+  </dl>
+
+</section>
+    
+<section property="bibo:hasPart" resource="#terms-from-paging" typeof="bibo:Chapter" id="terms-from-paging">
+<h3 resource="#h-terms-from-paging" id="h-terms-from-paging"><span property="xhv:role" resource="xhv:heading"><span class="secno">2.2 </span>Terms normatively defined by this specification</span></h3>
+
+<p>The following terminology is based on <abbr title="World Wide Web Consortium">W3C</abbr>'s Architecture of the World Wide Web [<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>], 
+	Hyper-text Transfer Protocol ([<cite><a href="#bib-RFC7230" class="bibref">RFC7230</a></cite>], [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>]) and Linked Data Platform [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+</p>
+  <dl class="glossary">	
+	<dt><dfn id="dfn-paged-resource">Paged resource</dfn></dt>
+	<dd>A <abbr title="Linked Data Platform Resource">LDPR</abbr> whose representation may be too large for a server to construct in a single HTTP response
+	(e.g. without running out of memory), for which an
+	<a class="internalDFN" href="#dfn-ldp-paging-server">LDP Paging server</a> offers a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a> that allows clients to obtain subsets of its state
+	over some period of time by making multiple HTTP requests.
+	<p>
+	For readers
+	familiar with paged feeds [<cite><a href="#bib-RFC5005" class="bibref">RFC5005</a></cite>], a paged resource is similar to a logical feed.
+	Any resource could be considered to be a paged resource consisting of exactly one page, 
+	although there is no known advantage in doing so.
+	</p>  
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-page-sequence">Page sequence</dfn></dt>
+	<dd>A sequence of related <a class="internalDFN" href="#dfn-linked-data-platform-resource" title="Linked Data Platform Resource"><abbr title="Linked Data Platform Resources">LDPRs</abbr></a>
+	<var>P<sub>1 (first)</sub>, P<sub>2</sub>, ...,P<sub>n (last)</sub></var>, 
+	each of which contains a subset of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s state.  
+	<p>
+	When the representations of the sequence's <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">resources</a>
+	are combined by a client, the client has a copy of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s
+	state; if the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> changed while the client was retrieving the sequence's resources, 
+	then the client's copy of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s state can be incomplete or inconsistent
+	with the state of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> at any single instant in time.
+	Thus, it is impossible to strongly guarantee that the result of this retrieval and combination process is the same state that
+	the client would obtain using a single request (if that were possible), but LDP does provide
+	a way for <a href="#ldpr-notify-changes">clients to detect when the paged resource's state changed</a> during the retrieval process.
+	As long as the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s state did not change during the retrieval process, the 
+	client's copy of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s state will be as accurate as the server implementation
+	allows it to be.
+	</p>  
+	<p>
+	If a paged resource <var>P</var> is a <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>, 
+	the representation of each <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> contains
+	a subset of the triples in <var>P</var>, and a client can merge those graphs to combine them.
+	LDP allows paging of resources other than <a class="internalDFN" href="#dfn-linked-data-platform-rdf-source" title="Linked Data Platform RDF Source">LDP-RSs</a>, 
+	but does not specify how clients combine
+	their representations.  See <a href="#ldpr" class="sectionRef sec-ref">section <span class="secno">6.</span> <span class="sec-title">Linked Data Platform Resources</span></a> for additional details.
+	</p>  
+	For readers
+	familiar with paged feeds [<cite><a href="#bib-RFC5005" class="bibref">RFC5005</a></cite>], a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a> is similar to a paged feed
+	and many of the same consideration (echoed above) apply.
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-in-sequence-page-resource">In-sequence page resource</dfn></dt>
+	<dd>One <abbr title="Linked Data Platform Resource">LDPR</abbr> in a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>, 
+	which contains a subset of the state
+	of another resource <var>P</var>, called the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>.
+	For readers
+	familiar with paged feeds [<cite><a href="#bib-RFC5005" class="bibref">RFC5005</a></cite>], an in-sequence page resource is similar to a feed document.
+	<p>
+	Note: the choice of terms was designed to help authors and readers clearly differentiate between
+	the <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource"><em>resource being paged</em></a>, and the 
+	<a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource"><em>individual page resources</em></a>, 
+	in cases where both are mentioned in
+	close proximity.  
+	</p>
+	<p>
+	Note: page sequences are described and named with respect to how they are traversed starting from the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>,
+	using only <a class="internalDFN" href="#dfn-forward-traversal">forward traversal</a>.
+	This <em>does not</em> imply anything more; the choice is arbitrary.
+	For example, following forward links does not imply that resources later in the sequence are newer; the forward direction might
+	correspond to moving forward or backward in time or along some other dimension, but any such relationship is server-specific.
+	It is not implied by LDP Paging, 
+	absent additional concrete assertions like those <a href="#ldpc-HTTP_GET">defined later</a> for <abbr title="Linked Data Platform Container">LDPC</abbr> representations.
+	</p>
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-first-page-link">first page link</dfn></dt>
+	<dd>A link to the first <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource</a> <var>P<sub>1 (first)</sub></var>
+	of a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>.  The first page is the one that a LDP Paging server
+	redirects to (<code>303</code> response) in response
+	to a retrieval request for the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s URI.
+	Syntactically, a
+	HTTP <code>Link &lt;<var>P<sub>1</sub></var>&gt;; rel="first"</code>
+	header [<cite><a href="#bib-RFC5988" class="bibref">RFC5988</a></cite>].
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-next-page-link">next page link</dfn></dt>
+	<dd>A link to the next <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource</a> 
+	of a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>.  Syntactically, a
+	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel="next"</code>
+	header [<cite><a href="#bib-RFC5988" class="bibref">RFC5988</a></cite>] where 
+	the context URI identifies some <var>P<sub>i=1 (first)...n-1 (next to last)</sub></var> and
+	the target URI identifies <var>P<sub>i+1</sub></var>.
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-last-page-link">last page link</dfn></dt>
+	<dd>A link to the last <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource</a> <var>P<sub>n (last)</sub></var>
+	of a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>.  
+	The last page is the page that terminates a <a class="internalDFN" href="#dfn-forward-traversal">forward traversal</a>, because it contains no <a class="internalDFN" href="#dfn-next-page-link">next page link</a>.
+	Syntactically, a
+	HTTP <code>Link &lt;<var>P<sub>n</sub></var>&gt;; rel="last"</code>
+	header [<cite><a href="#bib-RFC5988" class="bibref">RFC5988</a></cite>].
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-previous-page-link">previous page link</dfn></dt>
+	<dd>A link to the previous <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource</a>
+	of a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>  Syntactically, a
+	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel="prev"</code>
+	header [<cite><a href="#bib-RFC5988" class="bibref">RFC5988</a></cite>] where 
+	the context URI identifies some <var>P<sub>i=2...n (last)</sub></var> and
+	the target URI identifies <var>P<sub>i-1</sub></var>.
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-paging-link">paging link</dfn></dt>
+	<dd>Any of the links defined by LDP Paging: 
+	<a class="internalDFN" href="#dfn-first-page-link" title="first page link">first page links</a>,
+	<a class="internalDFN" href="#dfn-next-page-link" title="next page link">next page links</a>,
+	<a class="internalDFN" href="#dfn-last-page-link" title="last page link">last page links</a>,
+	<a class="internalDFN" href="#dfn-previous-page-link" title="previous page link">previous page links</a>.
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-forward-traversal">forward traversal</dfn></dt>
+	<dd>The process of following <a class="internalDFN" href="#dfn-next-page-link" title="next page link">next page links</a> from
+	some starting point.
+	<p>
+	Note: "forward" should <i>not</i> be read to mean anything more than a name for one direction through the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>.
+	For example, following forward links does not imply that resources later in the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a> are newer; the forward direction might
+	correspond to moving forward in time, but any such relationship is server-specific not implied by LDP Paging 
+	absent additional concrete assertions like those <a href="#ldpc-HTTP_GET">defined later</a> for <abbr title="Linked Data Platform Container">LDPC</abbr> representations.
+	</p>
+	<p></p></dd>
+	
+	<dt><dfn id="dfn-backward-traversal">backward traversal</dfn></dt>
+	<dd>The process of following <a class="internalDFN" href="#dfn-previous-page-link" title="previous page link">previous page links</a> from
+	some starting point.
+	<p>
+	Note: "backward" should <i>not</i> be read to mean anything more than a name for one direction through the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>.
+	</p>
+	<p></p></dd>
+	
+  </dl>
+</section>
+
+<section property="bibo:hasPart" resource="#conventions" typeof="bibo:Chapter" id="conventions">
+<h3 resource="#h-conventions" id="h-conventions"><span property="xhv:role" resource="xhv:heading"><span class="secno">2.3 </span>Conventions Used in This Document</span></h3>
+
+	<p>The namespace for LDP Paging is <code>http://www.w3.org/ns/ldp#</code>.</p>
+	<p>Sample resource representations are provided in <code>text/turtle</code>
+		format [<cite><a href="#bib-turtle" class="bibref">turtle</a></cite>].</p>
+	<p>Commonly used namespace prefixes:</p>
+	<pre style="word-wrap: break-word; white-space: pre-wrap;">	
+	@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
+	@prefix foaf:    &lt;http://xmlns.com/foaf/0.1/&gt;.
+	@prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
+	@prefix ldp:     &lt;http://www.w3.org/ns/ldp#&gt;.
+	</pre>
+</section>
+</section>
+    
+<section property="bibo:hasPart" resource="#conformance" typeof="bibo:Chapter" id="conformance"><!--OddPage--><h2 resource="#h-conformance" id="h-conformance"><span property="xhv:role" resource="xhv:heading"><span class="secno">3. </span>Conformance</span></h2>
+<p>
+  As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
+  and notes in this specification are non-normative. Everything else in this specification is
+  normative.
+</p>
+<p id="respecRFC2119">The key words <em class="rfc2119" title="MAY">MAY</em>, <em class="rfc2119" title="MUST">MUST</em>, <em class="rfc2119" title="MUST NOT">MUST NOT</em>, <em class="rfc2119" title="SHOULD">SHOULD</em>, and <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> are 
+  to be interpreted as described in [<cite><a href="#bib-RFC2119" class="bibref">RFC2119</a></cite>].
+</p>
+
+
+<p>The status of the sections of Linked Data Platform Paging 1.0 (this document) is as follows:</p>
+
+<ul>
+  <li><a href="#intro" class="sectionRef sec-ref">section <span class="secno">1.</span> <span class="sec-title">Introduction</span></a>: <b>non-normative</b></li>
+  <li><a href="#terms" class="sectionRef sec-ref">section <span class="secno">2.</span> <span class="sec-title">Terminology</span></a>
+	<ul>
+	  <li><a href="#terms-from-ldp" class="sectionRef sec-ref">section <span class="secno">2.1</span> <span class="sec-title">Terms re-used from the Linked Data Platform</span></a>: <b>non-normative</b></li>
+	  <li><a href="#terms-from-paging" class="sectionRef sec-ref">section <span class="secno">2.2</span> <span class="sec-title">Terms normatively defined by this specification</span></a>: <b>normative</b></li>
+	  <li><a href="#conventions" class="sectionRef sec-ref">section <span class="secno">2.3</span> <span class="sec-title">Conventions Used in This Document</span></a>: <b>normative</b></li>
+	</ul>
+  </li>
+  <li><a href="#conformance" class="sectionRef sec-ref">section <span class="secno">3.</span> <span class="sec-title">Conformance</span></a>: <b>normative</b></li>
+  <li><a href="#ldpp-ex-mx" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Example paging message exchanges</span></a>: <b>non-normative</b></li>
+  <li><a href="#ldppclient" class="sectionRef sec-ref">section <span class="secno">5.</span> <span class="sec-title">Linked Data Platform Paging Clients</span></a>: <b>normative</b></li>
+  <li><a href="#ldpr" class="sectionRef sec-ref">section <span class="secno">6.</span> <span class="sec-title">Linked Data Platform Resources</span></a>: <b>normative</b></li>
+  <li><a href="#ldpc" class="sectionRef sec-ref">section <span class="secno">7.</span> <span class="sec-title">Linked Data Platform Containers</span></a>: <b>normative</b></li>  
+  <li><a href="#security" class="sectionRef sec-ref">section <span class="secno">8.</span> <span class="sec-title">Security Considerations</span></a>: <b>non-normative</b></li> 
+  <li><a href="#ldpr-impl" class="sectionRef sec-ref">section <span class="secno">A.</span> <span class="sec-title">Paging LDPRs without maintaining server-side session state</span></a>: <b>non-normative</b></li> 
+  <li><a href="#acks" class="sectionRef sec-ref">section <span class="secno">B.</span> <span class="sec-title">Acknowledgements</span></a>: <b>non-normative</b></li> 
+  <li><a href="#history" class="sectionRef sec-ref">section <span class="secno">C.</span> <span class="sec-title">Change History</span></a>: <b>non-normative</b></li> 
+  <li><a href="#normative-references" class="sectionRef sec-ref">section <span class="secno">D.1</span> <span class="sec-title">Normative references</span></a>: <b>normative</b></li>
+  <li><a href="#informative-references" class="sectionRef sec-ref">section <span class="secno">D.2</span> <span class="sec-title">Informative references</span></a>: <b>non-normative</b></li>
+</ul>
+
+<p>A conforming <b><dfn id="dfn-ldp-paging-client">LDP Paging client</dfn></b> is a conforming LDP client [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] that follows the rules defined by LDP Paging.
+</p>
+
+<p>A conforming <b><dfn id="dfn-ldp-paging-server">LDP Paging server</dfn></b> is a conforming LDP server [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] that follows the rules defined by LDP Paging.</p>
+</section>
+
+<section property="bibo:hasPart" resource="#ldpp-ex-mx" typeof="bibo:Chapter" class="informative" id="ldpp-ex-mx">
+<!--OddPage--><h2 resource="#h-ldpp-ex-mx" id="h-ldpp-ex-mx"><span property="xhv:role" resource="xhv:heading"><span class="secno">4. </span>Example paging message exchanges</span></h2><p><em>This section is non-normative.</em></p>
+
+	<p>
+		Example Co.'s customer
+		relationship data is identified by the URI <code>http://example.org/customer-relations</code>,
+		and is retrievable using the same URI.
+	</p>
+
+<section property="bibo:hasPart" resource="#ldpp-ex-no-paging" typeof="bibo:Chapter" id="ldpp-ex-no-paging">
+<h3 resource="#h-ldpp-ex-no-paging" id="h-ldpp-ex-no-paging"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.1 </span>Traditional flow without paging</span></h3>
+
+	<p>
+		A standard HTTP client that knows nothing about LDP paging obtains a representation of the
+		resource in the usual way.
+	</p>
+
+	<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example">GET /customer-relations HTTP/1.1
+Host: example.org
+Accept: text/turtle</pre></div>
+
+	<p>
+		The server response is: 
+	</p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example" id="ldpp-ex-no-paging-resp">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "_87e52ce291112"
+Link: &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
+Allow: GET,OPTIONS,HEAD
+
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
[email protected] &lt;http://example.org/customer-relations&gt;.
+
+&lt;&gt;
+   a o:CustomerRelations;
+   dcterms:title "The customer information for Example Co.";
+   o:client &lt;#JohnZSmith&gt;, &lt;#BettyASmith&gt;, &lt;#JoanRSmith&gt;,
+            &lt;#GlenWSmith&gt;, &lt;#AlfredESmith&gt;. 
+
+&lt;#JohnZSmith&gt;
+   a foaf:Person;
+   o:status o:ActiveCustomer;
+   foaf:name "John Z. Smith".
+   
+&lt;#BettyASmith&gt;
+   a foaf:Person;
+   o:status o:PreviousCustomer;
+   foaf:name "Betty A. Smith".
+ 
+ &lt;#JoanRSmith&gt;
+   a foaf:Person;
+   o:status o:PotentialCustomer;
+   foaf:name "Joan R. Smith".
+ 
+&lt;#GlenWSmith&gt;
+   a foaf:Person;
+   o:status o:ActiveCustomer, o:GoldCustomer;
+   foaf:name "Glen W. Smith".
+
+&lt;#AlfredESmith&gt;
+   a foaf:Person;
+   o:status o:ActiveCustomer, o:BronzeCustomer;
+   foaf:name "Alfred E. Smith".</pre></div>
+
+	<p>
+		As long as the resource being retrieved is small enough that the server can form its
+		representation without running into implementation limits on memory etc., and as long
+		as the client is likewise able to consume these representations, this pattern works
+		fine.  Indeed, it's by far the most common pattern on the Web.
+	</p>
+	<p>
+		At the point where server and/or client constraints or consumption preferences come into play, however, 
+		something else is needed.  LDP Paging addresses this need by giving clients and 
+		servers the ability to partition representations into smaller pieces, transfer
+		as many as the client needs (potentially a small subset of the resource's full
+		state), and allows the client to reassemble the pieces (or not) as it prefers.
+		One sees this pattern in contexts such as search page results, as one common
+		example.
+	</p>
+
+</section>
+
+<section property="bibo:hasPart" resource="#ldpp-ex-paging-303" typeof="bibo:Chapter" id="ldpp-ex-paging-303">
+<h3 resource="#h-ldpp-ex-paging-303" id="h-ldpp-ex-paging-303"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.2 </span>Simple paging flow using redirects</span></h3>
+
+	<p>
+		The simplest possible solution would be to redefine the meaning of the existing
+		URI <code>http://example.org/customer-relations</code> from "all customer relations information"
+		to "the first subset of all customer relations information".  This would require changes to
+		any existing clients whose code was built using the original definition however, so it's 
+		more likely that Example Co. would mint a new URI for "the first subset", define a way to 
+		find subsequent subsets, and have clients use this new "first subset" URI approach.
+	</p>
+	<p>
+		The "first subset" URI approach does not solve the problem of migrating existing clients from the old
+		"all" to the new "first subset" semantic; neither would a <code>303 See Other</code> redirect
+		from the old to the new URI, given the 
+		<a href="http://www.w3.org/2001/tag/issues.html#httpRange-14">widespread historical client practice</a> of automatically
+		following <code>303</code> redirects and treating the redirected-to resource as equivalent
+		to the original, contrary to HTTP.  The safe route is to have clients explicitly tell the server that they
+		are capable of handling the "first subset" semantic on the redirected-to URI; this is what
+		LDP Paging does.
+	</p>
+	<p>
+		A client aware of LDP paging obtains a representation of the
+		resource in the usual way, and also signals its ability to handle redirection to a first-page resource:
+	</p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example">GET /customer-relations HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"</pre></div>
+
+	<p>
+		The server's response contains a <code>303 See Other</code> status code and
+		a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header
+		identifying the target resource, as shown below:
+	</p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example" id="ldpp-ex-paging-303-resp1">HTTP/1.1 303 See Other
+Location: &lt;http://example.org/customer-relations?page1&gt;</pre></div>
+
+	<p>
+		At this point the client does not know if the target
+		resource is "all" or "the first subset"; it has to retrieve the resource to know.
+	</p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example">GET /customer-relations?page1 HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"</pre></div>
+	<p>
+		The server's response is shown below:
+	</p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example" id="ldpp-ex-paging-303-resp2">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "_87e52ce291112"
+Link: &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type",
+      &lt;http://www.w3.org/ns/ldp#Page&gt;; rel="type"
+Link: &lt;http://example.org/customer-relations?p=2&gt;; rel="next"
+Link: &lt;http://example.org/customer-relations&gt;; rel="canonical"; etag="customer-relations-v1"
+Allow: GET,OPTIONS,HEAD
+
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
[email protected] &lt;http://example.org/customer-relations&gt;.
+
+&lt;&gt;
+   a o:CustomerRelations;
+   dcterms:title "The customer information for Example Co.";
+   o:client &lt;#JohnZSmith&gt;, &lt;#BettyASmith&gt;, &lt;#JoanRSmith&gt;. 
+
+&lt;#JohnZSmith&gt;
+   a foaf:Person;
+   o:status o:ActiveCustomer;
+   foaf:name "John Z. Smith".
+&lt;#BettyASmith&gt;
+   a foaf:Person;
+   o:status o:PreviousCustomer;
+   foaf:name "Betty A. Smith".
+ &lt;#JoanRSmith&gt;
+   a foaf:Person;
+   o:status o:PotentialCustomer;
+   foaf:name "Joan R. Smith".</pre></div>
+
+	<p>
+		From this response, the client knows that more data exists and where to find it.
+		The server determines the size of the pages using application-specific methods not defined
+		within this specification, with the client's <code>max-triple-count</code> preference as one
+		input; the simplest method is to make the server's page size equal
+		to the client's preference.  In this example, the server chooses a smaller value so 
+		there is a second page.
+	</p>
+	<ul>
+	<li>
+		The <code>Link: &lt;http://example.org/customer-relations&gt;; rel="canonical"</code>
+		response header tells the client which resource <code>&lt;http://example.org/customer-relations?page1&gt;</code>
+		is a page of.  The <code>etag="customer-relations-v1"</code> parameter value gives the client a way to know,
+		during its page traversal, whether or not the canonical <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> has changed; not all
+		clients will use this information, but it is there for those that can make use of it.
+	</li>
+	<li>
+		The <code>Link: &lt;http://www.w3.org/ns/ldp#Page&gt;; rel="type"</code>
+		response header tells the client that this is one <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>, and therefore it
+		needs to examine the other response headers to see if more data existed in the 
+		canonical <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> when the response
+		was generated by the server.
+	</li>
+	<li>
+		The <code>Link: &lt;http://example.org/customer-relations?p=2&gt;; rel="next"</code>
+		response header tells the client that at least one more <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> exists,
+		and how to retrieve its representation.  The next page link's target URI is 
+		defined by the server and is not constrained by this specification.
+	</li>
+	</ul>
+	<p>
+		The following example shows the message exchange for retrieving
+		the next page:
+	</p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example">GET /customer-relations?p=2 HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"</pre></div>
+	<p>
+		The server's response is shown below: 
+	</p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example" id="ldpp-ex-paging-303-resp3">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "8_7e52ce291112"
+Link: &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type",
+      &lt;http://www.w3.org/ns/ldp#Page&gt;; rel="type"
+Link: &lt;http://example.org/customer-relations&gt;; rel="canonical"; etag="customer-relations-v1"
+Allow: GET,OPTIONS,HEAD
+
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
[email protected] &lt;http://example.org/customer-relations&gt;.
+
+&lt;&gt;
+   o:client &lt;#GlenWSmith&gt;, &lt;#AlfredESmith&gt;. 
+ 
+&lt;#GlenWSmith&gt;
+   a foaf:Person;
+   o:status o:ActiveCustomer, o:GoldCustomer;
+   foaf:name "Glen W. Smith".
+
+&lt;#AlfredESmith&gt;
+   a foaf:Person;
+   o:status o:ActiveCustomer, o:BronzeCustomer;
+   foaf:name "Alfred E. Smith".</pre></div>
+
+	<p>
+		In this example, there are only two customers provided in the
+		second page.  
+	</p>
+		<!-- DONE: show it both ways; if a competing change hit the container, or not.
+			 6.2.2.7's non-normative note covers this case.
+		-->
+	<ul>
+	<li>
+		The <code>Link: &lt;http://www.w3.org/ns/ldp#Page&gt;; rel="type"</code>
+		response header tells the client that this is one <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>, and therefore it
+		needs to examine the other response headers to see if more data existed in the 
+		canonical <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> when the response
+		was generated by the server.
+	</li>
+	<li>
+		The absence of a <code>Link: &lt;http://example.org/customer-relations?p=2&gt;; rel="next"</code>
+		response header tells the client that no more <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>s existed in this <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+		at the time the response was generated; repeating the request might result in a representation with links to more pages,
+		if other processes are updating the customer relations data.
+	</li>
+	<li>
+		Since the <code>etag="customer-relations-v1"</code> parameter value of the canonical <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+		did not change across the client's process of retrieving the entire <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>, it is assured that 
+		the merged response representations are equivalent to what it would have received had the server
+		provided the entire representation of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> in a single <code>200 OK</code> response.
+		The client has <em>no assurance</em> that the current state of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+ remains unchanged
+		since the final page's representation was generated.  For example, 
+after the server constructs the final page representation, another
+		actor could delete <code>client#BettyASmith</code> from the server.
+	</li>
+	</ul>
+
+</section>
+
+<section property="bibo:hasPart" resource="#ldpp-ex-paging-other-links" typeof="bibo:Chapter" id="ldpp-ex-paging-other-links">
+<h3 resource="#h-ldpp-ex-paging-other-links" id="h-ldpp-ex-paging-other-links"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.3 </span>Optional paging links</span></h3>
+
+	<p>
+		The preceding paging examples in this section have all assumed that only <a class="internalDFN" href="#dfn-forward-traversal">forward traversal</a>
+		is supported by the server, to reduce complexity.
+		A server might also support <a class="internalDFN" href="#dfn-backward-traversal">backward traversal</a> through its pages, and/or direct access to the 
+		<a class="internalDFN" href="#dfn-first-page-link" title="first page link">first page</a> and/or <a class="internalDFN" href="#dfn-last-page-link" title="last page link">last page</a> from any <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>.
+		Those options would be reflected by adding some combination of the links below, 
+		or equivalent semantically equivalent syntactic variations of them, to the response messages.
+	</p>
+
+	<ul>
+	<li>
+		The <a class="internalDFN" href="#dfn-first-page-link" title="first page link">first page</a>'s <a href="#ldpp-ex-paging-303-resp2">response message</a> might also have the following links:
+<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example">Link: &lt;&gt;; rel="first"
+Link: &lt;http://example.org/customer-relations?p=2&gt;; rel="last"</pre></div>
+	</li>
+	<li>
+		Any <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>'s response message, including the <a class="internalDFN" href="#dfn-first-page-link" title="first page link">first page</a> and the <a class="internalDFN" href="#dfn-last-page-link" title="last page link">last page</a>,
+		might also have the following links:
+<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example">Link: &lt;http://example.org/customer-relations?page1&gt;; rel="first"
+Link: &lt;http://example.org/customer-relations?p=2&gt;; rel="last"</pre></div>
+	</li>
+	<li>
+		The <a class="internalDFN" href="#dfn-last-page-link" title="last page link">last page</a>'s <a href="#ldpp-ex-paging-303-resp3">response message</a> might also have the following links:
+<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example">Link: &lt;http://example.org/customer-relations?page1&gt;; rel="first"
+Link: &lt;http://example.org/customer-relations?page1&gt;; rel="prev"
+Link: &lt;&gt;; rel="last"</pre></div>
+	</li>
+	</ul>
+
+</section>
+
+</section> <!-- Example message exchanges -->
+
+<section property="bibo:hasPart" resource="#ldppclient" typeof="bibo:Chapter" id="ldppclient">
+<!--OddPage--><h2 resource="#h-ldppclient" id="h-ldppclient"><span property="xhv:role" resource="xhv:heading"><span class="secno">5. </span>Linked Data Platform Paging Clients</span></h2>
+<p>All of the following are conformance rules for <a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging Clients</a>.
+</p>
+<section property="bibo:hasPart" resource="#general-requirements" typeof="bibo:Chapter" id="general-requirements"><h3 resource="#h-general-requirements" id="h-general-requirements"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1 </span>General requirements</span></h3>
+
+	<section property="bibo:hasPart" resource="#ldpp-client-advertise" typeof="bibo:Chapter" id="ldpp-client-advertise"><h4 resource="#h-ldpp-client-advertise" id="h-ldpp-client-advertise" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.1 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a> <em title="MUST" class="rfc2119">MUST</em>
+		<a href="#ldpp-hints">advertise their ability to support LDP Paging</a> on all retrieval requests that normally result in
+		a response containing a representation.
+	</span></h4>
+	</section>
+		
+	<section property="bibo:hasPart" resource="#ldpp-client-traversal" typeof="bibo:Chapter" id="ldpp-client-traversal"><h4 resource="#h-ldpp-client-traversal" id="h-ldpp-client-traversal" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.2 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a> <em title="MUST" class="rfc2119">MUST</em>
+		be capable of at least one of <a class="internalDFN" href="#dfn-forward-traversal">forward traversal</a> and/or <a class="internalDFN" href="#dfn-backward-traversal">backward traversal</a>.
+	</span></h4>
+	</section>
+	
+	<section property="bibo:hasPart" resource="#ldpp-client-linkschg" typeof="bibo:Chapter" id="ldpp-client-linkschg"><h4 resource="#h-ldpp-client-linkschg" id="h-ldpp-client-linkschg" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.3 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a> <em title="MUST NOT" class="rfc2119">MUST NOT</em>
+		assume that any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource's</a> <a class="internalDFN" href="#dfn-paging-link" title="paging link">paging links</a>
+		will remain unchanged when the <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource</a>
+		is retrieved more than once.  Such an assumption would 
+		conflict with a server's ability to 
+		<a href="#ldpr-pagingGET-sequences-change">add pages to a sequence</a> as the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> changes, for example.
+	</span></h4>
+	</section>
+	
+	<section property="bibo:hasPart" resource="#ldpp-client-4xxok" typeof="bibo:Chapter" id="ldpp-client-4xxok"><h4 resource="#h-ldpp-client-4xxok" id="h-ldpp-client-4xxok" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.4 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a> <em title="MUST NOT" class="rfc2119">MUST NOT</em>
+		assume that any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource's</a> <a class="internalDFN" href="#dfn-paging-link" title="paging link">paging links</a>
+		will always be accessible.</span></h4>
+		<blockquote><em>Non-normative note:</em> 
+		Such an assumption would 
+		conflict with a server's ability to <a href="#ldpr-pagingGET-sequences-change">remove pages from a sequence</a> 
+		as the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> changes, for example.
+		One consequence of this is that clients can receive responses with <code>4xx</code> status codes  
+		when following page links, purely due to timing issues and without any error on the part of the client
+		or the server.  Such a response would be unusual, and would likely signal an error, 
+		if the response also indicates that the <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource's</a> 
+		<a href="#ldpr-notify-changes">state has <i>not</i> changed</a> 
+		while the client was traversing its <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">pages</a>.
+		Servers might also limit the lifetime of a particular <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>, and client requests after the server has
+		abandoned that sequence are likely to result in <code>410 Gone</code> or other <code>4xx</code> status codes.
+		</blockquote>
+	
+	</section>
+	
+	<section property="bibo:hasPart" resource="#ldpp-client-paging-incomplete" typeof="bibo:Chapter" id="ldpp-client-paging-incomplete"><h4 resource="#h-ldpp-client-paging-incomplete" id="h-ldpp-client-paging-incomplete" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.5 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a>  
+		<em title="SHOULD NOT" class="rfc2119">SHOULD NOT</em> treat a page sequence as equivalent to the <a class="internalDFN" href="#dfn-paged-resource" title="paged resource">paged resource</a> 
+		when the <a href="#ldpr-notify-changes">paged resource changed</a> 
+		<a href="#ldpr-guarantee-show-unchanged">during retrieval of the page sequence</a>.
+	</span></h4></section>
+
+	<section property="bibo:hasPart" resource="#ldpp-client-nofollow-303" typeof="bibo:Chapter" id="ldpp-client-nofollow-303"><h4 resource="#h-ldpp-client-nofollow-303" id="h-ldpp-client-nofollow-303" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.6 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a>  
+		<em title="MUST NOT" class="rfc2119">MUST NOT</em> treat the target of a <code>303 See Other</code> redirection as a replacement for the original resource.  
+		That is, they cannot treat a <code>303</code> status code as if it was a 
+		<code>307 Temporary Redirect</code> [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>] or <code>308 Permanent Redirect</code> [<cite><a href="#bib-RFC7238" class="bibref">RFC7238</a></cite>],
+		as [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>] makes clear.  This is critical to a client's ability to distinguish between the representation
+		of a single <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> and that of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> when a <a class="internalDFN" href="#dfn-ldp-paging-server">LDP Paging server</a>
+		uses <a href="#ldpr-status-code">redirection</a> as a way to initiate paging.
+	</span></h4></section>
+
+</section>
+
+<section property="bibo:hasPart" resource="#ldpp-hints" typeof="bibo:Chapter" id="ldpp-hints">
+<h3 resource="#h-ldpp-hints" id="h-ldpp-hints"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.2 </span>Client preferences</span></h3>
+	<p>
+		LDP Paging clients <a href="#ldpp-client-advertise">must provide paging-related hints</a> 
+		in order to influence an LDP Paging server's choices.
+	</p>
+
+	<p>
+		This specification introduces new 
+		parameters on the HTTP <code>Prefer</code> request header's
+		<code>return=representation</code> preference [<cite><a href="#bib-RFC7240" class="bibref">RFC7240</a></cite>], <a href="#ldpp-client-advertise">used by clients</a> to 
+		supply a preference that helps the server form a response that is most appropriate to 
+		the client's needs.  The presence of any parameter defined in this section serves several purposes:
+		</p><ul>
+		<li>It signals the client's support for LDP Paging to the request server</li>
+		<li>It communicates the client's maximum desired size for a response representation</li>
+		</ul>
+	<p></p>
+
+	<section property="bibo:hasPart" resource="#ldpr-cli-paging" typeof="bibo:Chapter" id="ldpr-cli-paging"><h4 resource="#h-ldpr-cli-paging" id="h-ldpr-cli-paging" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.2.1 </span>
+		<a class="internalDFN" href="#dfn-ldp-client" title="LDP client">LDP clients</a> <em title="SHOULD" class="rfc2119">SHOULD</em> 
+		be capable of processing successful HTTP <code>GET</code> responses formed by a LDP server
+		that independently initiated paging, returning a page of representation instead of full resource
+		representation [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+	</span></h4>
+	</section> 
+	
+	<p>
+		LDP Paging defines <code>max-triple-count</code>, <code>max-member-count</code>, and <code>max-kbyte-count</code> 
+		as new parameters on the existing 
+		HTTP <code>Prefer</code> request header's
+		<code>return=representation</code> preference [<cite><a href="#bib-RFC7240" class="bibref">RFC7240</a></cite>]; the presence of any of these parameters
+		on the preference, not the preference alone, is what indicates to a server that the client
+		supports LDP Paging.
+		A client communicates its hint(s) to the server by adding the
+		request header with a 
+		<code>return=representation</code> preference that includes any of the following preference parameters
+		</p><table class="indented">
+		<tbody><tr>
+		<td> <code>max-triple-count</code> </td>
+		<td> The maximum decimal number of triples the client wishes to appear on each page.  </td>
+		</tr>
+		<tr>
+		<td> <code>max-kbyte-count</code> </td>
+		<td> The maximum decimal number of kilobytes (1024 byte units) the client wishes to receive as the page's representation.  </td>
+		</tr>
+		<tr>
+		<td> <code>max-member-count</code> </td>
+		<td> The maximum decimal number of members the client wishes to appear on each page.
+				This parameter is only meaningful for paged <a class="internalDFN" href="#dfn-linked-data-platform-container" title="Linked Data Platform Container"><abbr title="Linked Data Platform Containers">LDPCs</abbr></a>.
+		</td>
+		</tr>
+		</tbody></table>
+		<blockquote>
+		<p>
+		The generic preference BNF [<cite><a href="#bib-RFC7240" class="bibref">RFC7240</a></cite>] allows either a quoted string or a token as the value of a 
+		preference parameter.
+		</p>
+		</blockquote>
+	<p></p>
+
+	<p id="prefer-examples-500-triples">
+	Clients interested in receiving at most 500 RDF triples per <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">page</a>
+	would use add this HTTP header on a <code>GET</code> request, as shown in <a href="#ldpp-ex-paging-303" class="sectionRef sec-ref">section <span class="secno">4.2</span> <span class="sec-title">Simple paging flow using redirects</span></a>:
+	<code>Prefer: return=representation; max-triple-count="500"</code>
+	</p>
+
+</section> <!-- Paging hints -->
+
+</section> <!-- Client constraints -->
+
+<section property="bibo:hasPart" resource="#ldpr" typeof="bibo:Chapter" id="ldpr">
+<!--OddPage--><h2 resource="#h-ldpr" id="h-ldpr"><span property="xhv:role" resource="xhv:heading"><span class="secno">6. </span>Linked Data Platform Resources</span></h2>
+
+<section property="bibo:hasPart" resource="#ldpr-PagingIntro" typeof="bibo:Chapter" class="informative" id="ldpr-PagingIntro">
+
+<h3 resource="#h-ldpr-pagingintro" id="h-ldpr-pagingintro"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.1 </span>Paging considerations</span></h3><p><em>This section is non-normative.</em></p>
+
+	<p>
+		As <a href="#intro">described</a> <a href="#ldpp-ex-mx">previously</a>,
+		paging logically breaks up a <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> 
+		into a list of <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resources</a> (pages) whose representations the client can retrieve, and serves each
+		page with links to other <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">pages in the sequence</a>.
+		Clients inspect each response to see if additional pages
+		are available; paging does not affect the choice of HTTP status code.
+		Clients generally have no insight into the allocation of information to pages, 
+		although in <a href="#ldpc">some cases currently defined only for <abbr title="Linked Data Platform Containers">LDPCs</abbr></a> the server can expose its
+		algorithm.
+	</p>
+	<p>
+		Some clients will be interested in knowing whether or not competing requests altered the
+		<a class="internalDFN" href="#dfn-paged-resource">paged resource</a> while the client was retrieving pages, since LDP paging does not guarantee
+		that those alterations were reflected in any <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> received by the client.
+		Regardless of the server implementation, LDP only guarantees that while traversing a series of pages that
+		the client observes data that is equivalent to a database that uses 
+		read committed isolation [<cite><a href="#bib-READ-COMMITTED" class="bibref">READ-COMMITTED</a></cite>]; 
+		specifically, clients can observe 
+		non-repeatable reads [<cite><a href="#bib-NON-REPEATABLE-READS" class="bibref">NON-REPEATABLE-READS</a></cite>] while traversing pages served by 
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a>.
+		LDP Paging does <a href="#ldpr-guarantee-show-unchanged">guarantee</a>, however, that any information in the <abbr title="Linked Data Platform Resource">LDPR</abbr> continuously present (neither added nor deleted) in the 
+		<a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource</a> across the entire period of time when the client is retrieving pages will
+		be present in at least one <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>.
+	</p>
+	<p>
+		LDP Paging defines a mechanism by which <a href="#ldpr-notify-changes">clients can detect that the paged resource has been changed</a> so that they can, for example,
+		abandon a page traversal as early as possible.
+		This provides a stronger guarantee in certain cases
+		than the one described for paged feeds [<cite><a href="#bib-RFC5005" class="bibref">RFC5005</a></cite>], but it does require the client
+		to detect when the condition holds.
+		Paging <i>does not guarantee</i> that it will ever be possible to successfully
+		retrieve all the <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>s without the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+		being added to or changed, so clients requiring such a guarantee 
+		may not find all <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>s usable in practice.
+		A detailed example was provided in <a href="#ldpp-ex-mx" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Example paging message exchanges</span></a>.
+		See <a href="#ldpr-impl" class="sectionRef sec-ref">section <span class="secno">A.</span> <span class="sec-title">Paging LDPRs without maintaining server-side session state</span></a> for server implementation considerations.
+	</p>
+</section>
+
+<section property="bibo:hasPart" resource="#ldpr-PagingGET" typeof="bibo:Chapter" id="ldpr-PagingGET">
+<h3 resource="#h-ldpr-pagingget" id="h-ldpr-pagingget"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2 </span>HTTP GET</span></h3>
+	<p>In addition to the requirements on HTTP <code>GET</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr> [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>], 
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> must 
+		also follow the requirements in this section for all <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resources</a>
+		and their associated <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resources</a>.
+	</p>
+		
+	<section property="bibo:hasPart" resource="#ldpr-page-large" typeof="bibo:Chapter" id="ldpr-page-large"><h4 resource="#h-ldpr-page-large" id="h-ldpr-page-large" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.1 </span>
+		<!-- Remove this clause? No, it was MOVED here from LDP, and as a Must we'd need to define 'large' to test compliance. -->
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">SHOULD</em> allow clients to retrieve large LDP-RSs in
+		pages.
+	</span></h4></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
+	
+	<section property="bibo:hasPart" resource="#ldpr-split-any-resource" typeof="bibo:Chapter" id="ldpr-split-any-resource"><h4 resource="#h-ldpr-split-any-resource" id="h-ldpr-split-any-resource" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.2 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em> 
+		treat any resource (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> or not) as a <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>.
+	</span></h4></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
+
+	<section property="bibo:hasPart" resource="#ldpr-split-any-time" typeof="bibo:Chapter" id="ldpr-split-any-time"><h4 resource="#h-ldpr-split-any-time" id="h-ldpr-split-any-time" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.3 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em> 
+		vary their treatment of any resource (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> or not) as a <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> over time.
+		In other words, given two attempts to retrieve the same resource at different points
+		in time, the server can choose to return a representation of the first page at one time and 
+		of the entire resource at a different time.  Clients distinguish between these cases based
+		on the <a href="#ldpr-status-code">status code</a> 
+		and <a href="#ldpr-pagingGET-page-type-reqd">response headers</a>.
+	</span></h4></section>
+
+	<section property="bibo:hasPart" resource="#ldpp-prefer" typeof="bibo:Chapter" id="ldpp-prefer"><h4 resource="#h-ldpp-prefer" id="h-ldpp-prefer" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.4 </span><a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a>
+		<em title="SHOULD" class="rfc2119">SHOULD</em> respect all of a client's <a href="#ldpp-hints">LDP Paging defined hints</a>, for example 
+		<a href="#ldpp-hints">the largest page size</a>
+		the client is interested in processing,
+		to influence the amount of data returned in representations.</span></h4> 
+	<blockquote>
+		<em>Non-normative note</em>: LDP server implementers should be careful not to interpret a 
+		<code>Prefer return=representation</code> request header that <em>lacks</em> any
+		parameters defined here as a client's request for a <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>.
+		<a href="#ldpp-hints">A client's hints</a> indicate LDP Paging support <em>only</em>
+		when at least one of the preference parameters defined by this specification is present.
+	</blockquote>
+	<blockquote>
+		<em>Non-normative note</em>: LDP server implementers should carefully consider the effects of these
+		preferences on caching, as described in section 2 of [<cite><a href="#bib-RFC7240" class="bibref">RFC7240</a></cite>].
+	</blockquote>
+	<blockquote>
+		<em>Non-normative note</em>: [<cite><a href="#bib-RFC7240" class="bibref">RFC7240</a></cite>] recommends that server implementers include a 
+		<code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
+		behavior with respect to honoring hints from the response content.
+	</blockquote>
+	</section>
+
+	<section property="bibo:hasPart" resource="#ldpp-prefer-unrecognized" typeof="bibo:Chapter" id="ldpp-prefer-unrecognized"><h4 resource="#h-ldpp-prefer-unrecognized" id="h-ldpp-prefer-unrecognized" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.5 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em> 
+		ignore a <a href="#ldpp-hints">page size hints</a> whose value is zero, 
+		and process the request as if no maximum desired size was specified; in the latter case the server
+		can select whatever page size it deems appropriate, or choose not to page the resource at all.
+	</span></h4></section>
+			
+	<section property="bibo:hasPart" resource="#ldpr-status-code" typeof="bibo:Chapter" id="ldpr-status-code"><h4 resource="#h-ldpr-status-code" id="h-ldpr-status-code" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.6 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD NOT" class="rfc2119">SHOULD NOT</em>
+			initiate paging unless the client has indicated it understands LDP Paging.
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> initiating paging <em title="SHOULD" class="rfc2119">SHOULD</em> respond
+			to successful <code>GET</code> requests with any <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource</a> 
+			as the <code>Request-URI</code> in one of the following ways:</span></h4>
+			<ul>
+			<li>
+				If the client supports paging, respond with 
+				status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
+				the first <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>.
+				The only standard means defined by LDP paging for a client to signal a server that the client
+				understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
+				other implementation-specific means could also be used.
+			</li>
+			<li>
+				If the server is willing to provide a non-paged representation, respond
+				with an appropriate status code (likely <code>200 OK</code>) and the potentially large
+				non-paged representation.
+			</li>
+			<li>
+				Either reject the request, most likely with a <code>4xx</code> status code,
+				or (keeping in mind the note below)
+				initiate paging as described above with a <code>303</code> status code, or
+				choose another status code appropriate to the specific situation.
+			</li>
+			</ul>
+			
+			<blockquote>
+				<em>Non-normative note:</em>
+				<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> could choose to make any resource
+				available <em>only</em> as a paged resource.  
+				In so doing, when interacting with clients <em>unaware</em> of LDP Paging, 
+				if the server initiates paging anyway then it runs the risk
+				that an ill-behaved client will automatically follow a 
+				<code>303 See Other</code> redirect and believe via the subsequent
+				<code>200 OK</code> that it has obtained a complete representation of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+				rather than of a single <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>.
+				<a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a> <a href="#ldpp-client-nofollow-303">will not follow redirects in this way</a>,
+				but some existing HTTP clients are known to treat <code>303 See Other</code> redirects as if they were 
+				equivalent to the original request-URI, despite this being explicitly disclaimed in [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>].
+			</blockquote>
+	</section>
+
+	<section property="bibo:hasPart" resource="#ldpr-guarantee-show-unchanged" typeof="bibo:Chapter" id="ldpr-guarantee-show-unchanged"><h4 resource="#h-ldpr-guarantee-show-unchanged" id="h-ldpr-guarantee-show-unchanged" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.7 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em> 
+		ensure that all state present in the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> throughout a client's <em>entire</em> traversal operation
+		is represented in at least one <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>.  In other words, whatever subset of the 
+		<a class="internalDFN" href="#dfn-paged-resource">paged resource</a> that is <em>not added, updated, or removed during the client's traversal</em>
+		of its pages has to be present in one of the pages.
+		</span></h4>
+		<blockquote><em>Non-normative note:</em> 
+		As a consequence, if the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> does not change <em>at all</em> during the traversal, 
+		then the client has a complete view of its state as given by the negotiated response media type
+		<em>at the point in time when the final page was retrieved</em>.  
+		If the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> <em>does</em> change during the traversal, then only the portions that
+		were actually updated will differ; the client has no LDP Paging provided means for knowing in what
+		way(s) its view differs from that of the server in this case.  
+		</blockquote>
+		<blockquote><em>Non-normative note:</em> 
+		When the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> is an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>, 
+		the expectation is that all triples untouched by changes to the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+ have been
+		given to the client during the traversal; it is possible that some 
+subset of the changed triples, including all or none of them,
+		have been provided to the client, but the client has no way to know 
+which.
+		</blockquote>
+	</section>
+
+	<!-- 
+	<div class="ldp-issue-pending" id="question-link-relation"><p class="ldp-issue-title">Feedback requested on the link relation type used below</p>
+		<p>Background: likely suspects from the <a href="http://www.iana.org/assignments/link-relations/link-relations.xml">IANA link relation registry</a> that the editors examined:</p>
+		<ul>
+		<li><p>
+		<a href="http://tools.ietf.org/html/rfc6596">canonical</a> (see section 3, source has no TOC/anchors) may be
+		close enough; the content at the context URI can explicitly be a subset of that at the target (canoncial) URI.
+		Certain cited functions like link consolidation are completely appropriate; if we believe the authors about its
+		usage by crawlers/indexers however, we may be working at cross purposes.
+		</p></li>
+		<li><p>
+		<a href="http://tools.ietf.org/html/rfc6573">collection</a> has muddy semantics in the case where
+		the paged resource is an LDPC (i.e. the case we care most about, in terms of LDP's use cases).  We could 
+		probably get away with using collection, but its "inverse" item (defined in the same RFC) would definitely 
+		have a <em>different</em> semantic than what we want for paging (the RFC thinks an item is a member of the
+		collection, but a page of an LDPC might have multiple LDP members on it, if we consider inlining in any form).
+		It would have the net effect of looking at the LDPC as a generic RDF source, and "forgetting" within the paging
+		spec that LDPCs have members - something that I'm sure we could all do, but pity the adopters using both
+		together and trying to keep the different collection/item "models" untangled.
+		</p></li>
+		<li><p>
+		<a href="http://tools.ietf.org/html/rfc4287#page-21">enclosure</a> has "good match" semantics,
+		but a name that's awkward for our case.
+		</p></li>
+		<li><p>
+		<a href="http://tools.ietf.org/html/rfc5005">Atom Feed Paging and Archiving</a> has no analog for the logical feed.
+		</p></li>
+		<li><p>
+		We also have the choice of defining-new, either an extension link relation (we just mint our own URI, done)
+		or as a short name (requiring a small-but-not-zero registration template).
+		</p></li>
+		</ul>
+	</div>
+	-->
+		
+	<section property="bibo:hasPart" resource="#ldpr-notify-changes" typeof="bibo:Chapter" id="ldpr-notify-changes"><h4 resource="#h-ldpr-notify-changes" id="h-ldpr-notify-changes" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.8 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em> 
+		enable a client to detect any change to the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> that occurs while the client is retrieving pages
+		by 
+		including a HTTP <code>Link</code> header on all successful
+		HTTP <code>GET</code> responses, and <em title="SHOULD" class="rfc2119">SHOULD</em> include the same header on all <code>4xx</code>
+		status code responses.
+		The link's
+		context URI identifies the <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> being retrieved, 
+		target URI identifies the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>,
+		link relation type is <code>canonical</code> [<cite><a href="#bib-REL-CANONICAL" class="bibref">REL-CANONICAL</a></cite>],
+		and 
+		link extension parameters include the parameter name <code>etag</code>
+		and a corresponding parameter value identical to the ETag [<cite><a href="#bib-RFC7232" class="bibref">RFC7232</a></cite>]
+		of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>.
+		For example: <code>Link: &lt;http://example.org/customer-relations&gt;; rel="canonical"; etag="customer-relations-v1"</code>
+		</span></h4>
+		<blockquote><em>Non-normative note:</em> 
+		If the <code>rel="canonical"; etag="..."</code> value changes as the client retrieves pages, 
+		for example the value accompanying the first page's representation is <code>rel="canonical"; etag="v1"</code> 
+		and the value accompanying the second page's representation is <code>rel="canonical"; etag="v2"</code>,
+		the client can detect that the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s state has changed.
+		Some clients will ignore such changes, but others may choose to react to them, for example by restarting the traversal.
+		</blockquote>
+	</section>
+
+	<section property="bibo:hasPart" resource="#ldpr-pagingGET-sequences-change" typeof="bibo:Chapter" id="ldpr-pagingGET-sequences-change"><h4 resource="#h-ldpr-pagingget-sequences-change" id="h-ldpr-pagingget-sequences-change" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.9 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em>
+		add or remove <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resources</a> to a 
+		<a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource's</a> sequence over time.
+		If the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a> is <a href="#ldpc-HTTP_GET">ordered</a>, then the ordering communicated by the server <em title="MUST" class="rfc2119">MUST</em> be maintained;
+		the server <em title="SHOULD" class="rfc2119">SHOULD</em> only add pages to the end of an unordered sequence.
+		</span></h4><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
+		<blockquote><em>Non-normative note:</em> 
+		Servers might abandon an ordered <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>, resulting in <code>4xx</code> status codes to subsequent requests,
+		although it will be less disruptive to clients if the server either adds content to the appropriate existing page or
+		adds new pages at the proper point in the sequence.  Clients have no more efficient means than a conditional retrieval
+		request on existing pages to detect the changed/added pages.
+		</blockquote>
+		<blockquote><em>Non-normative note:</em> 
+		As a result, clients retrieving any <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> several times can observe its place in the sequence
+		change as the state of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> changes.
+		For example, a nominally last page's server might provide a 
+		<a class="internalDFN" href="#dfn-next-page-link">next page link</a> when the page is retrieved again later.  
+		Similar situations arise when the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a> crosses server boundaries; 
+		server A might host the initial portion of a sequence that links to the last page server A is aware of,  
+		hosted on server B, and server B might extend the sequence of pages.
+		A nominally middle page <var>M</var> can become the last (or a non-existent) page if a competing request deletes
+		part of the <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource's</a> content after the client retrieves <var>M</var>.
+		</blockquote>
+	</section>
+
+		<section property="bibo:hasPart" resource="#ldpr-pagingGET-first-allowed-onpages" typeof="bibo:Chapter" id="ldpr-pagingGET-first-allowed-onpages"><h4 resource="#h-ldpr-pagingget-first-allowed-onpages" id="h-ldpr-pagingget-first-allowed-onpages" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.10 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em> provide 
+			a <a class="internalDFN" href="#dfn-first-page-link">first page link</a> when responding to 
+			requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resource</a> as the <code>Request-URI</code>.
+		</span></h4></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
+	
+		<section property="bibo:hasPart" resource="#ldpr-pagingGET-last-allowed-onpages" typeof="bibo:Chapter" id="ldpr-pagingGET-last-allowed-onpages"><h4 resource="#h-ldpr-pagingget-last-allowed-onpages" id="h-ldpr-pagingget-last-allowed-onpages" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.11 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em>
+			provide a <a class="internalDFN" href="#dfn-last-page-link">last page link</a>
+			in responses to <code>GET</code> requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resource</a> as the <code>Request-URI</code>.
+		</span></h4></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
+	
+	<section property="bibo:hasPart" resource="#ldpr-pagingGET-next-reqd" typeof="bibo:Chapter" id="ldpr-pagingGET-next-reqd"><h4 resource="#h-ldpr-pagingget-next-reqd" id="h-ldpr-pagingget-next-reqd" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.12 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em>
+		provide a <a class="internalDFN" href="#dfn-next-page-link">next page link</a>
+		in responses to <code>GET</code> requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence 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. 
+	</span></h4><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
+	</section>
+	
+		<section property="bibo:hasPart" resource="#ldpr-pagingGET-lastnext-prohibited" typeof="bibo:Chapter" id="ldpr-pagingGET-lastnext-prohibited"><h4 resource="#h-ldpr-pagingget-lastnext-prohibited" id="h-ldpr-pagingget-lastnext-prohibited" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.13 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST NOT" class="rfc2119">MUST NOT</em>
+			provide a <a class="internalDFN" href="#dfn-next-page-link">next page link</a>
+			in responses to <code>GET</code> requests with the final <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resource</a> 
+			as the <code>Request-URI</code>.
+			This is the mechanism by which clients can discover the end of the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>
+			as currently known by the server.  
+		</span></h4></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
+		
+		<section property="bibo:hasPart" resource="#ldpr-pagingGET-prev-allowed" typeof="bibo:Chapter" id="ldpr-pagingGET-prev-allowed"><h4 resource="#h-ldpr-pagingget-prev-allowed" id="h-ldpr-pagingget-prev-allowed" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.14 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em>
+			provide a <a class="internalDFN" href="#dfn-previous-page-link">previous page link</a>
+			in responses to <code>GET</code> requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resource</a>
+			<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.  
+		</span></h4></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
+		
+		<section property="bibo:hasPart" resource="#ldpr-pagingGET-firstprev-prohibited" typeof="bibo:Chapter" id="ldpr-pagingGET-firstprev-prohibited"><h4 resource="#h-ldpr-pagingget-firstprev-prohibited" id="h-ldpr-pagingget-firstprev-prohibited" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.15 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST NOT" class="rfc2119">MUST NOT</em>
+			provide a <a class="internalDFN" href="#dfn-previous-page-link">previous page link</a>
+			in responses to <code>GET</code> requests with the <em>first</em> <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resource</a> 
+			as the <code>Request-URI</code>.
+			This is one mechanism by which clients can discover the beginning of the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>
+			as currently known by the server.  
+		</span></h4></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
+
+		<section property="bibo:hasPart" resource="#ldpr-pagingGET-page-type-reqd" typeof="bibo:Chapter" id="ldpr-pagingGET-page-type-reqd"><h4 resource="#h-ldpr-pagingget-page-type-reqd" id="h-ldpr-pagingget-page-type-reqd" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.16 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em>
+			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> [<cite><a href="#bib-RFC5988" class="bibref">RFC5988</a></cite>]
+			in responses to <code>GET</code> requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence 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.  
+		</span></h4></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
+
+		<section property="bibo:hasPart" resource="#ldpr-pagingGET-abandon-pageseq" typeof="bibo:Chapter" id="ldpr-pagingGET-abandon-pageseq"><h4 resource="#h-ldpr-pagingget-abandon-pageseq" id="h-ldpr-pagingget-abandon-pageseq" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.17 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">SHOULD</em>
+			indicate that they have abandoned a
+			sequence by responding with at <code>410 Gone</code> to HTTP requests to any of the 
+			<a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resources</a> with appropriate 
+			paging link response headers, for example, rel="first".
+		</span></h4></section><!-- #ldpr-pagingGET-abandon-pageseq -->
+
+		<section property="bibo:hasPart" resource="#ldpr-units-triple-count" typeof="bibo:Chapter" id="ldpr-units-triple-count"><h4 resource="#h-ldpr-units-triple-count" id="h-ldpr-units-triple-count" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.18 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">SHOULD</em>
+			support the <code>max-triple-count</code> <a href="#ldpp-hints">client preference parameter</a>,
+			which expresses a page size limiting the number of RDF triples represented on a page.
+			For example, <code>max-triple-count="500"</code> expresses a limit of 500 RDF triples per page.
+		</span></h4>
+		</section> 
+
+		<section property="bibo:hasPart" resource="#ldpr-units-kbyte-count" typeof="bibo:Chapter" id="ldpr-units-kbyte-count"><h4 resource="#h-ldpr-units-kbyte-count" id="h-ldpr-units-kbyte-count" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.19 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">SHOULD</em>
+			support the <code>max-kbyte-count</code> <a href="#ldpp-hints">client preference parameter</a>,
+			which expresses a page size limit as kilobytes of representation size.
+			For example, <code>max-kbyte-count="1"</code> expresses a limit of 1024 bytes per page.
+		</span></h4>
+		</section> 
+	
+		<section property="bibo:hasPart" resource="#ldpr-pagesize-multiple-units" typeof="bibo:Chapter" id="ldpr-pagesize-multiple-units"><h4 resource="#h-ldpr-pagesize-multiple-units" id="h-ldpr-pagesize-multiple-units" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.20 </span>
+			<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em>, if provided with multiple 
+			 <a href="#ldpp-hints">client preference parameters</a> limiting page size,
+			honor all hints that it recognizes.  This has the net effect that the most restrictive
+			hint for any given response governs the resulting page size.
+			For example, <code>max-kbyte-count="1"</code> and <code>max-triple-count="500"</code>
+			usually would result in pages whose size hits the 1 kilobyte limit first, since each triple very likely
+			requires more than two bytes (500 triples/1024 bytes).
+		</span></h4>
+		</section> 
+	
+		<!-- combined into ldpr-status-code
+		<section id="ldpr-pagingGET-only-paging-clients"><h2 class="normal">
+			<a title="LDP Paging server">LDP Paging servers</a> SHOULD NOT
+			initiate paging unless the client has indicated it understands LDP Paging or that it is prepared to 
+			process <code>2NN Contents of Related</code> responses [[!2NN]].
+			If the client supports paging but not <code>2NN</code> responses, a server initiating paging SHOULD respond with 
+			status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
+			the URI of the first <a>in-sequence page resource</a> of the <a>paged resource</a>.
+			The only standard means defined by LDP paging for a client to signal a server that the client
+			understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
+			other implementation-specific means could also be used.</h2>
+			<blockquote>
+				<em>Non-normative note:</em>
+				<a title="LDP Paging server">LDP Paging servers</a> could choose to make any resource
+				available <em>only</em> as a paged resource.  
+				In so doing, when interacting with clients <em>unaware</em> of LDP Paging, 
+				if the server initiates paging anyway then it runs the risk
+				that an ill-behaved client will automatically follow a 
+				<code>303 See Other</code> redirect and believe via the subsequent
+				<code>200 OK</code> that it has obtained a complete representation of the <a>paged resource</a>
+				rather than of what may be a single <a>in-sequence page resource</a>.
+				The alternative is for the server to reject the request, most likely
+				with a <code>4xx</code> status code.
+				<a title="LDP Paging client">LDP Paging clients</a> <a href="#ldpp-client-nofollow-303">will not follow redirects in this way</a>,
+				but some existing HTTP clients are known to treat <code>303 See Other</code> redirects as if they were 
+				equivalent to the original request-URI, despite this being explicitly disclaimed in [[RFC7231]].
+			</blockquote>
+		</section>
+		-->
+
+</section>
+
+</section> <!-- h1 -->
+
+<section property="bibo:hasPart" resource="#ldpc" typeof="bibo:Chapter" id="ldpc">
+<!--OddPage--><h2 resource="#h-ldpc" id="h-ldpc"><span property="xhv:role" resource="xhv:heading"><span class="secno">7. </span>Linked Data Platform Containers</span></h2>
+
+<section property="bibo:hasPart" resource="#ldpc-general" typeof="bibo:Chapter" id="ldpc-general">
+<h3 resource="#h-ldpc-general" id="h-ldpc-general"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.1 </span>Requirements when paging LDP Containers</span></h3>
+
+	<section property="bibo:hasPart" resource="#ldpc-onsamepage" typeof="bibo:Chapter" id="ldpc-onsamepage"><h4 resource="#h-ldpc-onsamepage" id="h-ldpc-onsamepage" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.1.1 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em>
+		ensure that the <a class="internalDFN" href="#dfn-membership-triples" title="membership triples">membership triple</a> and 
+		<a class="internalDFN" href="#dfn-containment-triples" title="containment triples">containment triple</a> for each member are part of the
+		same <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>, whenever both triples are present in the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>
+		for a <a class="internalDFN" href="#dfn-paged-resource" title="paged resource">paged <abbr title="Linked Data Platform Container">LDPC</abbr></a>.
+	</span></h4></section>
+	
+	<section property="bibo:hasPart" resource="#ldpr-units-record-count" typeof="bibo:Chapter" id="ldpr-units-record-count"><h4 resource="#h-ldpr-units-record-count" id="h-ldpr-units-record-count" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.1.2 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">SHOULD</em>
+		support the <code>max-member-count</code> <a href="#ldpp-hints">client preference parameter</a>,
+		which expresses a page size limiting the number of members returned on each page of a <a class="internalDFN" href="#dfn-paged-resource" title="paged resource">paged <abbr title="Linked Data Platform Container">LDPC</abbr></a>.
+		For example, <code>max-member-count="10"</code> expresses a limit of 10 members per page.
+	</span></h4>
+	</section> 
+	
+</section>
+
+<section property="bibo:hasPart" resource="#ldpc-informative" typeof="bibo:Chapter" class="informative" id="ldpc-informative">		
+<h3 resource="#h-ldpc-informative" id="h-ldpc-informative"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.2 </span>Ordering of container members across pages</span></h3><p><em>This section is non-normative.</em></p>
+
+	<section property="bibo:hasPart" resource="#ldpc-ordering" typeof="bibo:Chapter" id="ldpc-ordering"><h4 resource="#h-ldpc-ordering" id="h-ldpc-ordering" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.2.1 </span>Ordering</span></h4>
+	<p>
+		There are many cases where an ordering of the members of a
+		container is important. [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] does not provide any particular support
+		for server ordering of members in containers, because any client can
+		order the members in any way it chooses based on the value of any
+		available property of the members. In the example below, the value of
+		the <code>o:marketValue</code> predicate is present for each
+		member, so the client can easily order the members according to the
+		value of that property.  Applications that require a way for clients to
+		specify the order, can do so with application-specific extensions. 
+	</p>
+	<p>
+		Order becomes more important when containers are
+		paginated. If the server respects ordering when constructing
+		pages, clients needing a globally sorted set of members
+		can reduce the effort required to merge pages.
+		In cases where ordering is important, an <a class="internalDFN" href="#dfn-ldp-paging-server">LDP Paging server</a> ensures that all the
+		members on any single page have the proper sort order with relation to all 
+		members on any next and previous pages.
+		<em>This says nothing about the ordering of members <strong>within</strong> any 
+		<a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">single page</a>.</em>
+		When the sort is ascending, all the members on a current page have a 
+		sort order no lower than all members on the previous page and 
+		sort order no higher than all the members on the next page; 
+		that is, it proceeds from low to high, but keep in mind that several 
+		consecutive pages might have members whose sort criteria are equal. 
+		When the sort is descending, the opposite order is used. 
+		Since more than one value may be used to sort members, 
+		the <abbr title="Linked Data Platform Container">LDPC</abbr> specification allows servers to assert the ordered list
+		of sort criteria used to sort the members, using the 
+		<code>ldp:pageSequence</code> HTTP link relation and its
+		<code>ldp:pageSortCriteria</code> predicate.
+		Each member of the ordered list exposes one <code>ldp:pageSortCriterion</code>, 
+		consisting of a <code>ldp:pageSortOrder</code>, 
+		<code>ldp:pageSortPredicate</code>, and 
+		optionally a <code>ldp:pageSortCollation</code>.
+	</p>
+	<p>
+		Here is an example asset container described in [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] section 5.1:
+	</p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example">GET /netWorth/nw1/assetContainer/ HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"</pre></div>
+	<p>
+		The server might respond with status code <code>200 OK</code>, 
+		and the following representation:
+	</p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example" id="ldpc-ex-ordering-nopaging">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "_87e52ff291112"
+Link: &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
+Link: &lt;http://www.w3.org/ns/ldp#DirectContainer&gt;; rel="type"
+Allow: GET,OPTIONS,HEAD
+
+# The following is the ordered representation of
+#   http://example.org/netWorth/nw1/assetContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base &lt;http://example.org/netWorth/nw1/assetContainer/&gt; .
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&lt;&gt;
+   a ldp:DirectContainer;
+   dcterms:title "The assets of JohnZSmith";
+   ldp:membershipResource &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:hasMemberRelation o:asset;
+   ldp:insertedContentRelation ldp:MemberSubject;
+   ldp:contains &lt;a1&gt;, &lt;a2&gt;, &lt;a3&gt;.
+
+&lt;http://example.org/netWorth/nw1&gt;
+   a o:NetWorth;
+   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
+
+&lt;a1&gt;
+   a o:Stock;
+   o:marketValue 100.00 .
+&lt;a2&gt;
+   a o:Cash;
+   o:marketValue 505.00 .
+&lt;a3&gt;
+   a o:RealEstateHolding;
+   o:marketValue 100.00 .</pre></div>
+	<p>
+		The client knows that LDP Paging was not used to form the response, because the HTTP status code is <code>200 OK</code>;
+		the absence of a <code>Link: &lt;http://www.w3.org/ns/ldp#Page&gt;; rel="type"</code> response header provides redundant
+		confirmation of this.
+		Since paging was not used, the server provides no information related to page sorting;
+		providing page sorting information would have no value to the client, it would only waste resources.
+	</p>
+
+	<p>
+		Had the server responded instead with a redirect to a first page <code>http://example.org/netWorth/nw1/assetContainer/?p=1</code>,
+		whose representation was (after following the redirect):
+	</p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example" id="ldpc-ex-ordering-page1">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "_87e52ff291112"
+Link: &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type",
+      &lt;http://www.w3.org/ns/ldp#Page&gt;; rel="type"
+Link: &lt;http://example.org/netWorth/nw1/assetContainer/?p=2&gt;; rel="next"
+Link: &lt;http://example.org/netWorth/nw1/assetContainer/&gt;; rel="canonical"; etag="v1"
+Link: &lt;http://example.org/netWorth/nw1/assetContainer/sortedSequence/&gt;; rel="http://www.w3.org/ns/ldp#pageSequence"
+Allow: GET,OPTIONS,HEAD
+
+# The following is the ordered representation of
+#   http://example.org/netWorth/nw1/assetContainer/ page 1 of 2
+<!-- @base is required here because the page URI != container URI; any use for paste into validators for checking is free bonus -->
[email protected] &lt;http://example.org/netWorth/nw1/assetContainer/&gt; .
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&lt;&gt;
+   a ldp:DirectContainer;
+   dcterms:title "The assets of JohnZSmith";
+   ldp:membershipResource &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:hasMemberRelation o:asset;
+   ldp:insertedContentRelation ldp:MemberSubject;
+   ldp:contains &lt;a1&gt;, &lt;a2&gt;, &lt;a3&gt;.
+
+&lt;http://example.org/netWorth/nw1&gt;
+   a o:NetWorth;
+   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
+
+&lt;a1&gt;
+   a o:Stock;
+   o:marketValue 100.00 .
+   
+# The remainder of the content describes the sort order.
+# Note that the new base URI here matches the target URI of the pageSequence Link header above.
+
[email protected] &lt;http://example.org/netWorth/nw1/assetContainer/sortedSequence/&gt; .
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
+<!-- (#Sort-o.marketValue-Ascending) does not work, because the subject uri would be a blank node -->
+&lt;&gt; ldp:pageSortCriteria  ( &lt;#Sort-o.marketValue-Ascending&gt; ).
+
+&lt;#Sort-o.marketValue-Ascending&gt;
+   a ldp:pageSortCriterion;
+   ldp:pageSortOrder ldp:Ascending;
+   ldp:pageSortPredicate o:marketValue.</pre></div>
+	
+	<p>
+		In this case the server does provide information on the assignment of members to pages.
+	</p>
+	<ul>
+	<li>
+		A <code>Link: rel="http://www.w3.org/ns/ldp#pageSequence"</code> response header has been
+		added, allowing the client to where to find information about the page sequence;
+		its content includes a <code>ldp:pageSortCriteria</code> triple, 
+		allowing the client to know what sort criteria the server used when allocating members
+		to pages.
+	</li>
+	<li>
+		The server also chose to include assertions about the sort criteria in the content for the
+		first page, namely the triples occurring after the second <code>@base</code> directive.
+		This is an optional exemplary optimization, and the client must decide for itself using means outside of
+		LDP and HTTP whether or not to trust those assertions.
+		If the client trusts those assertions, it need not retrieve them; retrieving them would in this case
+		result in another <code>HTTP GET</code> request.  For the purposes of this example, assume that
+		the assertions match what the client would obtain by retrieving them itself.
+	</li>
+	<li>
+		The contents of the sort criteria resource
+		asserts that the <code>o:marketValue</code> predicate will be used 
+		to assign sets of members to pages in ascending order.  
+		The server is telling the client that the values of <code>o:marketValue</code> of all assets
+		on the first page are no lower than the values on subsequent pages.
+		Since only one such value happens to fall on the first page, this is trivially satisfied.
+	</li>
+	</ul>
+	
+	<p>
+		When the client retrieves the second page by following the <code>rel="next"</code> link,
+		its representation might be:
+	</p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 15</span></div><pre class="example" id="ldpc-ex-ordering-page2">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "_87e52ff291112"
+Link: &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type",
+      &lt;http://www.w3.org/ns/ldp#Page&gt;; rel="type"
+Link: &lt;http://example.org/netWorth/nw1/assetContainer/?pageSortOrder&gt;; rel="prev"
+Link: &lt;http://example.org/netWorth/nw1/assetContainer/&gt;; rel="canonical"; etag="v1"
+Link: &lt;http://example.org/netWorth/nw1/assetContainer/sortedSequence/&gt;; rel="http://www.w3.org/ns/ldp#pageSequence"
+Allow: GET,OPTIONS,HEAD
+
+# The following is the ordered representation of
+#   http://example.org/netWorth/nw1/assetContainer/ page 2 of 2
+<!-- @base is required here because the page URI != container URI; any use for paste into validators for checking is free bonus -->
[email protected] &lt;http://example.org/netWorth/nw1/assetContainer/&gt; .
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&lt;a2&gt;
+   a o:Cash;
+   o:marketValue 505.00 .
+&lt;a3&gt;
+   a o:RealEstateHolding;
+   o:marketValue 100.00 .</pre></div>
+	
+	<ul>
+	<li>
+		The same <code>Link: rel="http://www.w3.org/ns/ldp#pageSequence"</code> response header is present,
+		allowing the client to know what page sequence, and hence what sort criteria, the server used.
+	</li>
+	<li>
+		The server chose not to include assertions about the sort criteria in the content for the
+		second page.  Since LDP Paging <a href="#ldpc-sort-consistent">requires that the page sequence is sorted consistently</a>,
+		any client that already retrieved the first page has already seen the sorting criteria.  If a client is given
+		the URI of an <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> through means other than following links, it always has the option 
+		to retrieve the sort criteria.
+	</li>
+	<li>
+		As the example shows, the values of <code>o:marketValue</code> all assets
+		on the second page are greater than or equal to the values on earlier pages.
+		<em>The values within this page are not ordered according to the 
+		sort criterion</em>, illustrating that this criterion applies only to the 
+		sorting of "assigning members to pages", not
+		to the ordering within any single page's representation.
+		Typically those representations have not guarantee of ordering and are generated by libraries,
+		whose serializers do not provide a way to control how the order is conveyed.
+	</li>
+	</ul>
+	<p>
+		It is up to the domain model
+		and server to determine the appropriate predicate to indicate the
+		resource’s order within a page (or globally), and up to the client receiving this 
+		representation to use that order in whatever way is appropriate to meet its needs, for 
+		example to sort the data prior to presentation on a user interface. Also,
+		as it is possible for a container to have as its members other containers,
+		the ordering approach doesn't change as containers themselves are <abbr title="Linked Data Platform Resources">LDPRs</abbr> and the
+		properties from the domain model can be leveraged for the sort criteria.
+	</p>
+	</section><!-- Was 5.1.2 / #ldpc-ordering -->
+</section> <!-- containers . intro -->
+
+<section property="bibo:hasPart" resource="#ldpc-HTTP_GET" typeof="bibo:Chapter" id="ldpc-HTTP_GET">	
+<h3 resource="#h-ldpc-http_get" id="h-ldpc-http_get"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3 </span>HTTP GET requirements for member ordering across pages</span></h3>
+
+	<p>
+		If a <a class="internalDFN" href="#dfn-ldp-paging-server">LDP Paging server</a> chooses to use LDP Paging-defined mechanisms to 
+		tell clients the order it uses to assign <abbr title="Linked Data Platform Container">LDPC</abbr> members to pages, 
+		which is optional, then it does so as described in this section.
+		LDP Paging does not specify ordering for <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">pages</a> in other cases.
+		See <a href="#ldpc-ordering" class="sectionRef sec-ref">section <span class="secno">7.2.1</span> <span class="sec-title">Ordering</span></a> for
+		exemplary message exchanges.
+	</p>
+	
+	<section property="bibo:hasPart" resource="#ldpc-sort-criteria-consistent" typeof="bibo:Chapter" id="ldpc-sort-criteria-consistent"><h4 resource="#h-ldpc-sort-criteria-consistent" id="h-ldpc-sort-criteria-consistent" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.1 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em> 
+		communicate the order used to allocate <abbr title="Linked Data Platform Container">LDPC</abbr> members to <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">pages</a>.
+		If they choose to communicate the order, they <em title="MUST" class="rfc2119">MUST</em> respond 
+		consistently to retrieval requests for each <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">page</a> in the same sequence.
+		That is, they must communicate the same criteria (or absence of it) for all pages in the same sequence; if
+		the criteria were allowed to vary, the ordering among members of a container
+		across <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">pages</a> would be undefined.
+	</span></h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+	
+	<blockquote>
+		<em>Non-normative note:</em> A server can offer different sequences for the same <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>,
+		for example, sequences that have differing sort criteria, and they can be offered serially or concurrently.
+	</blockquote>
+	
+	<section property="bibo:hasPart" resource="#ldpc-sort-criteria-link" typeof="bibo:Chapter" id="ldpc-sort-criteria-link"><h4 resource="#h-ldpc-sort-criteria-link" id="h-ldpc-sort-criteria-link" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.2 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MUST" class="rfc2119">MUST</em> 
+		specify the order using a <code>HTTP Link</code> header
+		whose context URI is the page URI, 
+		whose link relation is <code>http://www.w3.org/ns/ldp#pageSequence</code>, 
+		and whose target IRI identifies a <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> whose content includes the 
+		sort criteria.
+		The resource identified by the <code>Link</code> header's target IRI <em title="MUST" class="rfc2119">MUST</em> contain a triple
+		whose subject is the <code>Link</code> header's target IRI, 
+		whose predicate is <code>ldp:pageSortCriteria</code> 
+		and whose object is a
+		page sort criteria resource compliant with this section's requirements on its content.
+	</span></h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+	
+	<section property="bibo:hasPart" resource="#ldpc-sort-criteria-content" typeof="bibo:Chapter" id="ldpc-sort-criteria-content"><h4 resource="#h-ldpc-sort-criteria-content" id="h-ldpc-sort-criteria-content" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.3 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MUST" class="rfc2119">MUST</em> 
+		expose page sort criteria resources that describe the allocation of members to pages; each resource consists of a <code>rdf:List</code> of
+		<code>ldp:pageSortCriterion</code> resources.  
+		The first list entry provides the primary
+		sorting criterion, any second entry provides a secondary criterion used to order members considered
+		equal according to the primary criterion, and so on.
+		The resulting page sort order <em title="MUST" class="rfc2119">MUST</em> be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause 
+		[<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>].
+	</span></h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+	
+	<section property="bibo:hasPart" resource="#ldpc-sortliteraltype" typeof="bibo:Chapter" id="ldpc-sortliteraltype"><h4 resource="#h-ldpc-sortliteraltype" id="h-ldpc-sortliteraltype" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.4 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MUST" class="rfc2119">MUST</em> 
+		expose page sort criteria resources that contain, 
+		in every <code>ldp:pageSortCriterion</code> list entry, 
+		a triple
+		whose subject is the sort criterion identifier, 
+		whose predicate is <code>ldp:pageSortPredicate</code> 
+		and whose object is 
+		the predicate whose value is used to order members between pages (the <dfn id="dfn-page-ordering-values">page-ordering values</dfn>).
+		The only literal data types whose behavior LDP constrains are those defined
+		by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>].  Other data types
+		can be used, but LDP
+		assigns no meaning to them and interoperability will be limited.
+	</span></h4></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
+	
+	<section property="bibo:hasPart" resource="#ldpc-sortorder" typeof="bibo:Chapter" id="ldpc-sortorder"><h4 resource="#h-ldpc-sortorder" id="h-ldpc-sortorder" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.5 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MUST" class="rfc2119">MUST</em> 
+		expose page sort criteria resources that contain, 
+		in every <code>ldp:pageSortCriterion</code> list entry, 
+		a triple
+		whose subject is the sort criterion identifier, 
+		whose predicate is <code>ldp:pageSortOrder</code> 
+		and whose object describes the order used.</span></h4>
+		<blockquote>
+		<p>
+		LDP defines two values,
+		<code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
+		as the object of this triple.  Other values can be used, but LDP
+		assigns no meaning to them and interoperability will be limited.
+		</p>
+		</blockquote>
+	</section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
+	
+	<section property="bibo:hasPart" resource="#ldpc-sortcollation" typeof="bibo:Chapter" id="ldpc-sortcollation"><h4 resource="#h-ldpc-sortcollation" id="h-ldpc-sortcollation" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.6 </span>
+		<a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MAY" class="rfc2119">MAY</em> 
+		expose page sort criteria resources that contain, 
+		in any <code>ldp:pageSortCriterion</code> list entry,
+		a triple
+		whose subject is the sort criterion identifier, 
+		whose predicate is <code>ldp:pageSortCollation</code> 
+		and whose object identifies the collation used.
+		The <code>ldp:pageSortCollation</code> triple <em title="MUST" class="rfc2119">MUST</em> be omitted for comparisons
+		involving <a class="internalDFN" href="#dfn-page-ordering-values" title="page-ordering values">page-ordering values</a> for which [<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>] does not use collations.</span></h4>
+		<blockquote>
+		<p>
+		LDP defines no values for use
+		as the object of this triple.  While it is better for interoperability to use
+		open standardized values, any value can be used.
+		</p>
+		<p>
+		When the <code>ldp:pageSortCollation</code> triple is absent and the 
+		<a class="internalDFN" href="#dfn-page-ordering-values" title="page-ordering values">page-ordering values</a> are strings or simple literals [<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>], the
+		resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause 
+		[<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>] using two-argument <code>fn:compare</code>, that is, 
+		it behaves as if <code>http://www.w3.org/2005/xpath-functions/collation/codepoint</code> 
+		was the specified collation.
+		</p>
+		<p>
+		When the <code>ldp:pageSortCollation</code> triple is present and the 
+		<a class="internalDFN" href="#dfn-page-ordering-values" title="page-ordering values">page-ordering values</a> are strings or simple literals 
+		[<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>], the
+		resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause 
+		[<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>] using three-argument <code>fn:compare</code>, that is, the 
+		specified collation.
+		</p>
+		</blockquote>
+	</section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
+
+</section> <!-- h2 -->
+
+</section> <!-- h1 LDPC -->
+
+<section property="bibo:hasPart" resource="#security" typeof="bibo:Chapter" class="informative" id="security">
+<!--OddPage--><h2 resource="#h-security" id="h-security"><span property="xhv:role" resource="xhv:heading"><span class="secno">8. </span>Security Considerations</span></h2><p><em>This section is non-normative.</em></p>
+As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many 
+security-related facilities associated with it and are not required to carry out LDP operations 
+that may be in contradistinction to a particular security policy in place. For example, when faced with an 
+unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may
+consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization 
+is required. In cases where authentication is provided fails to meet the requirements of a particular access control 
+policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the
+access control policy.
+</section>
+
+<section property="bibo:hasPart" resource="#ldpr-impl" typeof="bibo:Chapter" class="appendix informative" id="ldpr-impl">
+
+<!--OddPage--><h2 resource="#h-ldpr-impl" id="h-ldpr-impl"><span property="xhv:role" resource="xhv:heading"><span class="secno">A. </span>Paging <abbr title="Linked Data Platform Resources">LDPRs</abbr> without maintaining server-side session state</span></h2><p><em>This section is non-normative.</em></p>
+	<p>
+		Server implementers naturally have concerns when they are expected to maintain per-client state
+		because of the scalability limitations that per-client state implies.
+		LDP Paging carries no such requirement, although this may not be obvious at first glance.  
+		Since URLs are opaque to clients [<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>], a server
+		is free to encode the information required for it to know where to start the next page inside
+		its next page links, for example.
+	</p>
+	<p>
+		Observe that in the <a href="#ldpp-ex-mx" class="sectionRef">preceding examples</a>, 
+		the <var>page n</var> URIs are all of the form
+		<code>http://example.org/customer-relations?p=<var>n</var></code>, 
+		where <var>n</var> is <var>2..n</var>.  This is likely true in general practice.
+		If the server allocates <code>o:client</code> representations to pages randomly, it's not obvious how to avoid
+		keeping per-client state of one kind or another on the server while still sending all the representations on
+		at least one page.  In the common case where the list has an 
+		ordering (either a natural one or one imposed by the implementation) however, it is easy to avoid
+		keeping per-client state on the server.  
+	</p>
+	<p>
+		One trivial case is "fixed order"; if the server always sends
+		<code>o:client</code> representations in the order 
+		<code>#JohnZSmith, #BettyASmith, #JoanRSmith, #GlenWSmith, #AlfredESmith</code> (or indeed,
+		in <i>any</i> predictable order), then it can put the "last seen" identifier in the <a class="internalDFN" href="#dfn-next-page-link">next page link</a>
+		of each <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> as it is retrieved <em>by each client</em>.  The "session state"
+		is, in effect, kept by the client.
+		In this case, the <a class="internalDFN" href="#dfn-next-page-link">next page link</a> in the first page might be:
+	</p>
+	<div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example" id="paging-no-session-state1">Link: &lt;http://example.org/customer-relations?resumeafter=JoanRSmith&gt;; rel="next"</pre></div>
+	<p>
+		If the server also supports <a class="internalDFN" href="#dfn-backward-traversal">backward traversal</a>, then the second page's 
+		<a class="internalDFN" href="#dfn-previous-page-link">previous page link</a> might be:
+	</p>
+	<div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example" id="paging-no-session-state2">Link: &lt;http://example.org/customer-relations?resumebefore=GlenWSmith&gt;; rel="next"</pre></div>
+	<p>
+		Keep in mind that this is an exemplary server implementation decision; it is not prescribed by 
+		LDP Paging, and other choices are certainly possible.  As long as the URIs used in links 
+		are opaque to clients, any choice within the constraints of all normative references is permissible.
+	</p>
+</section>
+
+
+<section property="bibo:hasPart" resource="#acks" typeof="bibo:Chapter" class="appendix informative" id="acks">
+<!--OddPage--><h2 resource="#h-acks" id="h-acks"><span property="xhv:role" resource="xhv:heading"><span class="secno">B. </span>Acknowledgements</span></h2><p><em>This section is non-normative.</em></p>
+     
+  <p>The following people have been instrumental in providing thoughts, feedback,
+reviews, content, criticism and input in the creation of this specification:</p>
+
+  <p style="margin-left: 3em;">
+  Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou,  
+Arnaud Le Hors, Ashok Malhotra, Bart van Leeuwen, Cody Burleson, David 
+Wood, Eric Prud'hommeaux, Erik Wilde, Gregory McFall, Henry Story, John 
+Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel 
+Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, 
+Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, 
+Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena 
+Villata, Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, 
+Tim Berners-Lee, Yves Lafon
+  </p>
+
+</section>
+
+<section property="bibo:hasPart" resource="#history" typeof="bibo:Chapter" class="appendix informative" id="history">
+<!--OddPage--><h2 resource="#h-history" id="h-history"><span property="xhv:role" resource="xhv:heading"><span class="secno">C. </span>Change History</span></h2><p><em>This section is non-normative.</em></p>
+<!-- 
+<p>The change history is up to the editors to insert a brief summary of
+changes, ordered by most recent changes first and with heading from which
+public draft it has been changed from.
+</p>  -->
+
+<em>Summary</em>
+<ul>
+	<li>Sections previously marked "at risk" are no longer marked (the content remains in this document)
+		<a href="#ldpr-cli-paging">client should be prepared for pages</a>, hint units (<a href="#ldpr-units-kbyte-count">max-kbytes-count</a>
+		and 
+		<a href="#ldpr-units-record-count">max-member-count</a>) and <a href="#ldpr-pagesize-multiple-units">honor all size hints</a>.
+		</li>
+	<li>Removed "Feature at Risk" content for <code>2NN Contents of Related</code> status code and usage.</li>
+</ul>
+<!-- 
+<em>Summary</em>
+<ul>
+	<li>Split paging out from core LDP 1.0 specification into this document</li>
+	<li>Updated detection of paged resources based on link relations</li>
+	<li>Added rule to keep containment and membership triples for same resource on same page</li>
+	<li>Use of link header to location sort criteria</li>
+	<li>Added additional ways to request paging based kilobyte and membership count</li>
+</ul>
+ -->
+ 
+<!-- <p>The change history is up to the editors to insert a brief summary of
+changes, ordered by most recent changes first and with heading from which
+public draft it has been changed from.
+</p>  -->
+
+<!-- 
+<h2>Detailed history</h2> -->
+
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2014/CR-ldp-paging-20141216/">Candidate Recommendation Draft</a></em></blockquote> wah -->
+<!-- 
+<ul>
+	<li>2015-01-26 - Align usage of Link: rel= to not use single quotes per RFC5988 (SS)</li>
+</ul>
+-->
+
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
+<!-- 
+<ul>
+	<li>2014-11-05 - Removed "at risk" content for "2NN Contents of Related" status code and usage (SS) </li>
+	<li>2014-11-05 - Removed "at risk" markers for max-member-count and max-kbyte-count, honor all hints and clients should expect paging (SS) </li>
+	<li>2014-10-10 - Clarified "new protocol" in 4.2, hyper-linked max-member-count to LDPCs per 10/10 public comments email (JA) </li>
+	<li>2014-09-26 - Added non-norm items about extensions to supply client requested ordering (SS) </li>
+</ul>
+
+<blockquote><em><a href="http://www.w3.org/TR/2014/WD-ldp-paging-20140909/">Last Call Draft - 9 September 2014</a></em></blockquote>
+<ul>
+	<li>2014-08-25 - max-triple-count, max-member-count, max-kbyte-count support must > should per Aug 25 mtg (JA) </li>
+	<li>2014-08-25 - Clarify example (JA) </li>
+	<li>2014-08-22 - AT RISK the three limits, first reached per Aug 18 mtg (JA) </li>
+	<li>2014-08-21 - max-triple-count, max-member-count, max-kbyte-count with parms being integers per Aug 18 mtg (JA) </li>
+	<li>2014-08-05 - Re-cast sort criteria as rdf:List compatible with syntactic sugar for those (JA) </li>
+	<li>2014-08-05 - Fuss SOTD for Arnaud (JA) </li>
+	<li>2014-08-04 - Fuss with SortValueAscending value for Sandro (JA) </li>
+	<li>2014-08-04 - Incorporating resolutions from today's WG meeting (JA) </li>
+	<li>2014-07-30 - Rewording based on SS's 7/17 email comments (JA) </li>
+	<li>2014-07-29 - Fully specify 303+location's URI (JA) </li>
+	<li>2014-07-29 - Fuss with SortValueAscending value for Sandro (JA) </li>
+	<li>2014-07-29 - Update 6.2.9 to resolve the "add only at the end"/sorted container conflict (JA) </li>
+	<li>2014-07-29 - Remove chunked transfer encoding, which readers were conflating with paging (chunking) (JA) </li>
+	<li>2014-07-29 - Finish Turtle updates for change to Link header to locate sort criteria (JA) </li>
+	<li>2014-07-28 - Updates based on Sandro's email, excluding those on public comments list (JA) </li>
+	<li>2014-07-28 - Updates to address public review comment on must-not initiate paging (JA) </li>
+	<li>2014-07-28 - Updates to address public review comment on Prefer (JA) </li>
+	<li>2014-07-17 - Fixed minor spelling/grammar and validation problems (SS)</li>
+	<li>2014-07-15 - Final updates hopefully before LC2 draft issued (JA) </li>
+	<li>2014-07-09 - Fix Ashok's emailed comments (JA) </li>
+	<li>2014-07-09 - Clean up clients chapter, references, non/normative section listing in conformance, kitchen sink (JA) </li>
+	<li>2014-07-09 - Move paging example into "intro" chapter 4 (JA) </li>
+	<li>2014-07-08 - Resolve a set of editorial to-dos (JA) </li>
+	<li>2014-07-07 - Clients must consent to/invite paging per 20140630 resolution 2 (JA) </li>
+	<li>2014-07-07 - Rename single-page resource to in-sequence page resource per 20140630 resolution 3 (JA) </li>
+	<li>2014-06-10 - Use http-bis and Prefer RFC numbers, adjust BNF to match bis changes (JA) </li>
+	<li>2014-05-22 - Spec membership &amp; containment triples on same page (JA) </li>
+	<li>2014-05-22 - Spec syntax for page size hint; still need to wrap more text and examples around it (JA) </li>
+	<li>2014-05-20 - Spec Sandro's proposal, choose link relation for detection of paged resource changes (JA) </li>
+	<li>2014-05-19 - Rewrote non-normative parts, cleaned up terminology, ordering undefined when paging non-LDPC LDPRs (JA) </li>
+	<li>2014-05-15 - Fixed Respec messages by adding "terminology from LDP" section (JA) </li>
+	<li>2014-03-10 - Fixed namespaces (SS) </li>
+	<li>2014-02-18 - Split off LDP-Paging from LDP (SS) </li>
+</ul>
+<blockquote><em><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/94420c5678ae/ldp.html">February 18, 2014 Editor's Draft</a></em></blockquote>
+ -->
+</section>
+    
+  
+
+<section property="bibo:hasPart" resource="#references" typeof="bibo:Chapter" id="references" class="appendix"><!--OddPage--><h2 resource="#h-references" id="h-references"><span property="xhv:role" resource="xhv:heading"><span class="secno">D. </span>References</span></h2><section property="bibo:hasPart" resource="#normative-references" typeof="bibo:Chapter" id="normative-references"><h3 resource="#h-normative-references" id="h-normative-references"><span property="xhv:role" resource="xhv:heading"><span class="secno">D.1 </span>Normative references</span></h3><dl resource="" class="bibliography"><dt id="bib-LDP">[LDP]</dt><dd>Steve Speicher; John Arwe; Ashok Malhotra. <a property="dc:requires" href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 26 February 2015. W3C Recommendation. URL: <a property="dc:requires" href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
+</dd><dt id="bib-REL-CANONICAL">[REL-CANONICAL]</dt><dd>M. Ohye; J. Kupke. <a property="dc:requires" href="http://tools.ietf.org/html/rfc6596"><cite>The Canonical Link Relation</cite></a>. Informational. URL: <a property="dc:requires" href="http://tools.ietf.org/html/rfc6596">http://tools.ietf.org/html/rfc6596</a>
+</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a property="dc:requires" href="https://tools.ietf.org/html/rfc2119"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. Best Current Practice. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc2119">https://tools.ietf.org/html/rfc2119</a>
+</dd><dt id="bib-RFC5988">[RFC5988]</dt><dd>M. Nottingham. <a property="dc:requires" href="https://tools.ietf.org/html/rfc5988"><cite>Web Linking</cite></a>. October 2010. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc5988">https://tools.ietf.org/html/rfc5988</a>
+</dd><dt id="bib-RFC7230">[RFC7230]</dt><dd>R. Fielding, Ed.; J. Reschke, Ed.. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7230"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. June 2014. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7230">https://tools.ietf.org/html/rfc7230</a>
+</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd>R. Fielding, Ed.; J. Reschke, Ed.. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7231"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. June 2014. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7231">https://tools.ietf.org/html/rfc7231</a>
+</dd><dt id="bib-RFC7232">[RFC7232]</dt><dd>R. Fielding, Ed.; J. Reschke, Ed.. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7232"><cite>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</cite></a>. June 2014. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7232">https://tools.ietf.org/html/rfc7232</a>
+</dd><dt id="bib-RFC7238">[RFC7238]</dt><dd>J. Reschke. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7238"><cite>The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</cite></a>. June 2014. Experimental. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7238">https://tools.ietf.org/html/rfc7238</a>
+</dd><dt id="bib-RFC7240">[RFC7240]</dt><dd>J. Snell. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7240"><cite>Prefer Header for HTTP</cite></a>. June 2014. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7240">https://tools.ietf.org/html/rfc7240</a>
+</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd>Ian Jacobs; Norman Walsh. <a property="dc:requires" href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a property="dc:requires" href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
+</dd><dt id="bib-sparql11-query">[sparql11-query]</dt><dd>Steven Harris; Andy Seaborne. <a property="dc:requires" href="http://www.w3.org/TR/sparql11-query/"><cite>SPARQL 1.1 Query Language</cite></a>. 21 March 2013. W3C Recommendation. URL: <a property="dc:requires" href="http://www.w3.org/TR/sparql11-query/">http://www.w3.org/TR/sparql11-query/</a>
+</dd></dl></section><section property="bibo:hasPart" resource="#informative-references" typeof="bibo:Chapter" id="informative-references"><h3 resource="#h-informative-references" id="h-informative-references"><span property="xhv:role" resource="xhv:heading"><span class="secno">D.2 </span>Informative references</span></h3><dl resource="" class="bibliography"><dt id="bib-LDP-PAGING-TESTSUITE">[LDP-PAGING-TESTSUITE]</dt><dd>R. Garcia-Castro; F. Serena. <a property="dc:references" href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-paging-testsuite.html"><cite>Linked Data Platform Paging 1.0 Test Cases</cite></a>. Editor's Draft of Working Group Note. URL: <a property="dc:references" href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-paging-testsuite.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-paging-testsuite.html</a>
+</dd><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd>Steve Battle; Steve Speicher. <a property="dc:references" href="http://www.w3.org/TR/ldp-ucr/"><cite>Linked Data Platform Use Cases and Requirements</cite></a>. 13 March 2014. W3C Note. URL: <a property="dc:references" href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a>
+</dd><dt id="bib-NON-REPEATABLE-READS">[NON-REPEATABLE-READS]</dt><dd>Various. <a property="dc:references" href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Non-repeatable_reads"><cite>Wikipedia: Isolation (database systems)</cite></a>. N/A. URL: <a property="dc:references" href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Non-repeatable_reads">http://en.wikipedia.org/wiki/Isolation_(database_systems)#Non-repeatable_reads</a>
+</dd><dt id="bib-READ-COMMITTED">[READ-COMMITTED]</dt><dd>Various. <a property="dc:references" href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Read_committed"><cite>Wikipedia: Isolation (database systems)</cite></a>. N/A. URL: <a property="dc:references" href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Read_committed">http://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed</a>
+</dd><dt id="bib-RFC5005">[RFC5005]</dt><dd>M. Nottingham. <a property="dc:references" href="https://tools.ietf.org/html/rfc5005"><cite>Feed Paging and Archiving</cite></a>. September 2007. Proposed Standard. URL: <a property="dc:references" href="https://tools.ietf.org/html/rfc5005">https://tools.ietf.org/html/rfc5005</a>
+</dd><dt id="bib-turtle">[turtle]</dt><dd>Eric Prud'hommeaux; Gavin Carothers. <a property="dc:references" href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 25 February 2014. W3C Recommendation. URL: <a property="dc:references" href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a>
+</dd></dl></section></section></body></html>
\ No newline at end of file
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-paging-norespec 1.0_files/W3C-NOTE.css	Mon Jun 01 12:09:45 2015 -0400
@@ -0,0 +1,84 @@
+
+/* Style for a "Note" */
+
+/*
+   Copyright 1997-2003 W3C (MIT, ERCIM, Keio). All Rights Reserved.
+   The following software licensing rules apply:
+   http://www.w3.org/Consortium/Legal/copyright-software */
+
+/* $Id: base.css,v 1.28 2014-04-22 03:27:49 ijacobs Exp $ */
+
+body {
+  padding: 2em 1em 2em 70px;
+  margin: 0;
+  font-family: sans-serif;
+  color: black;
+  background: white;
+  background-position: top left;
+  background-attachment: fixed;
+  background-repeat: no-repeat;
+}
+:link { color: #00C; background: transparent }
+:visited { color: #609; background: transparent }
+a:active { color: #C00; background: transparent }
+
+a:link img, a:visited img { border-style: none } /* no border on img links */
+
+a img { color: white; }        /* trick to hide the border in Netscape 4 */
[email protected] all {                   /* hide the next rule from Netscape 4 */
+  a img { color: inherit; }    /* undo the color change above */
+}
+
+th, td { /* ns 4 */
+  font-family: sans-serif;
+}
+
+h1, h2, h3, h4, h5, h6 { text-align: left }
+/* background should be transparent, but WebTV has a bug */
+h1, h2, h3 { color: #005A9C; background: white }
+h1 { font: 170% sans-serif }
+h2 { font: 140% sans-serif }
+h3 { font: 120% sans-serif }
+h4 { font: bold 100% sans-serif }
+h5 { font: italic 100% sans-serif }
+h6 { font: small-caps 100% sans-serif }
+
+.hide { display: none }
+
+div.head { margin-bottom: 1em }
+div.head h1 { margin-top: 2em; clear: both }
+div.head table { margin-left: 2em; margin-top: 2em }
+
+p.copyright { font-size: small }
+p.copyright small { font-size: small }
+
[email protected] screen {  /* hide from IE3 */
+a[href]:hover { background: #ffa }
+}
+
+pre { margin-left: 2em }
+/*
+p {
+  margin-top: 0.6em;
+  margin-bottom: 0.6em;
+}
+*/
+dt, dd { margin-top: 0; margin-bottom: 0 } /* opera 3.50 */
+dt { font-weight: bold }
+
+ul.toc, ol.toc {
+  list-style: disc;		/* Mac NS has problem with 'none' */
+  list-style: none;
+}
+
[email protected] speech {
+ h1, h2, h3 { voice-stress: moderate; }
+ .hide { speak: none; }
+ p.copyright { voice-volume: x-soft; voice-rate: x-fast; }
+ dt { pause-before: 63ms; }
+}
+
+
+body {
+  background-image: url(//www.w3.org/StyleSheets/TR/logo-NOTE);
+}
Binary file ldp-paging-norespec 1.0_files/w3c_home.png has changed