Preparing for profiles - conformance section updates; add link to IETF draft
authorJohn Arwe
Tue, 01 Oct 2013 11:11:32 -0400
changeset 372 d85ca5c8cb68
parent 371 641980f7cb51
child 373 0562f8c4d4d4
Preparing for profiles - conformance section updates; add link to IETF draft
ldp.html
--- a/ldp.html	Mon Sep 30 16:53:10 2013 -0400
+++ b/ldp.html	Tue Oct 01 11:11:32 2013 -0400
@@ -310,13 +310,81 @@
   <li>B.2 Informative references: <b>informative</b></li>
 </ul>
 
-<p>A conforming <b>LDP server</b> is an application program that processes HTTP 
-requests and generates HTTP responses that conform to the rules defined in <a href="#ldpr" class="sectionRef"></a>
-and <a href="#ldpc" class="sectionRef"></a>.</p>
+<div class="ldp-issue-closed">
+<p>(OLD) A conforming <b>LDP server</b> is an application program that processes HTTP requests 
+and generates HTTP responses that conform to the rules defined in
+<a href="#ldpr" class="sectionRef"></a> and <a href="#ldpc" class="sectionRef"></a>.
+</p>
 
-<p>A conforming <b>LDP client</b> is an application program that generates HTTP 
-requests and processes HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef"></a>
-and <a href="#linked-data-platform-containers" class="sectionRef"></a>.</p>
+<p>(OLD) A conforming <b>LDP client</b> is an application program that generates HTTP 
+requests and processes HTTP responses that conform to the rules defined in <a href="#ldpr" class="sectionRef"></a>
+and <a href="#ldpc" class="sectionRef"></a>.
+</p>
+</div>
+
+<div class="ldp-issue-open">
+<p>(NEW) A conforming <b><dfn>LDP client</dfn></b> is a conforming HTTP client [[!HTTP11]] that follows the rules defined by LDP in
+<a href="#ldpclient" class="sectionRef"></a>.
+</p>
+
+<p>(NEW) A conforming <b><dfn>LDP server</dfn></b> is a conforming HTTP server [[!HTTP11]] that follows the rules defined by LDP in 
+<a href="#ldpr" class="sectionRef"></a> when it is serving LDPRs, and also
+<a href="#ldpc" class="sectionRef"></a> when it is serving LDPCs.
+LDP does not constrain its behavior when serving other HTTP resources.
+</p>
+
+<p>(NEW) LDP defines several classes of LDP servers, and places different conformance requirements on each of them.
+NOTE: "Basic" and "advanced" used here for drafting purposes; they correspond to 'vanilla' and 'chocolate', respectively.
+Final names TBD.
+</p>
+<ul>
+  <li><p>A conforming <b><dfn>basic LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
+  for basic LDP servers, as shown below.  Its content model is generally open and the server typically stores triples on behalf of clients
+  with minimal (if any) restrictions.
+  </p></li>
+  <li><p>A conforming <b><dfn>advanced LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
+  for advanced LDP servers, as shown below.  Its content model can be open or closed, and the server may impose non-trivial
+  restrictions on triples stored on behalf of conforming HTTP clients.
+  </p></li>
+</ul>
+
+<section>
+<h5>Example conformance rules</h5>
+
+<p>The following informative examples show how LDP assigns conformance criteria to each class of LDP servers using a single rule.</p>
+
+<section>
+<h6>Example: the same criteria apply to both basic and advanced LDP servers</h6>
+<div class="example">
+	<div class="rule">LDP servers SHOULD ...  </div>
+</div>
+
+<p>The preceding rule is equivalent to the following pair of rules:</p>
+<div class="example">
+	<div class="rule">Basic LDP servers SHOULD ...  </div>
+	<div class="rule">Advanced LDP servers SHOULD ...  </div>
+</div>
+</section>
+
+<section>
+<h6>Example: different criteria apply to basic and advanced LDP servers</h6>
+<p>Trying out different ways of covering each class while minimizing text duplication here.  Final format TBD.</p>
+<div class="example">
+	<div class="rule">(proposal 1) LDP servers MUST (basic)/SHOULD (advanced) ... </div>
+	<div class="rule">(proposal 2) Basic LDP servers MUST, and advanced LDP servers SHOULD, ... </div>
+	<div class="rule">(proposal 3) Basic LDP servers MUST ... .  Advanced LDP servers SHOULD do so. </div>
+</div>
+
+<p>Each of the preceding rules is equivalent to the following pair of rules:</p>
+<div class="example">
+	<div class="rule">4.8.2 Basic LDP servers MUST ...
+	</div>
+	<div class="rule">4.8.2 Advanced LDP servers SHOULD  ...
+	</div>
+</div>
+</section>
+
+</div>
 
 </section>
 
