Changeset 1604

Timestamp:

21/03/12 12:30:28 (10 years ago)

Author:

julian.reschke@…

Message:

replace a few instances of lowercase "must"

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (6 diffs)
• p1-messaging.xml (modified) (2 diffs)
• p2-semantics.html (modified) (7 diffs)
• p2-semantics.xml (modified) (3 diffs)
• p3-payload.html (modified) (6 diffs)
• p3-payload.xml (modified) (1 diff)
• p4-conditional.html (modified) (6 diffs)
• p4-conditional.xml (modified) (1 diff)
• p6-cache.html (modified) (6 diffs)
• p6-cache.xml (modified) (1 diff)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -460 +460 @@
   } 
   @bottom-center {
-       content: "Expires September 19, 2012"; 
+       content: "Expires September 22, 2012"; 
   } 
   @bottom-right {
@@ -502 +502 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-03-18">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-03-21">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -534 +534 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 19, 2012</td>
+               <td class="left">Expires: September 22, 2012</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">March 18, 2012</td>
+               <td class="right">March 21, 2012</td>
             </tr>
          </tbody>
@@ -572 +572 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 19, 2012.</p>
+      <p>This Internet-Draft will expire on September 22, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1538 +1538 @@
          received, provided that the header block was received intact.
       </p>
-      <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication must be given to the user that an
-         error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Response Cacheability">Section 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
+      <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication needs to be given to the user that
+         an error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Response Cacheability">Section 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
       </p>
       <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data
@@ -3016 +3016 @@
       </p>
       <p id="rfc.section.A.2.p.13">Change ABNF productions for header fields to only define the field value.</p>
-      <p id="rfc.section.A.2.p.14">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;6.1</a>)
+      <p id="rfc.section.A.2.p.14">Clarify exactly when close connection options have to be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;6.1</a>)
       </p>
       <p id="rfc.section.A.2.p.15">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.5</a>)

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -1780 +1780 @@
 <t>
    A user agent &MUST-NOT; render an incomplete response message body as if
-   it were complete (i.e., some indication must be given to the user that an
+   it were complete (i.e., some indication needs to be given to the user that an
    error occurred).  Cache requirements for incomplete responses are defined
    in &cache-incomplete;.
@@ -4894 +4894 @@
 </t>
 <t>
-  Clarify exactly when close connection options must be sent.
+  Clarify exactly when close connection options have to be sent.
   (<xref target="header.connection"/>)
 </t>

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

@@ -460 +460 @@
   } 
   @bottom-center {
-       content: "Expires September 13, 2012"; 
+       content: "Expires September 22, 2012"; 
   } 
   @bottom-right {
@@ -507 +507 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-03-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-03-21">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
@@ -538 +538 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 13, 2012</td>
+               <td class="left">Expires: September 22, 2012</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">March 12, 2012</td>
+               <td class="right">March 21, 2012</td>
             </tr>
          </tbody>
@@ -573 +573 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 13, 2012.</p>
+      <p>This Internet-Draft will expire on September 22, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1661 +1661 @@
          <li>1xx: Informational - Request received, continuing process</li>
          <li>2xx: Success - The action was successfully received, understood, and accepted</li>
-         <li>3xx: Redirection - Further action must be taken in order to complete the request</li>
+         <li>3xx: Redirection - Further action needs to be taken in order to complete the request</li>
          <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li>
          <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
@@ -2081 +2081 @@
       </p>
       <div class="note" id="rfc.section.7.5.4.p.3"> 
-         <p> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers might
+         <p> <b>Note:</b> The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might
             wish to simply refuse the connection.
          </p> 
@@ -3005 +3005 @@
       </p>
       <p id="rfc.section.A.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
-         must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
+         needs to be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
          was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;7.3.5</a>)
       </p>

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

@@ -1298 +1298 @@
     </t>
     <t>
-      3xx: Redirection - Further action must be taken in order to
+      3xx: Redirection - Further action needs to be taken in order to
         complete the request
     </t>
@@ -2105 +2105 @@
   <t>
     <x:h>Note:</x:h> The existence of the 503 status code does not imply that a
-    server must use it when becoming overloaded. Some servers might wish
+    server has to use it when becoming overloaded. Some servers might wish
     to simply refuse the connection.
   </t>
