Changeset 2347

Timestamp:

06/08/13 12:49:31 (9 years ago)

Author:

mnot@…

Message:

Start to work on #450; all done except for intro rewrite and moving 5.3 to a subsection of 3.4.1.

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (14 diffs)

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

@@ -263 +263 @@
   <x:anchor-alias value="target resource"/>
 <t>
-   The target of each HTTP request is called a resource. 
+   The target of a HTTP request is called a resource. 
    HTTP does not limit the nature of a resource; it merely
    defines an interface that might be used to interact with resources.
@@ -333 +333 @@
 </t>
 <t>
-   The following header fields are defined to convey representation metadata:
+   The following header fields convey representation metadata:
 </t>
 <texttable align="left">
@@ -345 +345 @@
 </texttable>
 
-<section title="Processing the Data" anchor="data.type">
+<section title="Processing Representation Data" anchor="data.type">
 
 <section title="Media Type" anchor="media.type">
@@ -543 +543 @@
    transformed without losing the identity of its underlying media type
    and without loss of information. Frequently, the representation is stored
-   in coded form, transmitted directly, and only decoded by the recipient.
+   in coded form, transmitted directly, and only decoded by the final recipient.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
@@ -729 +729 @@
          resource identified by the Content-Location field-value. However,
          such an assertion cannot be trusted unless it can be verified by
-         other means (not defined by HTTP). The information might still be
+         other means (not defined by this document). The information might still be
          useful for revision history links.</t>
       <t>Otherwise, the payload is unidentified.</t>
@@ -758 +758 @@
          representation of the resource identified by the Content-Location
          field-value. However, such an assertion cannot be trusted unless
-         it can be verified by other means (not defined by HTTP).</t>
+         it can be verified by other means (not defined by this document).</t>
       <t>Otherwise, the payload is unidentified.</t>
    </list>
@@ -950 +950 @@
 </t>
 <t>
-   Note that, in all cases, the supplier of representations to the origin
-   server determines which representations might be considered to be the
-   "same information".
+   Note that, in all cases, the resource determines which representations might
+   be considered to be the "same information".
 </t>
 
@@ -960 +959 @@
 <t>
    When content negotiation preferences are sent by the user agent in a
-   request in order to encourage an algorithm located at the server to
+   request to encourage an algorithm located at the server to
    select the preferred representation, it is called
    <x:dfn>proactive negotiation</x:dfn>
@@ -1047 +1046 @@
 </t>
 <t>
+  Reactive negotiation can also be supported in successful responses (e.g.,
+  <x:ref>200 (OK)</x:ref> responses) if the payload format allows it.
+</t>
+<t>
    Reactive negotiation is advantageous when the response would vary
    over commonly-used dimensions (such as type, language, or encoding),
@@ -1076 +1079 @@
    fields when present in a request (<xref target="request.header.fields"/>)
    if those additional semantics do not conflict with the method.
+</t>
+<t>
+   For example, a client can send conditional request header fields
+   (<xref target="request.conditionals"/>) to make the requested
+   action conditional on the current state of the target resource
+   (<xref target="Part4"/>).
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="method"/>
@@ -1154 +1163 @@
    with the <x:ref>405 (Method Not Allowed)</x:ref> status code.
 </t>
-<t>
-   A client can send conditional request header fields
-   (<xref target="request.conditionals"/>) to make the requested
-   action conditional on the current state of the target resource
-   (<xref target="Part4"/>).
-</t>
 </section>
 
@@ -1570 +1573 @@
 <t>
    If a DELETE method is successfully applied, the origin server &SHOULD; send
-   a <x:ref>202 (Accepted)</x:ref> status code if the action seems okay but
+   a <x:ref>202 (Accepted)</x:ref> status code if the action will likely succeed but
    has not yet been enacted,
    a <x:ref>204 (No Content)</x:ref> status code if the action has been
@@ -1677 +1680 @@
   <iref primary="true" item="OPTIONS method" x:for-anchor=""/>
 <t>
-   The OPTIONS method requests information about the
-   communication options available on the request/response chain
-   identified by the effective request URI. This method allows a client to
-   determine the options and/or requirements associated with a resource,
-   or the capabilities of a server, without implying a resource action.
+   The OPTIONS method requests information about the communication options
+   available for the target resource, either at the origin server or an
+   intervening intermediary. This method allows a client to determine the
+   options and/or requirements associated with a resource, or the capabilities
+   of a server, without implying a resource action.
 </t>
 <t>
@@ -3393 +3396 @@
 <t>
    The <x:dfn>409 (Conflict)</x:dfn> status code indicates that the request
-   could not be completed due to a conflict with the current state of the
+   could not be completed due to a conflict with the current state of the target
    resource. This code is used in situations where the user might be able to
    resolve the conflict and resubmit the request. The server &SHOULD; generate