@@ -329,7 +397,7 @@
 	<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
 		that conform to the simple patterns and conventions in this section.
 		HTTP requests to access, modify, create or delete LDPRs are accepted
-		and processed by LDPR servers. Most LDPRs are domain-specific resources
+		and processed by <a title="LDP server">LDP servers</a>. Most LDPRs are domain-specific resources
 		that contain data for an entity in some domain, which could be
 		commercial, governmental, scientific, religious, or other.</p>
 	<p>Some of the rules defined in this document provide
@@ -366,12 +434,12 @@
 <section id="ldpr-general">
 <h2>General</h2>
 		
-	<div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
-	<div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers MUST provide an RDF representation for LDPRs. 
+	<div id="ldpr-4_2_1" class="rule">4.2.1 <a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
+	<div id="ldpr-4_2_2" class="rule">4.2.2 <a title="LDP server">LDP servers</a> MUST provide an RDF representation for LDPRs. 
 	The HTTP <code>Request-URI</code> of the LDPR is typically the subject of most triples in the response.
 	</div>
-	<div id="ldpr-4_2_3" class="rule">4.2.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs. For example, it
-		is common for LDPR servers to need to host binary or text resources
+	<div id="ldpr-4_2_3" class="rule">4.2.3 <a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs and non-LDPRs. For example, it
+		is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
 		that do not have useful RDF representations.
 	</div>
 
@@ -387,7 +455,7 @@
 		set explicitly.  This makes the representations much more useful to
 		client applications that don’t support inferencing.
 	</div>
-	<div id="ldpr-4_2_6" class="rule">4.2.6 LDPR servers MAY support standard representations beyond those
+	<div id="ldpr-4_2_6" class="rule">4.2.6 <a title="LDP server">LDP servers</a> MAY support standard representations beyond those
 		necessary to conform to this specification. These
 		could be other RDF formats, like N3 or NTriples, but non-RDF formats
 		like HTML [[!HTML401]] and JSON [[!RFC4627]] would likely be common.
@@ -397,13 +465,13 @@
 		UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
 		normative requirements.
 	</div>
