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

Timestamp:

31/07/10 08:54:31 (12 years ago)

Author:

julian.reschke@…

Message:

regen HTML

File:

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

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

@@ -403 +403 @@
       <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="2010-07-30">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
       <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 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.">
@@ -434 +434 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 31, 2011</td>
+               <td class="left">Expires: February 1, 2011</td>
                <td class="right">HP</td>
             </tr>
@@ -487 +487 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 30, 2010</td>
+               <td class="right">July 31, 2010</td>
             </tr>
          </tbody>
@@ -514 +514 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in January 31, 2011.</p>
+      <p>This Internet-Draft will expire in February 1, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -938 +938 @@
       <div id="rfc.iref.s.1"></div>
       <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
-      <p id="rfc.section.7.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be
-         careful to allow the user to be aware of any actions they take which might have an unexpected significance to themselves or
-         others.
+      <p id="rfc.section.7.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow
+         the user to be aware of any actions they take which might have an unexpected significance to themselves or others.
       </p>
       <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
@@ -1225 +1224 @@
       </p>
       <div class="note" id="rfc.section.8.3.p.2"> 
-         <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers should be aware that there might be clients that implement such a fixed limitation.
+         <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation.
          </p> 
       </div>
@@ -1635 +1634 @@
       <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc.
          It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling
-         where they allow links from (so-called "deep linking"), but it should be noted that legitimate requests are not required to
-         contain a Referer header field.
+         where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field.
       </p>
       <p id="rfc.section.9.6.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),
@@ -1705 +1703 @@
       <p id="rfc.section.10.1.p.1">The registration procedure for HTTP Methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.1</a> of this document.
       </p>
-      <p id="rfc.section.10.1.p.2">The HTTP Method Registry should be created at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; and be populated with the registrations below:
+      <p id="rfc.section.10.1.p.2">The HTTP Method Registry shall be created at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; and be populated with the registrations below:
       </p>
       <div id="rfc.table.1">
@@ -1772 +1770 @@
       <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> -- is now defined by <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.1</a> of this document.
       </p>
-      <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; should be updated with the registrations below:
+      <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
       </p>
       <div id="rfc.table.2">
@@ -2005 +2003 @@
       </div>
       <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
-      <p id="rfc.section.10.3.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
+      <p id="rfc.section.10.3.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
       </p>
       <div id="rfc.table.3">
@@ -2128 +2126 @@
       <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
       </p>
-      <p id="rfc.section.11.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded
-         in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it
-         might be visible to third parties. Such services can use POST-based form submission instead.
+      <p id="rfc.section.11.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
+         servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties.
+         Such services can use POST-based form submission instead.
       </p>
       <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>