--- a/ldp.html	Tue Oct 01 14:50:16 2013 -0400
+++ b/ldp.html	Tue Oct 01 16:12:23 2013 -0400
@@ -1733,6 +1733,112 @@
 </div>
 </section> <!-- Client constraints -->
 
+<section id="base-specs" class="informative">
+<h1>Notable information from normative references</h1>
+<div class="ldp-issue-open">
+
+<p>
+AT THIS POINT ALL TEXT HAS BEEN COPIED HERE, NOT MOVED.
+DEPENDING UPON HOW THE WG ALTERS THE PROPOSAL BASED ON FEEDBACK, IT MIGHT CHANGE.
+THE 2119 LANGUAGE NEEDS TO BE REMOVED TOO.
+Given that it's from base specs => important to understand, should be moved up before 
+most of the normative sections IMO - renumbering hit again.
+</p>
+
+<p>
+While readers, and especially implementers, of LDP are assumed to understand the information in its normative 
+references, the working group has found that certain points are particularly important to understand.
+For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
+experience has shown that few non-experts find all of them obvious.  This section enumerates these topics; 
+it is simply re-stating (informatively) information locatable via the normative references.
+</p>
+
+<section id="specs-webarch" class="informative">
+<h1>Architecture of the World Wide Web</h1>
+Reference: [[WEBARCH]]
+
+	<div id="ldpc-5_2_2" class="rule">5.2.2 LDPC membership is not exclusive; this means that the same resource
+	(LDPR or not) MAY be a member of more than one LDPC.
+	</div>
+	<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]].
+		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
+		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
+	</div>
+
+</section> 
+
+<section id="specs-http" class="informative">
+<h1>HTTP 1.1</h1>
+Reference: [[HTTP11]]
+
+	<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.
+	</div>		
+	<div id="ldpr-4_2_7" class="rule">4.2.7 LDPRs MAY be created, updated and deleted using methods not defined in
+		this document, for example through application-specific means, SPARQL
+		UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
+		normative requirements.
+	</div>
+	<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). 
+	</div>
+	<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 <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 <a title="LDP server">LDP servers</a> to
+		not do this – behavior is server application specific.
+	</div>
+	<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="ldpc-5_4_2" class="rule">5.4.2 ... An LDPC MAY also contain resources that were
+		added through other means ... stays normative, sept 25 email
+	</div>
+	<div id="ldpc-5_4_6" class="rule">5.4.6 ...  When the header is absent, 
+		<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_10" class="rule">5.4.10 ... stays normative, sept 25 email
+	</div>
+
+</section> 
+
+<section id="specs-rdf" class="informative">
+<h1>RDF</h1>
+Reference: [[RDF-CONCEPTS]]
+
+	<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
+		additional triples whose subjects are the members of the container,
+		or that are from the representations of the members (if they have RDF
+		representations). This allows a LDPC server to provide clients with
+		information about the members without the client having to do a <code>GET</code>
+		on each member individually.  See <a href="#ldpc-member_data">section 5.1.1 Container
+		Member Information</a> for additional details.
+    </div>
+	<div id="ldpc-5_2_7" class="rule">5.2.7  , but it [The representation of a LDPC] MAY have additional
+		<code>rdf:type</code>s.
+	</div>
+	<div id="ldpc-5_3_1" class="rule">5.3.1 ... stays normative, sept 25 email
+	</div>
+
+</section> 
+
+
+</div>
+</section> <!-- Base specs -->
+
 
 <section class='appendix informative'>
 <h2>Acknowledgements</h2>
@@ -1758,9 +1864,10 @@
 
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote>  -->
 <ul>
+    <li>2013-10-01 - Mock up new section for rules declared to be non-normative restatements of info from other specs (JA)</li>
     <li>2013-10-01 - Revising terminology - membership triples and friends (JA)</li>
     <li>2013-10-01 - Revising introduction (JA)</li>
-    <li>2013-10-01 - Conformance section drafting (JA)</li>
+    <li>2013-10-01 - Conformance section drafting + mock up "LDP Clients" section as part of that (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>