-	<div id="ldpr-4_2_8" class="rule">4.2.8 LDPR server responses MUST use entity tags (either weak or strong 
+	<div id="ldpr-4_2_8" class="rule">4.2.8 <a title="LDP server">LDP server</a> responses MUST use entity tags (either weak or strong 
 ones) as response <code>ETag</code> header values.
 	</div>
 	<div id="ldpr-4_2_9" class="rule">4.2.9 LDPR
 		servers SHOULD enable simple creation and modification of LDPRs.
 		It is
-		common for LDPR servers to put restrictions on representations – for
+		common for <a title="LDP server">LDP servers</a> to put restrictions on representations – for
 		example, the range of <code>rdf:type</code> predicates, datatypes of
 		the objects of predicates, and the number of occurrences of predicates in an LDPR, but
 		servers SHOULD minimize those restrictions.  Enforcement of
@@ -411,7 +479,7 @@
 		that can modify resources. For some server applications, excessive
 		constraints on modification of resources may be required.
 	</div>
-	<div id="ldpr-4_2_10" class="rule">4.2.10 LDPR servers
+	<div id="ldpr-4_2_10" class="rule">4.2.10 <a title="LDP server">LDP servers</a>
 		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
 		with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
 		a link relation type of <code>type</code> (that is, <code>rel="type"</code>)
@@ -425,13 +493,13 @@
 		resources on the same server are also LDPRs.  Each HTTP <code>Request-URI</code> needs to be 
 		individually introspected by a conservative client, in the absence of outside information.
 	</div>
-	<div id="ldpr-4_2_11" class="rule">4.2.11 LDPR servers
+	<div id="ldpr-4_2_11" class="rule">4.2.11 <a title="LDP server">LDP servers</a>
 		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
 		of content defined by LDP.  Other specifications built on top of LDP may require clients
 		to implement inferencing [[!RDF-CONCEPTS]].  The practical implication is that all content defined by LDP
 		must be explicitly represented. 
 	</div>
-	<div id="ldpr-4_2_12" class="rule">4.2.12 LDPR servers MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP 
+	<div id="ldpr-4_2_12" class="rule">4.2.12 <a title="LDP server">LDP servers</a> MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP 
 		<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results 
 		in the creation of a new resource.
 	</div>
@@ -440,24 +508,24 @@
 
 <section id="ldpr-HTTP_GET">
 <h2>HTTP GET</h2>
-	<div id="ldpr-4_3_1" class="rule">4.3.1 LDPR servers MUST support the HTTP <code>GET</code> Method for LDPRs.
+	<div id="ldpr-4_3_1" class="rule">4.3.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>GET</code> Method for LDPRs.
 	</div>
-	<div id="ldpr-4_3_2" class="rule">4.3.2 LDPR servers MUST support the HTTP response headers defined in 
+	<div id="ldpr-4_3_2" class="rule">4.3.2 <a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in 
 		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
 	</div>
-	<div id="ldpr-4_3_3" class="rule">4.3.3 LDPR servers SHOULD provide a <code>text/turtle</code>
+	<div id="ldpr-4_3_3" class="rule">4.3.3 <a title="LDP server">LDP servers</a> SHOULD provide a <code>text/turtle</code>
 		representation of the requested LDPR [[!TURTLE]].
 	</div>
-	<div id="ldpr-4_3_4" class="rule">4.3.4 LDPR servers MAY provide 
+	<div id="ldpr-4_3_4" class="rule">4.3.4 <a title="LDP server">LDP servers</a> MAY provide 
 		representations of the requested LDPR beyond those
 		necessary to conform to this specification, using standard HTTP content negotiation ([[!HTTP11]] Section 12 - Content Negotiation). 
 		If the client does not indicate a preference, <code>text/turtle</code> SHOULD be returned.
 	</div>
-	<div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain, LDPR
-		clients MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
+	<div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain, 
+		<a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
 	</div>
-	<div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain, LDPR
-		clients MUST assume that the <code>rdf:type</code> values
+	<div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain, 
+		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
 		of a given LDPR can change over time.
 	</div>
 </section>
@@ -478,48 +546,48 @@
 		only when the LDPR supports that method.  This specification does not impose any
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
 		
-	<div id="ldpr-4_5_1" class="rule">4.5.1 If HTTP <code>PUT</code> is performed on an existing resource, LDPR servers MUST
+	<div id="ldpr-4_5_1" class="rule">4.5.1 If HTTP <code>PUT</code> is performed on an existing resource, <a title="LDP server">LDP servers</a> MUST
 		replace the entire persistent state of the identified resource with
 		the entity representation in the body of the request. 
-		LDPR servers MAY ignore server managed properties such as <code>dcterms:modified</code> 
+		<a title="LDP server">LDP servers</a> MAY ignore server managed properties such as <code>dcterms:modified</code> 
 		and <code>dcterms:creator</code> if they are not under
-		client control. Any LDPR servers that wish
+		client control. Any <a title="LDP server">LDP servers</a> that wish
 		to support a more sophisticated merge of data provided by the client
 		with existing state stored on the server for a resource MUST use HTTP
 		<code>PATCH</code>, not HTTP <code>PUT</code>.
 	</div>
 		
-	<div id="ldpr-4_5_2" class="rule">4.5.2 LDPR clients SHOULD use the HTTP <code>If-Match</code>
+	<div id="ldpr-4_5_2" class="rule">4.5.2 <a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
 		header and HTTP <code>ETags</code> to ensure it isn’t
 		modifying a resource that has changed since the client last retrieved
-		its representation. LDPR servers SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
-		to detect collisions. LDPR servers MUST respond with status code 412
+		its representation. <a title="LDP server">LDP servers</a> SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
+		to detect collisions. <a title="LDP server">LDP servers</a> MUST respond with status code 412
 		(Condition Failed) if <code>ETag</code>s fail to match when there are no other
-		errors with the request [[!HTTP11]].  LDPR servers that require conditional requests MUST respond with status code 428
+		errors with the request [[!HTTP11]].  <a title="LDP server">LDP servers</a> that require conditional requests MUST respond with status code 428
 		(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
 	</div>
-	<div id="ldpr-4_5_3" class="rule">4.5.3 LDPR clients SHOULD always assume that the set of predicates for a
+	<div id="ldpr-4_5_3" class="rule">4.5.3 <a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
 		resource of a particular type at an arbitrary server is open, in the
 		sense that different resources of the same type may not all have the
 		same set of predicates in their triples, and the set of predicates that
 		are used in the state of any one resource is not limited to any pre-defined
 		set.
 	</div>
-	<div id="ldpr-4_5_4" class="rule">4.5.4 LDPR clients SHOULD assume that an LDPR server could discard triples
+	<div id="ldpr-4_5_4" class="rule">4.5.4 <a title="LDP client">LDP clients</a> SHOULD assume that an <a title="LDP server">LDP server</a> could discard triples
 		whose predicates the server does not recognize or otherwise chooses
-		not to persist. In other words, LDPR servers MAY restrict themselves
-		to a known set of predicates, but LDPR clients MUST NOT restrict themselves to a known set of predicates 
+		not to persist. In other words, <a title="LDP server">LDP servers</a> MAY restrict themselves
+		to a known set of predicates, but <a title="LDP client">LDP clients</a> MUST NOT restrict themselves to a known set of predicates 
 		when their intent is to perform a later HTTP <code>PUT</code> to update the resource.
 	</div>
-	<div id="ldpr-4_5_5" class="rule">4.5.5 An LDPR client MUST preserve all triples retrieved using HTTP <code>GET</code> that
+	<div id="ldpr-4_5_5" class="rule">4.5.5 An <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
 		it doesn’t change whether it understands the predicates or not, when
 		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
 		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
 		[[RFC5789]].
 	</div>
-	<div id="ldpr-4_5_6" class="rule">4.5.6 LDPR servers MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
+	<div id="ldpr-4_5_6" class="rule">4.5.6 <a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
 	</div>
-	<div id="ldpr-4_5_7" class="rule">4.5.7 LDPR servers SHOULD allow clients to update resources without
+	<div id="ldpr-4_5_7" class="rule">4.5.7 <a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
 		requiring detailed knowledge of server-specific constraints.  
 		This is a consequence of the requirement to <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
 	</div>		
@@ -533,16 +601,16 @@
 	<p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
 	<a href="#ldpc-HTTP_DELETE" class="sectionRef"></a>.</p>
 		
-	<div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST remove the resource identified by the <code>Request-URI</code>.
+	<div id="ldpr-4_6_1" class="rule">4.6.1 <a title="LDP server">LDP servers</a> MUST remove the resource identified by the <code>Request-URI</code>.
 		After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
 		<code>Request-URI</code> MUST result in a 404 (Not found) or 410 (Gone) status
 		code. Clients SHOULD note that servers MAY reuse a URI under some circumstances.
 	</div>
 	
-	<div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MAY alter the state of other resources as a result of an
+	<div id="ldpr-4_6_2" class="rule">4.6.2 <a title="LDP server">LDP servers</a> MAY alter the state of other resources as a result of an
 		HTTP <code>DELETE</code> request. For example, it is acceptable for the server to
 		remove triples from other resources whose subject or object is the
-		deleted resource. It is also acceptable and common for LDPR servers to
+		deleted resource. It is also acceptable and common for <a title="LDP server">LDP servers</a> to
 		not do this – behavior is server application specific.
 	</div>
 </section>
@@ -553,7 +621,7 @@
 		<code>HEAD</code> responses include the same headers as <code>GET</code> responses.  
 		Thus, implementers should also carefully read sections <a href="#ldpr-HTTP_GET"></a> 
 		and <a href="#ldpr-HTTP_OPTIONS"></a>.</p>
-	<div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MUST support the HTTP <code>HEAD</code> method.</div>
+	<div id="ldpr-4_7_1" class="rule">4.7.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.</div>
 </section>
 
 <section id="ldpr-HTTP_PATCH">
@@ -561,18 +629,18 @@
 	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPRs 
 		only when the LDPR supports that method.  This specification does not impose any
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>	
-	<div id="ldpr-4_8_1" class="rule">4.8.1 LDPR servers MAY implement HTTP <code>PATCH</code> to allow modifications,
+	<div id="ldpr-4_8_1" class="rule">4.8.1 <a title="LDP server">LDP servers</a> MAY implement HTTP <code>PATCH</code> to allow modifications,
 		especially partial replacement, of their resources [[!RFC5789]]. No
 		minimal set of patch document formats is mandated by this document.
 	</div>
-	<div id="ldpr-4_8_2" class="rule">4.8.2 LDPR servers SHOULD allow clients to update resources without
+	<div id="ldpr-4_8_2" class="rule">4.8.2 <a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
 		requiring detailed knowledge of server-specific constraints.  
 		This is a consequence of the requirement to <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
 	</div>
-	<div id="ldpr-4_8_3" class="rule">4.8.3 LDPR servers SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
+	<div id="ldpr-4_8_3" class="rule">4.8.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
 		<a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpc-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
 	</div>
-	<div id="ldpr-4_8_4" class="rule">4.8.4 LDPR servers that support <code>PATCH</code> MUST
+	<div id="ldpr-4_8_4" class="rule">4.8.4 <a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
 		include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
 		requests, listing patch document media type(s) supported by the server.
 	</div>
@@ -589,8 +657,8 @@
 		add other requirements on <code>OPTIONS</code> responses.
 		</p>
 
-	<div id="ldpr-4_9_1" class="rule">4.9.1 LDPR servers MUST support the HTTP <code>OPTIONS</code> method.</div>		
-	<div id="ldpr-4_9_2" class="rule">4.9.2 LDPR servers MUST indicate their support for HTTP Methods by
+	<div id="ldpr-4_9_1" class="rule">4.9.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>OPTIONS</code> method.</div>		
+	<div id="ldpr-4_9_2" class="rule">4.9.2 <a title="LDP server">LDP servers</a> MUST indicate their support for HTTP Methods by
 		responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
 		Method tokens in the HTTP response header <code>Allow</code>.
 	</div>
@@ -622,7 +690,7 @@
 		are typically a subset of the triples in the resource
 		- same subject, predicate and object.
 	</p>
-	<p>LDPR servers may respond to requests for a
+	<p><a title="LDP server">LDP servers</a> may respond to requests for a
 		resource by redirecting the client to the first page resource –
 		using a 303 “See Other” redirect to the actual URL for the page
 		resource.  Alternatively, clients may introspect the resource for a paged representation 
@@ -713,11 +781,11 @@
 
 <section id="ldpr-PagingGET">
 <h3>HTTP GET</h3>
-<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, LDPR servers that support paging must also follow the requirements in this section</p>
+<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, <a title="LDP server">LDP servers</a> that support paging must also follow the requirements in this section</p>
 
-	<div id="ldpr-pagingGET-1" class="rule">4.10.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in
+	<div id="ldpr-pagingGET-1" class="rule">4.10.2.1 <a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
 		pages. In responses to <code>GET</code> requests with an LDPR as the <code>Request-URI</code>, 
-		LDPR servers that support paging SHOULD provide an HTTP <code>Link</code>
+		<a title="LDP server">LDP servers</a> that support paging SHOULD provide an HTTP <code>Link</code>
 		header whose target URI is the first page resource, and whose link relation type is <code>first</code> [[!RFC5988]]. 
 		This is the mechanism by which clients discover the URL of the first page.  If no such <code>Link</code>
 		header is present, then conservative clients will assume that the LDPR does not support paging.
@@ -727,15 +795,15 @@
 		The representation for any page, including the first, will include
 		the URL for the next page. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
 	</div>
-	<div id="ldpr-pagingGET-2" class="rule">4.10.2.2 LDPR servers MAY split the response representation of any LDPR. 
+	<div id="ldpr-pagingGET-2" class="rule">4.10.2.2 <a title="LDP server">LDP servers</a> MAY split the response representation of any LDPR. 
 		See <a href="#ldpr-Paging" class="sectionRef"></a> for
 		additional details.
 	</div>
-	<div id="ldpr-pagingGET-3" class="rule">4.10.2.3 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
+	<div id="ldpr-pagingGET-3" class="rule">4.10.2.3 <a title="LDP server">LDP servers</a> that initiate paging SHOULD respond to requests for a LDPR
 		by redirecting the client to the first page resource using a <code>303 See
 		Other</code> response with an HTTP <code>Location</code> header providing the first page resource URL.
 	</div>
-	<div id="ldpr-pagingGET-4" class="rule">4.10.2.4 LDPR servers that support paging MUST include a representation for the page resource.
+	<div id="ldpr-pagingGET-4" class="rule">4.10.2.4 <a title="LDP server">LDP servers</a> that support paging MUST include a representation for the page resource.
 	</div>
 	<div id="ldpr-pagingGET-4_1" class="rule">4.10.2.4.1 The page resource representation MUST have one triple with the subject
 		of the page, predicate of <code>ldp:nextPage</code> and
@@ -762,7 +830,7 @@
 <section id="ldpr-paging-HTTP_OPTIONS">
 <h3>HTTP OPTIONS</h3>
 
-<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 LDPR servers MUST indicate their support for paging by
+<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 <a title="LDP server">LDP servers</a> MUST indicate their support for paging by
 	responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
 	response header for link relations using the header name of <code>Link</code> and link relation type <code>first</code> [[!RFC5988]].
 </div>
@@ -1049,7 +1117,7 @@
 		constructs like Seq and List for expressing order.
 	</p>
 	<p>
-		Order becomes more important for LDPC servers when containers are
+		Order becomes more important for <a title="LDP server">LDP servers</a> when containers are
 		paginated. If the server does not respect ordering when constructing
 		pages, the client would be forced to retrieve all pages before
 		sorting the members, which would defeat the purpose of pagination. 
@@ -1127,7 +1195,7 @@
 	<p>The Linked Data Platform does not define how clients
 		discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
 
-	<div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
+	<div id="ldpc-5_2_1" class="rule">5.2.1 <a title="LDP server">LDP servers</a> MUST also be conformant <a title="LDP server">LDP servers</a>. A Linked Data Platform
 		Container MUST also be a conformant Linked Data Platform Resource.
 	</div>
 	<div id="ldpc-5_2_2" class="rule">5.2.2 LDPC membership is not exclusive; this means that the same resource
@@ -1139,7 +1207,7 @@
 		will be the LDPC resource itself, but it does not have to be. The
 		membership predicate is also variable and will often be a predicate
 		from the server application vocabulary. If there is no obvious
-		predicate from the server application vocabulary to use, LDPC servers
+		predicate from the server application vocabulary to use, <a title="LDP server">LDP servers</a>
 		SHOULD use the <code>rdfs:member</code> predicate. Member resources can be
 		any kind of resource identified by its URI, LDPR or otherwise.
 	</div>
@@ -1187,7 +1255,7 @@
 	<div id="ldpc-5_2_8" class="rule">5.2.8 LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
 		<code>rdf:Seq</code> or <code>rdf:List</code>.
 	</div>
-	<div id="ldpc-5_2_9" class="rule">5.2.9 LDPC servers SHOULD NOT re-use URIs, 
+	<div id="ldpc-5_2_9" class="rule">5.2.9 <a title="LDP server">LDP servers</a> SHOULD NOT re-use URIs, 
 		regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
 		Certain specific cases exist where a LDPC server MAY delete a resource and then later re-use the
 		URI when it identifies the same resource, but only when consistent with Web architecture [[WEBARCH]].
@@ -1244,7 +1312,7 @@
 		or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>).  See also
 		<a href="#ldpc-5_2_3">5.2.3</a>.
 	</div>
-	<div id="ldpc-5_3_2" class="rule">5.3.2 LDPC servers MAY represent the members of a paged LDPC in a sequential
+	<div id="ldpc-5_3_2" class="rule">5.3.2 <a title="LDP server">LDP servers</a> MAY represent the members of a paged LDPC in a sequential
 		order.  If the server does so, it MUST be specify the order using a triple 
 		whose subject is the page URI, 
 		whose predicate is <code>ldp:containerSortCriteria</code>, 
@@ -1318,7 +1386,7 @@
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
 		
 	<div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create member resources by submitting a representation as
-		the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, LDPC servers MUST
+		the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, <a title="LDP server">LDP servers</a> MUST
 		respond with status code 201 (Created) and the <code>Location</code>
 		header set to the new resource’s URL. Clients shall not expect any representation in the response
 		entity body on a 201 (Created) response.
@@ -1331,23 +1399,23 @@
 		the site that implements the LDPC.
 	</div>
 	
-	<div id="ldpc-5_4_3" class="rule">5.4.3 LDPC servers MAY accept an HTTP <code>POST</code> of non-RDF representations for
+	<div id="ldpc-5_4_3" class="rule">5.4.3 <a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations for
 		creation of any kind of resource, for example binary resources.  See <a href="#ldpc-5_4_13">5.4.13</a> for introspection
 		details.
 	</div>
-	<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a
+	<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, <a title="LDP server">LDP servers</a> MUST create an LDPR from a
 		RDF representation in the request entity body.  The newly created LDPR could also be a LDPC, therefore servers MAY
 		allow the creation of LDPCs within a LDPC. 
 	</div>
 	
-	<div id="ldpc-5_4_5" class="rule">5.4.5 LDPC servers MUST accept a request entity body with a request header
+	<div id="ldpc-5_4_5" class="rule">5.4.5 <a title="LDP server">LDP servers</a> MUST accept a request entity body with a request header
 	    of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
 	</div>
-	<div id="ldpc-5_4_6" class="rule">5.4.6 LDPC servers SHOULD use the <code>Content-Type</code> request header 
+	<div id="ldpc-5_4_6" class="rule">5.4.6 <a title="LDP server">LDP servers</a> SHOULD use the <code>Content-Type</code> request header 
 		to determine the representation format when the request has an entity body.  When the header is absent, 
-		LDPC servers MAY infer the content type by inspecting the entity body contents [[!HTTP11]].
+		<a title="LDP server">LDP servers</a> MAY infer the content type by inspecting the entity body contents [[!HTTP11]].
 	</div>
-	<div id="ldpc-5_4_7" class="rule">5.4.7 In RDF representations, LDPC servers MUST interpret the null relative
+	<div id="ldpc-5_4_7" class="rule">5.4.7 In RDF representations, <a title="LDP server">LDP servers</a> MUST interpret the null relative
 		URI for the subject of triples in the LDPR representation in the
 		request entity body as referring to the entity in the request body.
 		Commonly, that entity is the model for the “to be created” LDPR, so
@@ -1355,32 +1423,32 @@
 		triples in the created resource whose subject is the created
 		resource.  
 	</div>	
-	<div id="ldpc-5_4_8" class="rule">5.4.8 LDPC servers SHOULD assign the subject URI for the resource to be
+	<div id="ldpc-5_4_8" class="rule">5.4.8 <a title="LDP server">LDP servers</a> SHOULD assign the subject URI for the resource to be
 		created using server application specific rules in the absence of a <a href="#ldpc-5_4_10">client hint</a>.
 	</div>
-	<div id="ldpc-5_4_9" class="rule">5.4.9 LDPC servers SHOULD allow clients to create new resources without
+	<div id="ldpc-5_4_9" class="rule">5.4.9 <a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
 		requiring detailed knowledge of application-specific constraints.
 		This is a consequence of the requirement to 
 		<a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
 	</div>
-	<div id="ldpc-5_4_10" class="rule">5.4.10 LDPC servers MAY allow clients to suggest the URI for a resource
+	<div id="ldpc-5_4_10" class="rule">5.4.10 <a title="LDP server">LDP servers</a> MAY allow clients to suggest the URI for a resource
 		created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]].  LDP adds
 		no new requirements to this usage, so its presence functions as a client hint to the server 
 		providing a desired string to be incorporated into the server's final choice of resource URI.
 	</div>
 	
