Changeset 2098 for draft-ietf-httpbis/latest/p2-semantics.xml

Timestamp:

07/01/13 09:02:41 (9 years ago)

Author:

fielding@…

Message:

(editorial) move notes on 406 to 300 and include a reference to Link; miscellaneous proofreading edits

File:

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

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

@@ -1654 +1654 @@
    The response payload, if any, might also describe the communication options
    in a machine or human-readable representation. A standard format for such a
-   payload is not defined by this specification, but might be defined by
+   representation is not defined by this specification, but might be defined by
    future extensions to HTTP.
    A server &MUST; generate a <x:ref>Content-Length</x:ref> field with a value
@@ -2516 +2516 @@
    For example, if an unrecognized status code of 471 is received by a client,
    the client can assume that there was something wrong with its request and
-   treat the response as if it had received a 400 status code. If the response
-   includes a message body, it will usually include a representation that
-   explains the response status.
+   treat the response as if it had received a 400 status code. The response
+   message will usually contain a representation that explains the status.
 </t>
 <t>
@@ -2700 +2699 @@
 <t>
    The <x:dfn>200 (OK)</x:dfn> status code indicates that the request has
-   succeeded. The payload sent in the response
-   is dependent on the method used in the request, for example:
+   succeeded. The meaning of a payload sent in the response depends on the
+   request method, as follows:
   <list style="hanging">
     <t hangText="GET">
@@ -2707 +2706 @@
     </t>
     <t hangText="HEAD">
-      the same representation as GET, except without the message body;
+      the same representation as GET, but without the representation data;
     </t>
     <t hangText="POST">
@@ -2754 +2753 @@
    completed. The request might or might not eventually be acted upon, as it
    might be disallowed when processing actually takes place. There is no
-   facility for re-sending a status code from an asynchronous operation such
-   as this.
+   facility in HTTP for re-sending a status code from an asynchronous
+   operation.
 </t>
 <t>
@@ -2763 +2762 @@
    requiring that the user agent's connection to the server persist
    until the process is completed. The representation sent with this
-   response ought to describe the request's current status
-   and either a pointer to a status monitor or some estimate of when the
-   user can expect the request to be fulfilled.
+   response ought to describe the request's current status and point to
+   (or embed) a status monitor that can provide the user with an estimate of
+   when the request will be fulfilled.
 </t>
 </section>
@@ -2796 +2795 @@
    has successfully fulfilled the request and that there is no additional
    content to send in the response payload body. Metadata in the response
-   header fields refer to the <x:ref>target resource</x:ref> and its current representation
-   after the requested action.
+   header fields refer to the <x:ref>target resource</x:ref> and its
+   selected representation after the requested action was applied.
 </t>
 <t>
@@ -2822 +2821 @@
 </t>
 <t>
-   A 204 response does not include a message body, and thus is always
-   terminated by the first empty line after the header fields.
+   A 204 response is terminated by the first empty line after the header
+   fields because it cannot contain a message body.
 </t>
 </section>
@@ -2941 +2940 @@
 <t>
    The <x:dfn>300 (Multiple Choices)</x:dfn> status code indicates that the
-   <x:ref>target resource</x:ref> has more than one representation, each with its own more
-   specific identifier, and information about the alternatives is being
-   provided so that the user (or user agent) can select a preferred
+   <x:ref>target resource</x:ref> has more than one representation, each with
+   its own more specific identifier, and information about the alternatives is
+   being provided so that the user (or user agent) can select a preferred
    representation by redirecting its request to one or more of those
    identifiers. In other words, the server desires that the user agent engage
    in reactive negotiation to select the most appropriate representation(s)
    for its needs (&content-negotiation;).
+</t>
+<t>
+   If the server has a preferred choice, the server &SHOULD; generate a
+   <x:ref>Location</x:ref> header field containing a preferred choice's URI
+   reference. The user agent &MAY; use the Location field value for automatic
+   redirection.
 </t>
 <t>
@@ -2958 +2963 @@
 </t>
 <t>
-   If the server has a preferred choice, the server &SHOULD; generate a
-   <x:ref>Location</x:ref> header field containing a preferred choice's URI
-   reference. The user agent &MAY; use the Location field value for automatic
-   redirection.
-</t>
-<t>
    Caches &MAY; use a heuristic (see &p6-heuristic;) to determine 
    freshness for 300 responses.
 </t>
-
+<x:note>
+  <t>
+   &Note; The original proposal for 300 defined the URI header field as
+   providing a list of alternative representations, such that it would be
+   usable for 200, 300, and 406 responses and be transferred in responses to
+   the HEAD method. However, lack of deployment and disagreement over syntax
+   led to both URI and Alternates (a subsequent proposal) being dropped from
+   this specification. It is possible to communicate the list using a set of
+   Link header fields <xref target="RFC5988"/>, each with a relationship of
+   "alternate", though deployment is a chicken-and-egg problem.
+  </t>
+</x:note>
 </section>
 
@@ -3221 +3231 @@
    A user agent &MAY; automatically select the most appropriate choice from
    that list. However, this specification does not define any standard for
-   such automatic selection. [The original proposal for 406 defined the
-   Alternates header field as providing a list of alternative representations,
-   such that it would be available for responses to the HEAD method, but lack
-   of deployment led to Alternates being dropped from the specification.]
+   such automatic selection, as described in <xref target="status.300"/>.
 </t>
 </section>
@@ -5516 +5523 @@
 </reference>
 
+<reference anchor='RFC5988'>
+  <front>
+    <title>Web Linking</title>
+    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
+    <organization /></author>
+    <date year='2010' month='October' />
+  </front>
+  <seriesInfo name='RFC' value='5988' />
+</reference>
+
 <reference anchor="RFC6265">
   <front>