Changeset 2090 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

05/01/13 13:09:32 (9 years ago)

Author:

fielding@…

Message:

(editorial) more consistency regarding representation

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (7 diffs)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -806 +806 @@
          This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
       </p>
-      <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section&nbsp;2</a>), regardless of its type, nature, or implementation, and for transferring content in message payloads in the form of a representation
-         (<a href="#representations" title="Representations">Section&nbsp;3</a>).
+      <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section&nbsp;2</a>), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (<a href="#representations" title="Representations">Section&nbsp;3</a>).
       </p>
       <p id="rfc.section.1.p.3">HTTP semantics include the intentions defined by each request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>), extensions to those semantics that might be described in request header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>), the meaning of status codes to indicate a machine-readable response (<a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>), and the meaning of other control data and resource metadata that might be given in response header fields (<a href="#response.header.fields" title="Response Header Fields">Section&nbsp;7</a>).
@@ -959 +958 @@
       <div id="rfc.figure.u.6"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
 </pre><p id="rfc.section.3.1.1.5.p.5">A sender that generates a message containing a payload body <em class="bcp14">SHOULD</em> generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown
-         to the sender. If a Content-Type header field is not present, recipients <em class="bcp14">MAY</em> either assume a media type of "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the representation data to determine its type.
+         to the sender. If a Content-Type header field is not present, recipients <em class="bcp14">MAY</em> either assume a media type of "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the data to determine its type.
       </p>
       <p id="rfc.section.3.1.1.5.p.6">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
@@ -1108 +1107 @@
       </p>
       <p id="rfc.section.3.1.4.2.p.5">If Content-Location is included in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response message and its field-value refers to a URI that differs from the effective request URI, then the origin server claims
-         that the field-value is an identifier for the payload's representation. Such a claim can only be trusted if both identifiers
-         share the same resource owner, which cannot be programmatically determined via HTTP. 
+         that the field-value is an identifier for the representation enclosed as the payload. Such a claim can only be trusted if
+         both identifiers share the same resource owner, which cannot be programmatically determined via HTTP. 
       </p>
       <ul>
@@ -1131 +1130 @@
       </p>
       <p id="rfc.section.3.1.4.2.p.8">For example, if a client makes a PUT request on a negotiated resource and the origin server accepts that PUT (without redirection),
-         then the new set of values for that resource is expected to be consistent with the one representation supplied in that PUT;
-         the Content-Location cannot be used as a form of reverse content selection identifier to update only one of the negotiated
-         representations. If the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location
-         URI.
+         then the new state of that resource is expected to be consistent with the one representation supplied in that PUT; the Content-Location
+         cannot be used as a form of reverse content selection identifier to update only one of the negotiated representations. If
+         the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location URI.
       </p>
       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
@@ -1155 +1153 @@
          an HTML form.
       </p>
-      <p id="rfc.section.3.3.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) contains a representation of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
+      <p id="rfc.section.3.3.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) ought to contain a representation of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
          current representation of the target resource after applying the processing. Response messages with an error status code usually
-         contain a representation that describes the error and what next steps are suggested for resolving it.
+         contain a representation of the error condition, such that it describes the error state and what next steps are suggested
+         for resolving it.
       </p>
       <p id="rfc.section.3.3.p.5">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload
@@ -1187 +1186 @@
       </div>
       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2>
-      <p id="rfc.section.3.4.p.1">When responses convey a representation, whether indicating a success or an error, the origin server often has different ways
-         of representing that information; for example, in different formats, languages, or encodings. Likewise, different users or
-         user agents might have differing capabilities, characteristics, or preferences that could influence which representation,
+      <p id="rfc.section.3.4.p.1">When responses convey payload information, whether indicating a success or an error, the origin server often has different
+         ways of representing that information; for example, in different formats, languages, or encodings. Likewise, different users
+         or user agents might have differing capabilities, characteristics, or preferences that could influence which representation,
          among those available, would be best to deliver. For this reason, HTTP provides mechanisms for <a href="#content.negotiation" class="smpl">content negotiation</a>.
       </p>
@@ -1409 +1408 @@
       <div id="rfc.iref.h.1"></div>
       <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
-         representation implied by the request without transferring the representation data. This method is often used for testing
-         hypertext links for validity, accessibility, and recent modification.
+         selected representation without transferring the representation data. This method is often used for testing hypertext links
+         for validity, accessibility, and recent modification.
       </p>
       <p id="rfc.section.4.3.2.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.