-	<div id="ldpc-5_4_11" class="rule">5.4.11 LDPC servers that allow member creation via <code>POST</code> 
+	<div id="ldpc-5_4_11" class="rule">5.4.11 <a title="LDP server">LDP servers</a> that allow member creation via <code>POST</code> 
 		SHOULD NOT re-use URIs, per the<a href="#ldpc-5_2_9">
 		general requirements on LDPCs</a>.
 	</div>
 	
 	<div id="ldpc-5_4_12" class="rule">5.4.12 Upon successful creation of a non-RDF and therefore non-LDPR member (HTTP status code of 
-	201-Created and URI indicated by <code>Location</code> response header), LDPC servers MAY create an associated LDPR
+	201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated LDPR
 	to contain data about the created resource.  If an LDPC server creates this associated LDPR it MUST indicate
 	its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
 	and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].
 	</div>	
-	<div id="ldpc-5_4_13" class="rule">5.4.13 LDPC servers that support <code>POST</code> MUST
+	<div id="ldpc-5_4_13" class="rule">5.4.13 <a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
 		include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
 		responses, listing post document media type(s) supported by the server.
 		LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
@@ -1414,11 +1482,11 @@
 		only when an LDPC supports that method.  This specification does not impose any
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
 		
-	<div id="ldpc-5_5_1" class="rule">5.5.1 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>membership triples</a>; 
+	<div id="ldpc-5_5_1" class="rule">5.5.1 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>membership triples</a>; 
 		if the server receives such a request, it SHOULD respond with a 409
 		(Conflict) status code.
 	</div>
