--- a/ldp.html Mon Jul 08 11:18:19 2013 -0400
+++ b/ldp.html Mon Jul 08 13:25:02 2013 -0400
@@ -593,7 +593,9 @@
<h2 id="ldpr-HTTP_OPTIONS">HTTP OPTIONS</h2>
<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPRs
beyond those in [[!HTTP11]]. Other sections of this specification, for example
- <a href="#ldpr-HTTP_PATCH">PATCH</a> and <a href="#ldpr-paging-HTTP_OPTIONS">Paging</a>,
+ <a href="#ldpr-HTTP_PATCH">PATCH</a>,
+ <a href="#header-accept-post">Accept-Post</a>
+ and <a href="#ldpr-paging-HTTP_OPTIONS">Paging</a>,
add other requirements on <code>OPTIONS</code> responses.
</p>
@@ -1420,6 +1422,7 @@
SHOULD NOT re-use URIs, per the<a href="#ldpc-5_2_9">
general requirements on LDPCs</a>.
</div>
+ <div class="ldp-issue-open">
<div id="ldpc-5_4_12" class="rule">ISSUE-15 5.4.12 LDPC servers that allow non-LDPR member creation via POST
MAY create a companion LDPR, things to work out:
<ul>
@@ -1429,6 +1432,34 @@
<li>Do we need to say anyting about update</li>
</ul>
</div>
+ </div>
+
+ <div class="ldp-issue-pending">
+ <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/80">ISSUE-80</a></div>
+ How does a client know which POST requests create new resources.
+ <p>
+ Note from editor: the MUST here keeps this aligned with what we decided for OPTIONS on PATCH; in both
+ cases the header registration says SHOULD, and the LDP spec says MUST. What makes that look a bit odd is
+ that in the Accept-Post case, the registration and LDP are the same document. Thus I added informative
+ text here explicitly talking to the apparent discrepancy.
+ </div>
+
+ <div id="ldpr-5_4_13" class="rule">5.4.13 LDPR servers 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
+ can accept <code>POST</code> requests with other semantics.
+ While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when
+ making requests to an LDP server, that every successful <code>POST</code> request will result in the
+ creation of a new resource; they must rely on out of band information for knowledge of which <code>POST</code> requests,
+ if any, will have the "create new resource" semantic.
+ This requirement on LDP servers is intentionally stronger than the one levied in the
+ <a href="#header-accept-post">header registration</a>; it is unrealistic to expect all existing resources
+ that support <code>POST</code> to suddenly return a new header or for all new specifications constraining
+ <code>POST</code> to be aware of its existence and require it, but it is a reasonable requirement for new
+ specifications such as LDP.
+ </div>
+
</section>
<section>
@@ -1530,6 +1561,66 @@
</section>
</section>
+<section>
+<h2>HTTP Header Definitions</h2>
+
+<section>
+<h3 id="header-accept-post">The Accept-Post Response Header</h3>
+
+ <div class="ldp-issue-pending">
+ <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/80">ISSUE-80</a></div>
+ How does a client know which POST requests create new resources
+ </div>
+
+ <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]].
+ </p>
+
+ <div id="header-accept-post-1" class="rule">6.1.1 The syntax for <code>Accept-Post</code>, using
+ the ABNF syntax defined in Section 2.1 of [[!HTTP11]], is:
+ <blockquote><code>Accept-Post = "Accept-Post" ":" 1#media-type</code>
+ <p>
+ The <code>Accept-Post</code> header specifies a comma-separated list of media-
+ types (with optional parameters) as defined by [[!HTTP11]], Section 3.7.
+ </p>
+ </blockquote>
+ </div>
+
+ <div id="header-accept-post-2" class="rule">6.1.2
+ The <code>Accept-Post</code> HTTP header SHOULD appear in the <code>OPTIONS</code> response for any resource
+ that supports the use of the <code>POST</code> method. The presence of the
+ <code>Accept-Post</code> header in response to any method is an implicit
+ indication that <code>POST</code> is allowed on the resource identified by the
+ <code>Request-URI</code>. The presence of a specific document format in
+ this header indicates that that specific format is allowed on <code>POST</code> requests to the
+ resource identified by the <code>Request-URI</code>.
+ </div>
+
+<section>
+<h4 id="header-accept-post-iana">IANA Registration Template</h4>
+ <blockquote>
+ <p>
+ The Accept-Post response header must be added to the permanent registry (see [[!RFC3864]]).
+ </p>
+ <p>
+ Header field name: Accept-Post
+ </p>
+ <p>
+ Applicable Protocol: HTTP
+ </p>
+ <p>
+ Author/Change controller: W3C
+ </p>
+ <p>
+ Specification document: this specification
+ </p>
+ </blockquote>
+</section>
+
+</section>
+</section> <!-- Header defns -->
+
<section class='appendix informative'>
<h2>Acknowledgements</h2>
@@ -1554,6 +1645,14 @@
<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
-->
<ul>
+ <li>2013-07-08 - ISSUE- (JA)</li>
+ <li>2013-07-08 - ISSUE- (JA)</li>
+ <li>2013-07-08 - ISSUE- (JA)</li>
+ <li>2013-07-08 - ISSUE-80 Accept-Post (JA)</li>
+ <li>2013-07-08 - ISSUE-32 Must support options (JA)</li>
+ <li>2013-07-08 - ISSUE-78 No client inferencing (JA)</li>
+ <li>2013-07-08 - ISSUE-77 Move "must have rdf:type explicitly" to Best Practices (JA)</li>
+ <li>2013-07-08 - ISSUE-57 Knowing it's an LDP server (JA)</li>
<li>2013-07-01 - ISSUE-33 Moved 5.1.3 Paging (LDPC) to 4.8 (LDPR) (SS)</li>
<li>2013-06-18 - ISSUE-75 5.2.5 membershipxxx predicates required, per 2013-06-18 F2F resolution (JA)</li>
<li>2013-06-18 - ISSUE-63 End of 5.3 + example rewritten for 2013-06-18 F2F resolution (JA)</li>