Changeset 1684


Ignore:
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:
10 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1683 r1684  
    449449  }
    450450  @bottom-center {
    451        content: "Expires December 23, 2012";
     451       content: "Expires December 24, 2012";
    452452  }
    453453  @bottom-right {
     
    497497      <meta name="dct.creator" content="Reschke, J. F.">
    498498      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    499       <meta name="dct.issued" scheme="ISO8601" content="2012-06-21">
     499      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
    500500      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    501501      <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.">
     
    528528            </tr>
    529529            <tr>
    530                <td class="left">Expires: December 23, 2012</td>
     530               <td class="left">Expires: December 24, 2012</td>
    531531               <td class="right">greenbytes</td>
    532532            </tr>
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">June 21, 2012</td>
     535               <td class="right">June 22, 2012</td>
    536536            </tr>
    537537         </tbody>
     
    563563         in progress”.
    564564      </p>
    565       <p>This Internet-Draft will expire on December 23, 2012.</p>
     565      <p>This Internet-Draft will expire on December 24, 2012.</p>
    566566      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    567567      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    858858      <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
    859859         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    860          different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
    861          Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
    862          error recovery could lead to dangerous consequences.
     860         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
     861         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
     862         of error recovery could lead to dangerous consequences.
    863863      </p>
    864864      <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

    r1683 r1684  
    305305   specific error handling mechanisms, except in cases where it has direct
    306306   impact on security. This is because different uses of the protocol require
    307    different error handling strategies; for example, a Web browser may wish to
     307   different error handling strategies; for example, a Web browser might wish to
    308308   transparently recover from a response where the Location header field
    309309   doesn't parse according to the ABNF, whereby in a systems control protocol
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1682 r1684  
    449449  }
    450450  @bottom-center {
    451        content: "Expires December 23, 2012";
     451       content: "Expires December 24, 2012";
    452452  }
    453453  @bottom-right {
     
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2012-06-21">
     492      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    494494      <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.">
     
    516516            </tr>
    517517            <tr>
    518                <td class="left">Expires: December 23, 2012</td>
     518               <td class="left">Expires: December 24, 2012</td>
    519519               <td class="right">J. Reschke, Editor</td>
    520520            </tr>
     
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">June 21, 2012</td>
     527               <td class="right">June 22, 2012</td>
    528528            </tr>
    529529         </tbody>
     
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on December 23, 2012.</p>
     557      <p>This Internet-Draft will expire on December 24, 2012.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    660660      <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
    661661         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    662          different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
    663          Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
    664          error recovery could lead to dangerous consequences.
     662         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
     663         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
     664         of error recovery could lead to dangerous consequences.
    665665      </p>
    666666      <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

    r1682 r1684  
    197197   specific error handling mechanisms, except in cases where it has direct
    198198   impact on security. This is because different uses of the protocol require
    199    different error handling strategies; for example, a Web browser may wish to
     199   different error handling strategies; for example, a Web browser might wish to
    200200   transparently recover from a response where the Location header field
    201201   doesn't parse according to the ABNF, whereby in a systems control protocol
  • draft-ietf-httpbis/latest/p5-range.html

    r1682 r1684  
    449449  }
    450450  @bottom-center {
    451        content: "Expires December 23, 2012";
     451       content: "Expires December 24, 2012";
    452452  }
    453453  @bottom-right {
     
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-06-21">
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    496496      <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.">
     
    518518            </tr>
    519519            <tr>
    520                <td class="left">Expires: December 23, 2012</td>
     520               <td class="left">Expires: December 24, 2012</td>
    521521               <td class="right">J. Reschke, Editor</td>
    522522            </tr>
     
    527527            <tr>
    528528               <td class="left"></td>
    529                <td class="right">June 21, 2012</td>
     529               <td class="right">June 22, 2012</td>
    530530            </tr>
    531531         </tbody>
     
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on December 23, 2012.</p>
     557      <p>This Internet-Draft will expire on December 24, 2012.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    682682      <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
    683683         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    684          different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
    685          Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
    686          error recovery could lead to dangerous consequences.
     684         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
     685         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
     686         of error recovery could lead to dangerous consequences.
    687687      </p>
    688688      <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

    r1682 r1684  
    187187   specific error handling mechanisms, except in cases where it has direct
    188188   impact on security. This is because different uses of the protocol require
    189    different error handling strategies; for example, a Web browser may wish to
     189   different error handling strategies; for example, a Web browser might wish to
    190190   transparently recover from a response where the Location header field
    191191   doesn't parse according to the ABNF, whereby in a systems control protocol
  • draft-ietf-httpbis/latest/p6-cache.html

    r1682 r1684  
    452452  }
    453453  @bottom-center {
    454        content: "Expires December 23, 2012";
     454       content: "Expires December 24, 2012";
    455455  }
    456456  @bottom-right {
     
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    496       <meta name="dct.issued" scheme="ISO8601" content="2012-06-21">
     496      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <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.">
     
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: December 23, 2012</td>
     522               <td class="left">Expires: December 24, 2012</td>
    523523               <td class="right">M. Nottingham, Editor</td>
    524524            </tr>
     
    537537            <tr>
    538538               <td class="left"></td>
    539                <td class="right">June 21, 2012</td>
     539               <td class="right">June 22, 2012</td>
    540540            </tr>
    541541         </tbody>
     
    567567         in progress”.
    568568      </p>
    569       <p>This Internet-Draft will expire on December 23, 2012.</p>
     569      <p>This Internet-Draft will expire on December 24, 2012.</p>
    570570      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    571571      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    774774      <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
    775775         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    776          different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
    777          Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
    778          error recovery could lead to dangerous consequences.
     776         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
     777         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
     778         of error recovery could lead to dangerous consequences.
    779779      </p>
    780780      <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

    r1682 r1684  
    331331   specific error handling mechanisms, except in cases where it has direct
    332332   impact on security. This is because different uses of the protocol require
    333    different error handling strategies; for example, a Web browser may wish to
     333   different error handling strategies; for example, a Web browser might wish to
    334334   transparently recover from a response where the Location header field
    335335   doesn't parse according to the ABNF, whereby in a systems control protocol
  • draft-ietf-httpbis/latest/p7-auth.html

    r1682 r1684  
    449449  }
    450450  @bottom-center {
    451        content: "Expires December 23, 2012";
     451       content: "Expires December 24, 2012";
    452452  }
    453453  @bottom-right {
     
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2012-06-21">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-06-22">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <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.">
     
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: December 23, 2012</td>
     522               <td class="left">Expires: December 24, 2012</td>
    523523               <td class="right">greenbytes</td>
    524524            </tr>
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">June 21, 2012</td>
     527               <td class="right">June 22, 2012</td>
    528528            </tr>
    529529         </tbody>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on December 23, 2012.</p>
     555      <p>This Internet-Draft will expire on December 24, 2012.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    647647      <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
    648648         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    649          different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
    650          Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
    651          error recovery could lead to dangerous consequences.
     649         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
     650         the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
     651         of error recovery could lead to dangerous consequences.
    652652      </p>
    653653      <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

    r1682 r1684  
    172172   specific error handling mechanisms, except in cases where it has direct
    173173   impact on security. This is because different uses of the protocol require
    174    different error handling strategies; for example, a Web browser may wish to
     174   different error handling strategies; for example, a Web browser might wish to
    175175   transparently recover from a response where the Location header field
    176176   doesn't parse according to the ABNF, whereby in a systems control protocol
Note: See TracChangeset for help on using the changeset viewer.