@@ -3703 +3703 @@
 <t>
   Deprecate 305 Use Proxy status code, because user agents did not implement it.
-  It used to indicate that the target resource must be accessed through the
+  It used to indicate that the target resource needs to be accessed through the
   proxy given by the Location field. The Location field gave the URI of the
   proxy. The recipient was expected to repeat this single request via the proxy.

draft-ietf-httpbis/latest/p3-payload.html

@@ -460 +460 @@
   } 
   @bottom-center {
-       content: "Expires September 13, 2012"; 
+       content: "Expires September 22, 2012"; 
   } 
   @bottom-right {
@@ -505 +505 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-03-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-03-21">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
@@ -531 +531 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 13, 2012</td>
+               <td class="left">Expires: September 22, 2012</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -540 +540 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 12, 2012</td>
+               <td class="right">March 21, 2012</td>
             </tr>
          </tbody>
@@ -568 +568 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 13, 2012.</p>
+      <p>This Internet-Draft will expire on September 22, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1313 +1313 @@
       <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
       <p id="rfc.section.6.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent
-         in the media type, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type
-         header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the identity of
-         its underlying media type.
+         in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the
+         Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the
+         identity of its underlying media type.
       </p>
       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>

draft-ietf-httpbis/latest/p3-payload.xml

@@ -1192 +1192 @@
    The "Content-Encoding" header field indicates what content-codings 
    have been applied to the representation beyond those inherent in the media
-   type, and thus what decoding mechanisms must be applied in order to obtain
+   type, and thus what decoding mechanisms have to be applied in order to obtain
    the media-type referenced by the Content-Type header field.
    Content-Encoding is primarily used to allow a representation to be

draft-ietf-httpbis/latest/p4-conditional.html

@@ -460 +460 @@
   } 
   @bottom-center {
-       content: "Expires September 13, 2012"; 
+       content: "Expires September 22, 2012"; 
   } 
   @bottom-right {
@@ -501 +501 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-03-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-03-21">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
@@ -527 +527 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 13, 2012</td>
+               <td class="left">Expires: September 22, 2012</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -536 +536 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 12, 2012</td>
+               <td class="right">March 21, 2012</td>
             </tr>
          </tbody>
@@ -566 +566 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 13, 2012.</p>
+      <p>This Internet-Draft will expire on September 22, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -948 +948 @@
 
 <em>...binary data...</em></pre><div class="note" id="rfc.section.2.3.3.p.7"> 
-         <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation must be distinct
+         <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation has to be distinct
             from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings
             (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags.

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -637 +637 @@
   <t>
     <x:h>Note:</x:h> Content codings are a property of the representation,
-    so therefore an entity-tag of an encoded representation must be distinct
+    so therefore an entity-tag of an encoded representation has to be distinct
     from an unencoded representation to prevent conflicts during cache updates
     and range requests.  In contrast, transfer codings (&transfer-codings;)

draft-ietf-httpbis/latest/p6-cache.html

@@ -463 +463 @@
   } 
   @bottom-center {
-       content: "Expires September 13, 2012"; 
+       content: "Expires September 22, 2012"; 
   } 
   @bottom-right {
@@ -505 +505 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-03-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-03-21">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -531 +531 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 13, 2012</td>
+               <td class="left">Expires: September 22, 2012</td>
                <td class="right">M. Nottingham, Editor</td>
             </tr>
@@ -548 +548 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 12, 2012</td>
+               <td class="right">March 21, 2012</td>
             </tr>
          </tbody>
@@ -578 +578 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 13, 2012.</p>
+      <p>This Internet-Draft will expire on September 22, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -924 +924 @@
       <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
       </p>
-      <p id="rfc.section.2.2.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 6.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to the origin server; i.e., a cache must not generate a reply to such a request before having forwarded the request and
-         having received a corresponding response.
+      <p id="rfc.section.2.2.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 6.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
+         and having received a corresponding response.
       </p>
       <p id="rfc.section.2.2.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.6</a>.

draft-ietf-httpbis/latest/p6-cache.xml

@@ -569 +569 @@
 <t>
    A cache &MUST; write through requests with methods that are unsafe 
-   (&safe-methods;) to the origin server; i.e., a cache must not generate 
+   (&safe-methods;) to the origin server; i.e., a cache is not allowed to generate 
    a reply to such a request before having forwarded the request and having 
    received a corresponding response.