ldp.html
changeset 167 ae4592939639
parent 158 8af0b25f2748
child 169 9bff8b24692d
--- 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>