--- a/ldp.html	Tue Oct 22 15:35:52 2013 -0400
+++ b/ldp.html	Tue Oct 22 16:30:30 2013 -0400
@@ -600,7 +600,8 @@
 		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, <a title="LDP server">LDP servers</a> MUST
+	<div id="ldpr-4_5_1" class="rule">4.5.1 If a HTTP <code>PUT</code> is accepted on an existing resource, 
+		<a title="LDP server">LDP servers</a> MUST
 		replace the entire persistent state of the identified resource with
 		the entity representation in the body of the request. 
 		<a title="LDP server">LDP servers</a> MAY ignore server managed properties such as <code>dcterms:modified</code> 
@@ -611,6 +612,23 @@
 		<code>PATCH</code>, not HTTP <code>PUT</code>.
 	</div>
 		
+	<div id="ldpr-4_5_1_1" class="rule">4.5.1.1 
+		If an otherwise valid HTTP <code>PUT</code> request is received 
+		that attempts to change triples the server does not allow clients to modify, 
+		<a title="LDP server">LDP servers</a> MUST 
+		respond with a 4xx range status code (typically
+		409 Conflict). 
+		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+		information about which triples could not be
+		persisted.
+		The format of the 4xx response body is not constrained by LDP.
+	</div>
+	<blockquote>
+		Informative note: Clients might provide triples equivalent to those already in the resource's state,
+		e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the 
+		server-controlled triples are identical on the GET response and the subsequent PUT request.
+	</blockquote>
+		
 	<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
@@ -627,11 +645,15 @@
 		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 <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, <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 id="ldpr-4_5_4" class="rule">4.5.4 
+		If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server 
+		chooses not to persist, e.g. unknown content,
+		<a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
+		[[HTTP11]].  
+		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+		information about which triples could not be
+		persisted.
+		The format of the 4xx response body is not constrained by LDP.
 	</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
@@ -1985,6 +2007,7 @@
 
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote>  -->
 <ul>
+    <li>2013-10-22 - Resolve ACTION-109 Update spec to reflect 10/21 resolution for ignoring triples on PUT (JA)</li>
     <li>2013-10-22 - Resolve ACTION-107 Update spec to reflect 10/07 resolution on 5.6.2 LDPC deletion (JA)</li>
     <li>2013-10-22 - Resolve ACTION-102 Make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete. (JA)</li>
     <li>2013-10-22 - Resolve ACTION-103 Change SHOULD to MUST in 4.10.2.3 "LDPR servers that initiate paging SHOULD respond to request ..." (JA)</li>