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

Timestamp:

23/12/07 13:22:38 (13 years ago)

Author:

julian.reschke@…

Message:

Cleanup references after switch to symbolic references (removing duplicated RFC numbers), clean up some of the references XML code.

File:

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

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

@@ -1096 +1096 @@
       </p>
       <dl class="empty">
-         <dd> <b>Note:</b> RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most
-            existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless
-            of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear
-            which kind of reaction is expected of the client.
+         <dd> <b>Note:</b>  <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations
+            treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method.
+            The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected
+            of the client.
          </dd>
       </dl>
@@ -1129 +1129 @@
       </p>
       <dl class="empty">
-         <dd> <b>Note:</b> RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not
-            observing these limitations has significant security consequences.
+         <dd> <b>Note:</b>  <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing
+            these limitations has significant security consequences.
          </dd>
       </dl>
@@ -1391 +1391 @@
       <div id="rfc.iref.h.4"></div>
       <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="header.from" href="#header.from">From</a></h2>
-      <p id="rfc.section.10.3.p.1">The From request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> as updated by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
+      <p id="rfc.section.10.3.p.1">The From request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> as updated by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
       </p>
       <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span>    From   = "From" ":" mailbox
@@ -1544 +1544 @@
       <h1 id="rfc.references"><a href="#rfc.section.14" id="rfc.section.14">14.</a> References
       </h1>
-      <table summary="References">                        
+      <table summary="References">                          
          <tr>
             <td class="reference"><b id="Luo1998">[Luo1998]</b></td>
@@ -1582 +1582 @@
             <td class="reference"><b id="RFC1123">[RFC1123]</b></td>
             <td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD&nbsp;3, RFC&nbsp;1123, October&nbsp;1989.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1945">[RFC1945]</b></td>
+            <td class="top"><a title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.T.</a>, and <a title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
             </td>
          </tr>
@@ -1646 +1651 @@
       <p id="rfc.section.A.p.5">Clean up confusion between 403 and 404 responses. (Section <a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden">9.4.4</a>, <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">9.4.5</a>, and <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">9.4.11</a>)
       </p>
-      <p id="rfc.section.A.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
+      <p id="rfc.section.A.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
       </p>
       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
@@ -1887 +1892 @@
                   <li class="indline1">Retry-After header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.retry-after.1">6</a>, <a class="iref" href="#rfc.iref.r.2"><b>10.7</b></a></li>
                   <li class="indline1"><em>RFC1123</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1123.1">10.3</a>, <a class="iref" href="#RFC1123"><b>14</b></a></li>
-                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#RFC2068"><b>14</b></a>, <a class="iref" href="#rfc.xref.RFC2068.1">A</a></li>
+                  <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1945.1">9.3.3</a>, <a class="iref" href="#RFC1945"><b>14</b></a></li>
+                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">9.3.3</a>, <a class="iref" href="#rfc.xref.RFC2068.2">9.3.6</a>, <a class="iref" href="#RFC2068"><b>14</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">A</a></li>
                   <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>14</b></a></li>
                   <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#RFC2616"><b>14</b></a></li>