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

Timestamp:

Nov 1, 2012, 11:46:15 AM (7 years ago)

Author:

julian.reschke@…

Message:

editorial improvements (ack Dan W.)

File:

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

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

@@ -1048 +1048 @@
       <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.13"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
 </pre><p id="rfc.section.3.1.3.2.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;3.1.3.1</a>. 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 content is intended only for a Danish-literate audience, the appropriate field
+         users' own preferred language. Thus, if the content is intended only for a Danish-literate audience, the appropriate field
          is
       </p>
@@ -1242 +1242 @@
       <p id="rfc.section.3.4.1.p.4">Proactive negotiation allows the user agent to specify its preferences, 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 <a href="#status.406" class="smpl">406
-            (Not Acceptable)</a> response.
+         doesn't conform to the user agent's preferences is better than sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response.
       </p>
       <p id="rfc.section.3.4.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities
@@ -1993 +1992 @@
       </p>
       <div id="rfc.figure.u.34"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
-</pre><p id="rfc.section.6.3.5.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
+</pre><p id="rfc.section.6.3.5.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (See also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
       </p>
       <p id="rfc.section.6.3.5.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
@@ -2124 +2123 @@
       <div id="rfc.figure.u.40"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
 </pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="status.codes" href="#status.codes">Response Status Codes</a></h1>
-      <p id="rfc.section.7.p.1">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request.</p>
+      <p id="rfc.section.7.p.1">The status-code element is a 3-digit integer code giving the result of the attempt to understand and satisfy the request.</p>
       <p id="rfc.section.7.p.2">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes,
          though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent
@@ -2135 +2134 @@
       </p>
       <ul>
-         <li> <a href="#status.1xx" class="smpl">1xx (Informational)</a>: Request received, continuing process
-         </li>
-         <li> <a href="#status.2xx" class="smpl">2xx (Successful)</a>: The action was successfully received, understood, and accepted
+         <li> <a href="#status.1xx" class="smpl">1xx (Informational)</a>: The request was received, continuing process
+         </li>
+         <li> <a href="#status.2xx" class="smpl">2xx (Successful)</a>: The request was successfully received, understood, and accepted
          </li>
          <li> <a href="#status.3xx" class="smpl">3xx (Redirection)</a>: Further action needs to be taken in order to complete the request
@@ -2324 +2323 @@
                <tr>
                   <td class="left">416</td>
-                  <td class="left">Requested range not satisfiable</td>
+                  <td class="left">Requested Range Not Satisfiable</td>
                   <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
                </tr>
@@ -2426 +2425 @@
          (e.g., in the case of a response to a PUT request).
       </p>
-      <p id="rfc.section.7.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
+      <p id="rfc.section.7.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
       </p>
       <p id="rfc.section.7.3.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by
@@ -3507 +3506 @@
          </li>
          <li>
-            <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
+            <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop; see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
             </p>
          </li>
@@ -4088 +4087 @@
       </p>
       <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
-      <p id="rfc.section.C.p.1">Remove base URI setting semantics for "<a href="#header.content-location" class="smpl">Content-Location</a>" due to 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. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4.2</a>)
+      <p id="rfc.section.C.p.1">Remove base URI setting semantics for "<a href="#header.content-location" class="smpl">Content-Location</a>" due to 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). (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4.2</a>)
       </p>
       <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section&nbsp;5.3.3</a>)