-	<div id="ldpc-5_5_2" class="rule">5.5.2 LDPC servers MAY allow updating LDPC non-membership properties using
+	<div id="ldpc-5_5_2" class="rule">5.5.2 <a title="LDP server">LDP servers</a> MAY allow updating LDPC non-membership properties using
 		HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
 		MAY exclude server-managed properties such as <code>ldp:membershipSubject</code>, <code>ldp:membershipPredicate</code>
 		and <code>ldp:membershipPredicateInverse</code>.
@@ -1426,13 +1494,13 @@
 		use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL. 
 	</div>
 	    
-    <div id="ldpc-5_5_3" class="rule">5.5.3 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> requests
+    <div id="ldpc-5_5_3" class="rule">5.5.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> requests
 		with member resource information in the request representation.
 		See section <a href="#ldpc-member_data">5.1.1 Container
 		Member Information</a> for additional details.
 	</div>
 	
-	<div id="ldpc-5_5_4" class="rule">5.5.4 LDPC servers that allow member creation via <code>PUT</code> 
+	<div id="ldpc-5_5_4" class="rule">5.5.4 <a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code> 
 		SHOULD NOT re-use URIs, per the <a href="#ldpc-5_2_9">
 		general requirements on LDPCs</a>.
 	</div>
@@ -1471,7 +1539,7 @@
 <section id="ldpc-HTTP_HEAD">
 <h2>HTTP HEAD</h2>
 	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
