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

Timestamp:

21/06/12 09:01:49 (9 years ago)

Author:

julian.reschke@…

Message:

Clarify that in general recipients MUST be able to parse everything allowed by the ABNF (see #361)

File:

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

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires December 22, 2012"; 
+       content: "Expires December 23, 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-20">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-06-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. Furthermore, it defines HTTP message content, metadata, and content negotiation.">
@@ -528 +528 @@
             </tr>
             <tr>
-               <td class="left">Expires: December 22, 2012</td>
+               <td class="left">Expires: December 23, 2012</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">June 20, 2012</td>
+               <td class="right">June 21, 2012</td>
             </tr>
          </tbody>
@@ -552 +552 @@
       <p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.
       </p>  
-      <p>The changes in this draft are summarized in <a href="#changes.since.19" title="Since draft-ietf-httpbis-p2-semantics-19">Appendix&nbsp;E.40</a>.
+      <p>The changes in this draft are summarized in <a href="#changes.since.19" title="Since draft-ietf-httpbis-p2-semantics-19 and draft-ietf-httpbis-p3-payload-19">Appendix&nbsp;E.40</a>.
       </p> 
       <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>
@@ -563 +563 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 22, 2012.</p>
+      <p>This Internet-Draft will expire on December 23, 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>
@@ -807 +807 @@
                <li>E.38&nbsp;&nbsp;&nbsp;<a href="#changes.since.18">Since draft-ietf-httpbis-p2-semantics-18</a></li>
                <li>E.39&nbsp;&nbsp;&nbsp;<a href="#changes.3.since.18">Since draft-ietf-httpbis-p3-payload-18</a></li>
-               <li>E.40&nbsp;&nbsp;&nbsp;<a href="#changes.since.19">Since draft-ietf-httpbis-p2-semantics-19</a></li>
-               <li>E.41&nbsp;&nbsp;&nbsp;<a href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></li>
+               <li>E.40&nbsp;&nbsp;&nbsp;<a href="#changes.since.19">Since draft-ietf-httpbis-p2-semantics-19 and draft-ietf-httpbis-p3-payload-19</a></li>
             </ul>
          </li>
@@ -857 +856 @@
       <p id="rfc.section.1.2.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.3</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
       </p>
-      <p id="rfc.section.1.2.p.5">Unless noted otherwise, Recipients <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
+      <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
@@ -4729 +4728 @@
          </li>
       </ul>
-      <h2 id="rfc.section.E.40"><a href="#rfc.section.E.40">E.40</a>&nbsp;<a id="changes.since.19" href="#changes.since.19">Since draft-ietf-httpbis-p2-semantics-19</a></h2>
+      <h2 id="rfc.section.E.40"><a href="#rfc.section.E.40">E.40</a>&nbsp;<a id="changes.since.19" href="#changes.since.19">Since draft-ietf-httpbis-p2-semantics-19 and draft-ietf-httpbis-p3-payload-19</a></h2>
       <p id="rfc.section.E.40.p.1">Closed issues: </p>
       <ul>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/312">http://tools.ietf.org/wg/httpbis/trac/ticket/312</a>&gt;: "should there be a permanent variant of 307"
          </li>
-      </ul>
-      <h2 id="rfc.section.E.41"><a href="#rfc.section.E.41">E.41</a>&nbsp;<a id="changes.3.since.19" href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></h2>
-      <p id="rfc.section.E.41.p.1">None yet.</p>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>&gt;: "ABNF requirements for recipients"
+         </li>
+      </ul>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
       <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a>