--- a/ldp-paging.html Mon Jun 09 07:35:26 2014 -0500
+++ b/ldp-paging.html Tue Jun 10 10:43:58 2014 -0400
@@ -101,14 +101,14 @@
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/55082/status",
doRDFa: "1.1",
localBiblio: {
- "HTTPBIS-MESSAGING": {
+ "RFC7230": {
title: "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"
- , href: "http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21"
+ , href: "http://tools.ietf.org/html/rfc7230"
, authors: [
"R. Fielding"
, "J. Reschke"
]
- , status: "In Last Call"
+ , status: "Proposed Standard"
, publisher: "IETF"
},
"READ-COMMITTED": {
@@ -129,13 +129,13 @@
, status: "N/A"
, publisher: "Wikipedia"
},
- "Prefer": {
- title: "Prefer"
- , href: "http://tools.ietf.org/html/draft-snell-http-prefer-18"
+ "RFC7240": {
+ title: "Prefer Header for HTTP"
+ , href: "http://tools.ietf.org/html/rfc7240"
, authors: [
"J. Snell"
]
- , status: "Internet Draft"
+ , status: "Proposed Standard"
, publisher: "IETF"
},
"RFC5005": {
@@ -258,12 +258,12 @@
<dl class="glossary">
<dt><dfn>LDP server</dfn></dt>
- <dd>A conforming HTTP server [[HTTP11]] that follows the rules defined by [[LDP]]
+ <dd>A conforming HTTP server [[RFC7230]] that follows the rules defined by [[LDP]]
when it is serving LDPRs and LDPCs.
<p></p></dd>
<dt><dfn>LDP client</dfn></dt>
- <dd>A conforming HTTP client [[HTTP11]] that follows the rules defined by [[LDP]] when
+ <dd>A conforming HTTP client [[RFC7230]] that follows the rules defined by [[LDP]] when
interacting with a <a>LDP server</a>.
<p></p></dd>
@@ -943,7 +943,7 @@
<p>This specification introduces new ...
<!--
parameters on the HTTP <code>Prefer</code> request header's
- <code>return=representation</code> preference [[!Prefer]], used optionally by clients to
+ <code>return=representation</code> preference [[!RFC7240]], used optionally by clients to
supply a hint to help the server form a response that is most appropriate to
the client's needs. The LDP-defined parameters suggest the portion(s) of a resource's state that the
client application is interested in and, if received, is likely to be
@@ -957,11 +957,11 @@
<p>
Non-normative note: LDP server implementers should carefully consider the effects of these
- preferences on caching, as described in section 2 of [[!Prefer]].
+ preferences on caching, as described in section 2 of [[!RFC7240]].
</p>
<p>
- Non-normative note: [[!Prefer]] recommends that server implementers include a
+ Non-normative note: [[!RFC7240]] recommends that server implementers include a
<code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
behavior with respect to honoring hints from the response content.
<a href="#prefer-examples">Examples</a> illustrates some cases where the header is unnecessary.
@@ -992,8 +992,8 @@
<code>DIGIT</code> is an integer between zero and nine [[!RFC5234]],
<code>DQUOTE</code> is a double quote [[!RFC5234]],
and
- <code>token</code> is as defined in [[!HTTPBIS-MESSAGING]].
- The generic preference BNF [[!Prefer]] allows either a quoted string or a token as the value of a
+ <code>token</code> is as defined in [[!RFC7230]].
+ The generic preference BNF [[!RFC7240]] allows either a quoted string or a token as the value of a
preference parameter; LDP Paging assigns a meaning to the value only when it is a quoted string.
Servers MAY ignore a page size of zero, or unrecognized <code>units</code>,
and process the request as if the hint was absent.
@@ -1324,7 +1324,7 @@
<p>
The <code>209 Related Content</code> must be added to the permanent status code registry
maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
- (see [[HTTPBIS-SEMANTICS]], [[!RFC2817]]).
+ (see [[RFC7231]], [[!RFC2817]]).
</p>
<p>
Value: 209
--- a/ldp.html Mon Jun 09 07:35:26 2014 -0500
+++ b/ldp.html Tue Jun 10 10:43:58 2014 -0400
@@ -90,14 +90,34 @@
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/55082/status",
doRDFa: "1.1",
localBiblio: {
- "HTTPBIS-SEMANTICS": {
- title: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"
- , href: "http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/"
+ "RFC7230": {
+ title: "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"
+ , href: "http://tools.ietf.org/html/rfc7230"
, authors: [
"R. Fielding"
, "J. Reschke"
]
- , status: "In Last Call"
+ , status: "Proposed Standard"
+ , publisher: "IETF"
+ },
+ "RFC7231": {
+ title: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"
+ , href: "http://tools.ietf.org/html/rfc7231"
+ , authors: [
+ "R. Fielding"
+ , "J. Reschke"
+ ]
+ , status: "Proposed Standard"
+ , publisher: "IETF"
+ },
+ "RFC7232": {
+ title: "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests"
+ , href: "http://tools.ietf.org/html/rfc7232"
+ , authors: [
+ "R. Fielding"
+ , "J. Reschke"
+ ]
+ , status: "Proposed Standard"
, publisher: "IETF"
},
"RFC2817": {
@@ -137,13 +157,13 @@
, status: "W3C Recommendation"
, publisher: "W3C"
},
- "Prefer": {
- title: "Prefer"
- , href: "http://tools.ietf.org/html/draft-snell-http-prefer-18"
+ "RFC7240": {
+ title: "Prefer Header for HTTP"
+ , href: "http://tools.ietf.org/html/rfc7240"
, authors: [
"J. Snell"
]
- , status: "Internet Draft"
+ , status: "Proposed Standard"
, publisher: "IETF"
},
"Accept-Post": {
@@ -312,7 +332,8 @@
<section id="terms">
<h1>Terminology</h1>
-<p>Terminology is based on W3C's Architecture of the World Wide Web [[WEBARCH]] and Hyper-text Transfer Protocol [[HTTP11]].
+<p>Terminology is based on W3C's Architecture of the World Wide Web [[!WEBARCH]] and
+ Hyper-text Transfer Protocol ([[!RFC7230]], [[!RFC7231]], [[!RFC7232]]).
</p>
<dl class="glossary">
<dt>Link</dt>
@@ -324,19 +345,23 @@
<dd>As defined by Tim Berners-Lee [[LINKED-DATA]].<p></p></dd>
<dt>Client</dt>
- <dd>A program that establishes connections for the purpose of sending requests [[HTTP11]].<p></p></dd>
+ <dd>A program that establishes connections for the purpose of sending one or more HTTP requests [[!RFC7230]].<p></p></dd>
<dt>Server</dt>
- <dd>An application
- program that accepts connections in order to service requests by
- sending back responses.
- <p>Any given program may be capable of being
- both a client and a server; our use of these terms refers only to
- the role being performed by the program for a particular
- connection, rather than to the program's capabilities in general.
- Likewise, any server may act as an origin server, proxy, gateway,
- or tunnel, switching behavior based on the nature of each request
- [[HTTP11]]. </p></dd>
+ <dd>A program that accepts connections in order to service HTTP requests by sending HTTP responses.
+ <p>
+ The terms "client" and "server" refer only to the roles that these programs perform for a particular connection.
+ The same program might act as a client on some connections and a server on others.
+ </p>
+ <p>
+ HTTP enables the use of intermediaries to satisfy requests through a
+ chain of connections. There are three common forms of HTTP
+ intermediary: proxy, gateway, and tunnel. In some cases, a single
+ intermediary might act as an origin server, proxy, gateway, or
+ tunnel, switching behavior based on the nature of each request.
+ [[!RFC7230]].
+ </p>
+ </dd>
<dt><dfn>Linked Data Platform Resource</dfn> (<abbr title="Linked Data Platform Resource">LDPR</abbr>)</dt>
<dd>A HTTP resource whose state is represented in any way that conforms to the simple lifecycle
@@ -471,12 +496,12 @@
<li>C.2 Non-normative references: <b>non-normative</b></li>
</ul>
-<p>A conforming <b><dfn>LDP client</dfn></b> is a conforming HTTP client [[!HTTP11]] that follows the rules defined by LDP in
+<p>A conforming <b><dfn>LDP client</dfn></b> is a conforming HTTP client [[!RFC7230]] that follows the rules defined by LDP in
<a href="#ldpr" class="sectionRef"></a> and also
<a href="#ldpc" class="sectionRef"></a>.
</p>
-<p>A conforming <b><dfn>LDP server</dfn></b> is a conforming HTTP server [[!HTTP11]] that follows the rules defined by LDP in
+<p>A conforming <b><dfn>LDP server</dfn></b> is a conforming HTTP server [[!RFC7230]] that follows the rules defined by LDP in
<a href="#ldpr" class="sectionRef"></a> when it is serving LDPRs, and also
<a href="#ldpc" class="sectionRef"></a> when it is serving LDPCs.
LDP does not constrain its behavior when serving other HTTP resources.
@@ -626,7 +651,7 @@
<section id="ldpr-HTTP_POST">
<h2>HTTP POST</h2>
<p>
- Per [[HTTP11]], this HTTP method is optional and
+ Per [[!RFC7231]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
When a LDP server supports this method,
this specification imposes no new requirements for LDPRs.
@@ -643,7 +668,7 @@
<section id="ldpr-HTTP_PUT">
<h2>HTTP PUT</h2>
<p>
- Per [[HTTP11]], this HTTP method is optional and
+ Per [[!RFC7231]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
When a LDP server supports this method,
this specification imposes the following new requirements for LDPRs.
@@ -695,7 +720,7 @@
If an otherwise valid HTTP <code>PUT</code> request is received that contains properties 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]].
+ [[!RFC7231]].
<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
information about which properties could not be
persisted.
@@ -709,7 +734,7 @@
its representation. <a title="LDP server">LDP servers</a> SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
to detect collisions. <a title="LDP server">LDP servers</a> MUST respond with status code 412
(Condition Failed) if <code>ETag</code>s fail to match when there are no other
- errors with the request [[!HTTP11]]. <a title="LDP server">LDP servers</a> that require conditional requests MUST respond with status code 428
+ errors with the request [[!RFC7232]]. <a title="LDP server">LDP servers</a> that require conditional requests MUST respond with status code 428
(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
</h2></section><!-- Was 4.5.2 / #ldpr-4_5_2 -->
@@ -721,7 +746,7 @@
<section id="ldpr-HTTP_DELETE">
<h2>HTTP DELETE</h2>
<p>
- Per [[HTTP11]], this HTTP method is optional and
+ Per [[!RFC7231]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
When a LDP server supports this method,
this specification imposes no new blanket requirements for LDPRs.
@@ -745,7 +770,7 @@
<section id="ldpr-HTTP_PATCH">
<h2>HTTP PATCH</h2>
<p>
- Per [[RFC5789]], this HTTP method is optional and
+ Per [[!RFC5789]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
When a LDP server supports this method,
this specification imposes the following new requirements for LDPRs.
@@ -853,7 +878,7 @@
it doesn’t change whether it understands the predicates or not, when
its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
- [[RFC5789]].
+ [[!RFC5789]].
</h2></section> <!-- Was 4.5.5 / #ldpr-ldpr-4_5_5 -->
<section id="ldpr-cli-can-hint"><h2 class="normal">
@@ -1404,7 +1429,7 @@
<section id="ldpc-HTTP_POST">
<h2>HTTP POST</h2>
<p>
- Per [[HTTP11]], this HTTP method is optional and
+ Per [[!RFC7231]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
When a LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
@@ -1525,7 +1550,7 @@
<section id="ldpc-HTTP_PUT">
<h2>HTTP PUT</h2>
<p>
- Per [[HTTP11]], this HTTP method is optional and
+ Per [[!RFC7231]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
When a LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
@@ -1550,7 +1575,7 @@
<section id="ldpc-HTTP_DELETE">
<h2>HTTP DELETE</h2>
<p>
- Per [[HTTP11]], this HTTP method is optional and
+ Per [[!RFC7231]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
When a LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
@@ -1562,7 +1587,7 @@
</h2>
<blockquote>
Non-normative note: The <a>LDP server</a> might perform additional actions,
- as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]].
+ as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[!RFC7231]].
For example, the server could remove membership triples referring to the deleted LDPR,
perform additional cleanup tasks for resources it knows are no longer referenced or have not
been accessed for some period of time, and so on.
@@ -1590,7 +1615,7 @@
<section id="ldpc-HTTP_PATCH">
<h2>HTTP PATCH</h2>
<p>
- Per [[HTTP11]], this HTTP method is optional and
+ Per [[!RFC5789]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
When a LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
@@ -1847,13 +1872,13 @@
<section id="specs-http" class="informative">
<h2>HTTP 1.1</h2>
-Reference: [[!HTTP11]]
+Reference: [[!RFC7230]], [[!RFC7231]], [[!RFC7232]]
<section id="ldp-http-other-representations"><h2 class="normal"><a title="LDP server">LDP servers</a> can support 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.
- HTTP content negotiation ([[HTTP11]] Section 12 - Content Negotiation) is used to select the format.
+ HTTP content negotiation ([[RFC7231]] Section 3.4 - Content Negotiation) is used to select the format.
</h2></section>
<section id="ldp-http-other-methods"><h2 class="normal">LDPRs can be created, updated and deleted using methods not defined in
@@ -1870,7 +1895,7 @@
</h2></section>
<section id="ldp-http-method-side-effects"><h2 class="normal"><a title="LDP server">LDP servers</a> can alter the state of other resources
- as a result of any HTTP request, especially when non-safe methods are used ([[HTTP11]] section 9.1).
+ as a result of any HTTP request, especially when non-safe methods are used ([[RFC7231]] section 4.2.1).
For example, it is acceptable for the server to
remove triples from other resources whose subject or object is the
deleted resource as the result of a successful HTTP <code>DELETE</code> request.
@@ -1886,7 +1911,7 @@
<section id="ldp-http-content-sniffing"><h2 class="normal">
When the <code>Content-Type</code> request header is absent from a request,
- <a title="LDP server">LDP servers</a> might infer the content type by inspecting the entity body contents [[HTTP11]].
+ <a title="LDP server">LDP servers</a> might infer the content type by inspecting the entity body contents ([[RFC7231]] section 3.1.1.5).
</h2></section>
</section>
@@ -1995,7 +2020,7 @@
</div>
<p>This specification introduces new parameters on the HTTP <code>Prefer</code> request header's
- <code>return=representation</code> preference [[!Prefer]], used optionally by clients to
+ <code>return=representation</code> preference [[!RFC7240]], used optionally by clients to
supply a hint to help the server form a response that is most appropriate to
the client's needs. The LDP-defined parameters suggest the portion(s) of a resource's state that the
client application is interested in and, if received, is likely to be
@@ -2009,11 +2034,11 @@
<p>
Non-normative note: LDP server implementers should carefully consider the effects of these
- preferences on caching, as described in section 2 of [[!Prefer]].
+ preferences on caching, as described in section 2 of [[!RFC7240]].
</p>
<p>
- Non-normative note: [[!Prefer]] recommends that server implementers include a
+ Non-normative note: [[!RFC7240]] recommends that server implementers include a
<code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
behavior with respect to honoring hints from the response content.
<a href="#prefer-examples">Examples</a> illustrates some cases where the header is unnecessary.
@@ -2029,13 +2054,13 @@
would like included in a representation.
The syntax for the <code>include</code> parameter of the
HTTP <code>Prefer</code> request header's
- <code>return=representation</code> preference [[!Prefer]] is:</h2>
+ <code>return=representation</code> preference [[!RFC7240]] is:</h2>
<blockquote>
<code>include-parameter = "include" *WSP "=" *WSP ldp-uri-list</code>
<p>
Where <code>WSP</code> is whitespace [[!RFC5234]], and
<code>ldp-uri-list</code> is a double-quoted blank-delimited unordered set of URIs whose ABNF is given below.
- The generic preference BNF [[!Prefer]] allows either a quoted string or a token as the value of a
+ The generic preference BNF [[!RFC7240]] allows either a quoted string or a token as the value of a
preference parameter; LDP assigns a meaning to the value only when it is a quoted string of
the form:
</p>
@@ -2052,7 +2077,7 @@
would like omitted from a representation.
The syntax for the <code>omit</code> parameter of the
HTTP <code>Prefer</code> request header's
- <code>return=representation</code> preference [[!Prefer]] is:</h2>
+ <code>return=representation</code> preference [[!RFC7240]] is:</h2>
<blockquote>
<code>omit-parameter = "omit" *WSP "=" *WSP ldp-uri-list</code>
<p>
@@ -2065,7 +2090,7 @@
When LDP servers receive a request with conflicting hints, this specification imposes
no requirements on their behavior. They are free to reject the request, process it
applying some subset of the hints, or anything else appropriate to the server.
- [[!Prefer]] suggests treating similar requests as though none of the conflicting
+ [[!RFC7240]] suggests treating similar requests as though none of the conflicting
preferences were specified.
</h2>
</section>
@@ -2219,7 +2244,7 @@
the header would still be required for the client to know that the <code>303</code> response entity
is a representation of the resource identified by the <code>Location</code> URI
instead of a short hypertext note (one with a hyperlink to
- the same URI reference provided in the <code>Location</code> header field [[HTTPBIS-SEMANTICS]]).
+ the same URI reference provided in the <code>Location</code> header field [[RFC7231]]).
</p>
<pre class="example">
@@ -2305,7 +2330,7 @@
<p>
The <code>209 Related Content</code> must be added to the permanent status code registry
maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
- (see [[HTTPBIS-SEMANTICS]], [[!RFC2817]]).
+ (see [[RFC7231]], [[!RFC2817]]).
</p>
<p>
Value: 209