--- a/ldp.html Mon Mar 03 14:23:55 2014 -0500
+++ b/ldp.html Mon Mar 03 14:41:49 2014 -0500
@@ -1473,24 +1473,6 @@
but there is no requirement to materialize this triple in the LDP-BC representation.
</h2></section>
-<!-- TODO: Consider removing the following 2 sections, they are informative but not really needed -->
-
-<section id="ldpbc-containres"><h2 class="normal"><a title="Linked Data Platform Basic Container">LDP Basic Containers</a> MUST
- behave as if their state contains the triple
- whose subject is the LDPC URI,
- whose predicate is <code>ldp:membershipResource</code>,
- and whose object is the LDPC URI (subject and object are the same URI),
- but there is no requirement to materialize this triple in LDP-BC representations.
-</h2></section>
-
-<section id="ldpbc-containtriple"><h2 class="normal"><a title="Linked Data Platform Basic Container">LDP Basic Containers</a> MUST
- behave as if their state contains the triple
- whose subject is the LDPC URI,
- whose predicate is <code>ldp:hasMemberRelation</code>,
- and whose object is <code>ldp:contains</code>,
- but there is no requirement to materialize this triple in LDP-BC representations.
-</h2></section>
-
</section> <!-- ldpbc General -->
</section> <!-- ldpbc Basic -->
@@ -1498,8 +1480,6 @@
<section id="ldpdc">
<h2>Direct</h2>
-<!-- TODO: membership triples definitions? Could be valuable to have some informative statement here
- such as: Direct containers add the concept of membership, flexibility of which resources associated and which predicate to indicate-->
<p>The following section contains normative clauses for <a title="">Linked Data Platform Direct Container</a>.</p>
@@ -2168,20 +2148,18 @@
</section>
</section> <!-- status code defns -->
-
<section class='informative' id='security'>
<h1>Security Considerations</h1>
-As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many
+<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.
+access control policy.</p>
</section>
-
<section class='appendix informative'>
<h2>Acknowledgements</h2>
@@ -2204,6 +2182,7 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
<ul>
+ <li>2014-03-03 - Removed LDP-BC clauses that introduce membership (SS) </li>
<li>2014-03-03 - Tweaked LDPR PUT clauses to better match new defn of LDPR (SS) </li>
<li>2014-03-03 - Folded #ldpclients section into #ldprs (SS) </li>
<li>2014-03-01 - Split out different kinds of LDPRs into their own subsection (SS)</li>