-		<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also LDPC servers must also include HTTP headers
+		<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also <a title="LDP server">LDP servers</a> must also include HTTP headers
 		on response to <code>OPTIONS</code>, see <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
 		Thus, implementers supporting <code>HEAD</code> should also carefully read the
 		<a href="#ldpc-HTTP_GET" class="sectionRef"></a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a>.</p>
@@ -1483,7 +1551,7 @@
 		only when a LDPC supports that method.  This specification does not impose any
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
 		
-	<div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
+	<div id="ldpc-5_8_1" class="rule">5.8.1 <a title="LDP server">LDP servers</a> are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
 		method for updating LDPC non-membership properties.
 	</div>
 </section>
@@ -1494,14 +1562,14 @@
 		</p>
 
 	<div id="ldpc-5_9_1" class="rule">5.9.1  
-		LDPC servers SHOULD define a corresponding
+		<a title="LDP server">LDP servers</a> SHOULD define a corresponding
 		<a>non-member resource</a>
 		to support requests for information about a LDPC
 		without retrieving a full representation including all of its members; 
 		see section <a href="#ldpc-get_non-member_props">5.1.2 Retrieving Only Non-member Properties</a> for
 		examples. 
 		In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</code>, 
-		LDPC servers that define a non-member resource SHOULD provide an HTTP <code>Link</code>
+		<a title="LDP server">LDP servers</a> that define a non-member resource SHOULD provide an HTTP <code>Link</code>
 		header whose target URI is the <a>non-member resource</a>, and whose link relation type is 
 		<code>http://www.w3.org/ns/ldp#nonMemberResource</code> [[!RFC5988]]. 
 		This is the mechanism by which clients discover the URL of the non-member resource.  
