Ignore:
Timestamp:
Jun 21, 2012, 2:01:49 AM (7 years ago)
Author:
julian.reschke@…
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1677 r1682  
    449449  }
    450450  @bottom-center {
    451        content: "Expires December 17, 2012";
     451       content: "Expires December 23, 2012";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-06-15">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-06-21">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: December 17, 2012</td>
     525               <td class="left">Expires: December 23, 2012</td>
    526526               <td class="right">greenbytes</td>
    527527            </tr>
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">June 15, 2012</td>
     530               <td class="right">June 21, 2012</td>
    531531            </tr>
    532532         </tbody>
     
    561561         in progress”.
    562562      </p>
    563       <p>This Internet-Draft will expire on December 17, 2012.</p>
     563      <p>This Internet-Draft will expire on December 23, 2012.</p>
    564564      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    565565      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    959959      <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.
    960960      </p>
    961       <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
     961      <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
    962962         except when they have a direct impact on security, since different applications of the protocol require different error handling
    963963         strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field
     
    35303530      <ul>
    35313531         <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"
     3532         </li>
     3533         <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"
    35323534         </li>
    35333535      </ul>
Note: See TracChangeset for help on using the changeset viewer.