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

Timestamp:

01/11/12 18:46:15 (10 years ago)

Author:

julian.reschke@…

Message:

editorial improvements (ack Dan W.)

File:

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

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

@@ -656 +656 @@
    Language tags are defined in <xref target="language.tags"/>. The primary purpose of
    Content-Language is to allow a user to identify and differentiate
-   representations according to the user's own preferred language. Thus, if the
+   representations according to the users' own preferred language. Thus, if the
    content is intended only for a Danish-literate audience, the
    appropriate field is
@@ -1002 +1002 @@
    but it cannot expect responses to always honor them. For example, the origin
    server might not implement proactive negotiation, or it might decide that
-   sending a response that doesn't conform to them is better than sending a <x:ref>406
-   (Not Acceptable)</x:ref> response.
+   sending a response that doesn't conform to the user agent's preferences is
+   better than sending a <x:ref>406 (Not Acceptable)</x:ref> response.
 </t>
 <t>
@@ -2315 +2315 @@
 <t>
    would mean: "I prefer Danish, but will accept British English and
-   other types of English".
-   (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
+   other types of English". (See also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
 </t>
 <t>
@@ -2513 +2512 @@
 <section title="Response Status Codes" anchor="status.codes">
 <t>
-   The status-code element is a 3-digit integer result code of the attempt to
-   understand and satisfy the request.
+   The status-code element is a 3-digit integer code giving the result of the
+   attempt to understand and satisfy the request.
 </t>
 <t>
@@ -2537 +2536 @@
   <list style="symbols">
     <t>
-      <x:ref>1xx (Informational)</x:ref>: Request received, continuing process
+      <x:ref>1xx (Informational)</x:ref>: The request was received, continuing
+      process
     </t>
     <t>
-      <x:ref>2xx (Successful)</x:ref>: The action was successfully received,
-        understood, and accepted
+      <x:ref>2xx (Successful)</x:ref>: The request was successfully received,
+      understood, and accepted
     </t>
     <t>
       <x:ref>3xx (Redirection)</x:ref>: Further action needs to be taken in order to
-        complete the request
+      complete the request
     </t>
     <t>
       <x:ref>4xx (Client Error)</x:ref>: The request contains bad syntax or cannot
-        be fulfilled
+      be fulfilled
     </t>
     <t>
       <x:ref>5xx (Server Error)</x:ref>: The server failed to fulfill an apparently
-        valid request
+      valid request
     </t>
   </list>
@@ -2610 +2610 @@
   <c>414</c> <c>URI Too Long</c> <c><xref target="status.414"/></c>
   <c>415</c> <c>Unsupported Media Type</c> <c><xref target="status.415"/></c>
-  <c>416</c> <c>Requested range not satisfiable</c> <c anchor="status.416">&status-416;</c>
+  <c>416</c> <c>Requested Range Not Satisfiable</c> <c anchor="status.416">&status-416;</c>
   <c>417</c> <c>Expectation Failed</c> <c><xref target="status.417"/></c>
   <c>426</c> <c>Upgrade Required</c> <c><xref target="status.426"/></c>
@@ -2746 +2746 @@
    The origin server &MUST; create the resource(s) before returning the 201 status
    code. If the action cannot be carried out immediately, the server &SHOULD;
-   respond with <x:ref>202 (Accepted)</x:ref> response instead.
+   respond with a <x:ref>202 (Accepted)</x:ref> response instead.
 </t>
 <t>
@@ -4411 +4411 @@
     <x:lt><t>Whether it is appropriate to list the field-name in the
     <x:ref>Connection</x:ref> header field (i.e., if the header field is to
-    be hop-by-hop, see &header-connection;).</t></x:lt>
+    be hop-by-hop; see &header-connection;).</t></x:lt>
     <x:lt><t>Under what conditions intermediaries are allowed to modify the header
     field's value, insert or delete it.</t></x:lt>
@@ -5653 +5653 @@
 <t>
   Remove base URI setting semantics for "<x:ref>Content-Location</x:ref>" due to
-  poor implementation support, which was caused by too many broken servers emitting
+  poor implementation support (which was caused by too many broken servers emitting
   bogus Content-Location header fields, and also the potentially undesirable effect
-  of potentially breaking relative links in content-negotiated resources.
+  of potentially breaking relative links in content-negotiated resources).
   (<xref target="header.content-location"/>)
 </t>