Changeset 1682 for draft-ietf-httpbis/latest/p1-messaging.html

Timestamp:

21/06/12 09:01:49 (10 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/p1-messaging.html (modified) (6 diffs)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires December 17, 2012"; 
+       content: "Expires December 23, 2012"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-06-15">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-06-21">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -523 +523 @@
             </tr>
             <tr>
-               <td class="left">Expires: December 17, 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 15, 2012</td>
+               <td class="right">June 21, 2012</td>
             </tr>
          </tbody>
@@ -561 +561 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 17, 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>
@@ -959 +959 @@
       <p id="rfc.section.2.5.p.3">Senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements.
       </p>
-      <p id="rfc.section.2.5.p.4">Unless otherwise noted, recipients <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
+      <p id="rfc.section.2.5.p.4">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> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
          except when they have a direct impact on security, since different applications of the protocol require different error handling
          strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field
@@ -3530 +3530 @@
       <ul>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/346">http://tools.ietf.org/wg/httpbis/trac/ticket/346</a>&gt;: "make IANA policy definitions consistent"
+         </li>
+         <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>