Changeset 1684

Timestamp:

Jun 22, 2012, 12:12:17 AM (7 years ago)

Author:

julian.reschke@…

Message:

Replace "may" by "might" (see #362)

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (5 diffs)
• p2-semantics.xml (modified) (1 diff)
• p4-conditional.html (modified) (6 diffs)
• p4-conditional.xml (modified) (1 diff)
• p5-range.html (modified) (6 diffs)
• p5-range.xml (modified) (1 diff)
• p6-cache.html (modified) (6 diffs)
• p6-cache.xml (modified) (1 diff)
• p7-auth.html (modified) (5 diffs)
• p7-auth.xml (modified) (1 diff)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires December 23, 2012"; 
+       content: "Expires December 24, 2012"; 
   } 
   @bottom-right {
@@ -497 +497 @@
       <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-06-21">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
       <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. Furthermore, it defines HTTP message content, metadata, and content negotiation.">
@@ -528 +528 @@
             </tr>
             <tr>
-               <td class="left">Expires: December 23, 2012</td>
+               <td class="left">Expires: December 24, 2012</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">June 21, 2012</td>
+               <td class="right">June 22, 2012</td>
             </tr>
          </tbody>
@@ -563 +563 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 23, 2012.</p>
+      <p>This Internet-Draft will expire on December 24, 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>
@@ -858 +858 @@
       <p id="rfc.section.1.2.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
-         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
-         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
-         error recovery could lead to dangerous consequences.
+         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
+         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
+         of error recovery could lead to dangerous consequences.
       </p>
       <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

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

@@ -305 +305 @@
    specific error handling mechanisms, except in cases where it has direct
    impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser may wish to
+   different error handling strategies; for example, a Web browser might wish to
    transparently recover from a response where the Location header field
    doesn't parse according to the ABNF, whereby in a systems control protocol

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires December 23, 2012"; 
+       content: "Expires December 24, 2012"; 
   } 
   @bottom-right {
@@ -490 +490 @@
       <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-06-21">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
       <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.">
@@ -516 +516 @@
             </tr>
             <tr>
-               <td class="left">Expires: December 23, 2012</td>
+               <td class="left">Expires: December 24, 2012</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -525 +525 @@
             <tr>
                <td class="left"></td>
-               <td class="right">June 21, 2012</td>
+               <td class="right">June 22, 2012</td>
             </tr>
          </tbody>
@@ -555 +555 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 23, 2012.</p>
+      <p>This Internet-Draft will expire on December 24, 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>
@@ -660 +660 @@
       <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
-         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
-         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
-         error recovery could lead to dangerous consequences.
+         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
+         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
+         of error recovery could lead to dangerous consequences.
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

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

@@ -197 +197 @@
    specific error handling mechanisms, except in cases where it has direct
    impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser may wish to
+   different error handling strategies; for example, a Web browser might wish to
    transparently recover from a response where the Location header field
    doesn't parse according to the ABNF, whereby in a systems control protocol

draft-ietf-httpbis/latest/p5-range.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires December 23, 2012"; 
+       content: "Expires December 24, 2012"; 
   } 
   @bottom-right {
@@ -492 +492 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-06-21">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
       <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 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
@@ -518 +518 @@
             </tr>
             <tr>
-               <td class="left">Expires: December 23, 2012</td>
+               <td class="left">Expires: December 24, 2012</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -527 +527 @@
             <tr>
                <td class="left"></td>
-               <td class="right">June 21, 2012</td>
+               <td class="right">June 22, 2012</td>
             </tr>
          </tbody>
@@ -555 +555 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 23, 2012.</p>
+      <p>This Internet-Draft will expire on December 24, 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>
@@ -682 +682 @@
       <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
-         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
-         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
-         error recovery could lead to dangerous consequences.
+         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
+         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
+         of error recovery could lead to dangerous consequences.
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

draft-ietf-httpbis/latest/p5-range.xml

@@ -187 +187 @@
    specific error handling mechanisms, except in cases where it has direct
    impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser may wish to
+   different error handling strategies; for example, a Web browser might wish to
    transparently recover from a response where the Location header field
    doesn't parse according to the ABNF, whereby in a systems control protocol

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

@@ -452 +452 @@
   } 
   @bottom-center {
-       content: "Expires December 23, 2012"; 
+       content: "Expires December 24, 2012"; 
   } 
   @bottom-right {
@@ -494 +494 @@
       <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-06-21">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
       <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.">
@@ -520 +520 @@
             </tr>
             <tr>
-               <td class="left">Expires: December 23, 2012</td>
+               <td class="left">Expires: December 24, 2012</td>
                <td class="right">M. Nottingham, Editor</td>
             </tr>
@@ -537 +537 @@
             <tr>
                <td class="left"></td>
-               <td class="right">June 21, 2012</td>
+               <td class="right">June 22, 2012</td>
             </tr>
          </tbody>
@@ -567 +567 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 23, 2012.</p>
+      <p>This Internet-Draft will expire on December 24, 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>
@@ -774 +774 @@
       <p id="rfc.section.1.3.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
-         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
-         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
-         error recovery could lead to dangerous consequences.
+         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
+         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
+         of error recovery could lead to dangerous consequences.
       </p>
       <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

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

@@ -331 +331 @@
    specific error handling mechanisms, except in cases where it has direct
    impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser may wish to
+   different error handling strategies; for example, a Web browser might wish to
    transparently recover from a response where the Location header field
    doesn't parse according to the ABNF, whereby in a systems control protocol

draft-ietf-httpbis/latest/p7-auth.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires December 23, 2012"; 
+       content: "Expires December 24, 2012"; 
   } 
   @bottom-right {
@@ -489 +489 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-06-21">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
       <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, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
@@ -520 +520 @@
             </tr>
             <tr>
-               <td class="left">Expires: December 23, 2012</td>
+               <td class="left">Expires: December 24, 2012</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">June 21, 2012</td>
+               <td class="right">June 22, 2012</td>
             </tr>
          </tbody>
@@ -553 +553 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 23, 2012.</p>
+      <p>This Internet-Draft will expire on December 24, 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>
@@ -647 +647 @@
       <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
-         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
-         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
-         error recovery could lead to dangerous consequences.
+         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
+         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
+         of error recovery could lead to dangerous consequences.
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

draft-ietf-httpbis/latest/p7-auth.xml

@@ -172 +172 @@
    specific error handling mechanisms, except in cases where it has direct
    impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser may wish to
+   different error handling strategies; for example, a Web browser might wish to
    transparently recover from a response where the Location header field
    doesn't parse according to the ABNF, whereby in a systems control protocol