@@ -1533,7 +1601,8 @@
 		<p>The LDP Working Group proposes incorporation of the features described in this section.</p>
 		<ul>
 		<li>The addition of <a>Accept-Post</a> in this specification is pending 
-		advancement of an IETF draft that would fully include it, see [[!RFC5789]].  Once LDP is in
+		advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-accept-post/">IETF draft</a>
+		that would fully include it, based on the Accept-Patch header's design from [[!RFC5789]].  Once LDP is in
 		Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF
 		working with the W3C Director.</li>
 		</ul>
@@ -1541,7 +1610,7 @@
 		
 	<p>This specification introduces a new HTTP response header <code>Accept-Post</code> used
 		to specify the document formats accepted by the server on HTTP <code>POST</code> requests.
-		It is modeled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
+		It is modelled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
 	</p>
    
 	<div id="header-accept-post-1" class="rule">6.1.1 The syntax for <code>Accept-Post</code>, using
@@ -1588,6 +1657,39 @@
 </section>
 </section> <!-- Header defns -->
     
+<section id="ldpclient">
+<h1>Linked Data Platform Clients</h1>
+<div class="ldp-issue-open">
+
+
+<p>All of the following rules are just copied here, without change; still need to be removed from original section.
+Should consider making this section come before the server sections; doing so would cause mass-renumbering however.
+</p>
+	<div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain, 
+		<a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
+	</div>
+	<div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain, 
+		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
+		of a given LDPR can change over time.
+	</div>
+	<div id="ldpr-4_5_3" class="rule">4.5.3 <a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
+		resource of a particular type at an arbitrary server is open, in the
+		sense that different resources of the same type may not all have the
+		same set of predicates in their triples, and the set of predicates that
+		are used in the state of any one resource is not limited to any pre-defined
+		set.
+	</div>
+	<div id="ldpr-4_5_5" class="rule">4.5.5 An <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
+		it doesn’t change whether it understands the predicates or not, when
+		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
+		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
+		[[RFC5789]].
+	</div>
+
+</div>
+</section> <!-- Client constraints -->
+
+
 <section class='appendix informative'>
 <h2>Acknowledgements</h2>
      
@@ -1612,6 +1714,7 @@
 
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote>  -->
 <ul>
+    <li>2013-10-01 - Conformance section drafting (JA)</li>
     <li>2013-09-23 - Remove client/server-initiated paging terms (JA)</li>
     <li>2013-09-17 - Change must to MUST in <a href="#ldpc-5_6_4">5.6.4</a> (SS)</li>
 	<li>2013-09-17 - Removed "at-risk" inlining feature from spec, <a href="https://www.w3.org/2012/ldp/track/actions/98">ACTION-98</a> (SS)</li>