* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 1682


Ignore:
Timestamp:
2012-06-21 02:01:49 (2 years ago)
Author:
julian.reschke@gmx.de
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
13 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> 
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1677 r1682  
    602602</t> 
    603603<t> 
    604    Unless otherwise noted, recipients &MAY; attempt to recover a usable 
     604   Unless noted otherwise, recipients &MUST; be able to parse all protocol 
     605   elements matching the ABNF rules defined for them and &MAY; attempt to recover a usable 
    605606   protocol element from an invalid construct.  HTTP does not define 
    606607   specific error handling mechanisms except when they have a direct impact 
     
    58235824      "make IANA policy definitions consistent" 
    58245825    </t> 
     5826    <t> 
     5827      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 
     5828      "ABNF requirements for recipients" 
     5829    </t> 
    58255830  </list> 
    58265831</t> 
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1680 r1682  
    449449  }  
    450450  @bottom-center { 
    451        content: "Expires December 22, 2012";  
     451       content: "Expires December 23, 2012";  
    452452  }  
    453453  @bottom-right { 
     
    497497      <meta name="dct.creator" content="Reschke, J. F."> 
    498498      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 
    499       <meta name="dct.issued" scheme="ISO8601" content="2012-06-20"> 
     499      <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 
    500500      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    501501      <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."> 
     
    528528            </tr> 
    529529            <tr> 
    530                <td class="left">Expires: December 22, 2012</td> 
     530               <td class="left">Expires: December 23, 2012</td> 
    531531               <td class="right">greenbytes</td> 
    532532            </tr> 
    533533            <tr> 
    534534               <td class="left"></td> 
    535                <td class="right">June 20, 2012</td> 
     535               <td class="right">June 21, 2012</td> 
    536536            </tr> 
    537537         </tbody> 
     
    552552      <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;. 
    553553      </p>   
    554       <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>. 
     554      <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>. 
    555555      </p>  
    556556      <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1> 
     
    563563         in progress”. 
    564564      </p> 
    565       <p>This Internet-Draft will expire on December 22, 2012.</p> 
     565      <p>This Internet-Draft will expire on December 23, 2012.</p> 
    566566      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    567567      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    807807               <li>E.38&nbsp;&nbsp;&nbsp;<a href="#changes.since.18">Since draft-ietf-httpbis-p2-semantics-18</a></li> 
    808808               <li>E.39&nbsp;&nbsp;&nbsp;<a href="#changes.3.since.18">Since draft-ietf-httpbis-p3-payload-18</a></li> 
    809                <li>E.40&nbsp;&nbsp;&nbsp;<a href="#changes.since.19">Since draft-ietf-httpbis-p2-semantics-19</a></li> 
    810                <li>E.41&nbsp;&nbsp;&nbsp;<a href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></li> 
     809               <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> 
    811810            </ul> 
    812811         </li> 
     
    857856      <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. 
    858857      </p> 
    859       <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 
     858      <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 
    860859         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 
    861860         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 
     
    47294728         </li> 
    47304729      </ul> 
    4731       <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> 
     4730      <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> 
    47324731      <p id="rfc.section.E.40.p.1">Closed issues: </p> 
    47334732      <ul> 
    47344733         <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" 
    47354734         </li> 
    4736       </ul> 
    4737       <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> 
    4738       <p id="rfc.section.E.41.p.1">None yet.</p> 
     4735         <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" 
     4736         </li> 
     4737      </ul> 
    47394738      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 
    47404739      <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>  
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1680 r1682  
    300300</t> 
    301301<t> 
    302    Unless noted otherwise, Recipients &MAY; take steps to recover a usable 
    303    protocol element from an invalid construct. However, HTTP does not define 
     302   Unless noted otherwise, Recipients &MUST; be able to parse all protocol 
     303   elements matching the ABNF rules defined for them and &MAY; take steps to 
     304   recover a usable protocol element from an invalid construct. However, HTTP does not define 
    304305   specific error handling mechanisms, except in cases where it has direct 
    305306   impact on security. This is because different uses of the protocol require 
     
    67646765</section> 
    67656766 
    6766 <section title="Since draft-ietf-httpbis-p2-semantics-19" anchor="changes.since.19"> 
     6767<section title="Since draft-ietf-httpbis-p2-semantics-19 and draft-ietf-httpbis-p3-payload-19" anchor="changes.since.19"> 
    67676768<t> 
    67686769  Closed issues: 
     
    67726773      "should there be a permanent variant of 307" 
    67736774    </t> 
     6775    <t> 
     6776      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 
     6777      "ABNF requirements for recipients" 
     6778    </t> 
    67746779  </list> 
    6775 </t> 
    6776 </section> 
    6777  
    6778 <section title="Since draft-ietf-httpbis-p3-payload-19" anchor="changes.3.since.19"> 
    6779 <t> 
    6780   None yet. 
    67816780</t> 
    67826781</section> 
  • draft-ietf-httpbis/latest/p3-payload.html

    r1679 r1682  
    374374  }  
    375375  @bottom-center { 
    376        content: "Expires December 21, 2012";  
     376       content: "Expires December 23, 2012";  
    377377  }  
    378378  @bottom-right { 
     
    404404      <meta name="dct.creator" content="Reschke, J. F."> 
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 
    406       <meta name="dct.issued" scheme="ISO8601" content="2012-06-19"> 
     406      <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 
    407407      <meta name="dct.abstract" content="This part is now obsolete. Please see HTTPbis, Part 2."> 
    408408      <meta name="description" content="This part is now obsolete. Please see HTTPbis, Part 2."> 
     
    424424            </tr> 
    425425            <tr> 
    426                <td class="left">Expires: December 21, 2012</td> 
     426               <td class="left">Expires: December 23, 2012</td> 
    427427               <td class="right">W3C</td> 
    428428            </tr> 
     
    437437            <tr> 
    438438               <td class="left"></td> 
    439                <td class="right">June 19, 2012</td> 
     439               <td class="right">June 21, 2012</td> 
    440440            </tr> 
    441441         </tbody> 
     
    453453         in progress”. 
    454454      </p> 
    455       <p>This Internet-Draft will expire on December 21, 2012.</p> 
     455      <p>This Internet-Draft will expire on December 23, 2012.</p> 
    456456      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    457457      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1667 r1682  
    449449  }  
    450450  @bottom-center { 
    451        content: "Expires December 3, 2012";  
     451       content: "Expires December 23, 2012";  
    452452  }  
    453453  @bottom-right { 
     
    490490      <meta name="dct.creator" content="Reschke, J. F."> 
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 
    492       <meta name="dct.issued" scheme="ISO8601" content="2012-06-01"> 
     492      <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    494494      <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 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> 
     
    516516            </tr> 
    517517            <tr> 
    518                <td class="left">Expires: December 3, 2012</td> 
     518               <td class="left">Expires: December 23, 2012</td> 
    519519               <td class="right">J. Reschke, Editor</td> 
    520520            </tr> 
     
    525525            <tr> 
    526526               <td class="left"></td> 
    527                <td class="right">June 1, 2012</td> 
     527               <td class="right">June 21, 2012</td> 
    528528            </tr> 
    529529         </tbody> 
     
    555555         in progress”. 
    556556      </p> 
    557       <p>This Internet-Draft will expire on December 3, 2012.</p> 
     557      <p>This Internet-Draft will expire on December 23, 2012.</p> 
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    658658      <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 
    659659      </p> 
    660       <p id="rfc.section.1.1.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 
     660      <p id="rfc.section.1.1.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 
    661661         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 
    662662         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 
     
    13391339      </p> 
    13401340      <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a>&nbsp;<a id="changes.since.19" href="#changes.since.19">Since draft-ietf-httpbis-p4-conditional-19</a></h2> 
    1341       <p id="rfc.section.C.1.p.1">None yet.</p> 
     1341      <p id="rfc.section.C.1.p.1">Closed issues: </p> 
     1342      <ul> 
     1343         <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" 
     1344         </li> 
     1345      </ul> 
    13421346      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 
    13431347      <p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.E">E</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.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a>  
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1667 r1682  
    192192</t> 
    193193<t> 
    194    Unless noted otherwise, Recipients &MAY; take steps to recover a usable 
    195    protocol element from an invalid construct. However, HTTP does not define 
     194   Unless noted otherwise, Recipients &MUST; be able to parse all protocol 
     195   elements matching the ABNF rules defined for them and &MAY; take steps to 
     196   recover a usable protocol element from an invalid construct. However, HTTP does not define 
    196197   specific error handling mechanisms, except in cases where it has direct 
    197198   impact on security. This is because different uses of the protocol require 
     
    14091410<section title="Since draft-ietf-httpbis-p4-conditional-19" anchor="changes.since.19"> 
    14101411<t> 
    1411   None yet. 
     1412  Closed issues: 
     1413  <list style="symbols">  
     1414    <t> 
     1415      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 
     1416      "ABNF requirements for recipients" 
     1417    </t> 
     1418  </list> 
    14121419</t> 
    14131420</section> 
  • draft-ietf-httpbis/latest/p5-range.html

    r1667 r1682  
    449449  }  
    450450  @bottom-center { 
    451        content: "Expires December 3, 2012";  
     451       content: "Expires December 23, 2012";  
    452452  }  
    453453  @bottom-right { 
     
    492492      <meta name="dct.creator" content="Reschke, J. F."> 
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-06-01"> 
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    496496      <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 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests."> 
     
    518518            </tr> 
    519519            <tr> 
    520                <td class="left">Expires: December 3, 2012</td> 
     520               <td class="left">Expires: December 23, 2012</td> 
    521521               <td class="right">J. Reschke, Editor</td> 
    522522            </tr> 
     
    527527            <tr> 
    528528               <td class="left"></td> 
    529                <td class="right">June 1, 2012</td> 
     529               <td class="right">June 21, 2012</td> 
    530530            </tr> 
    531531         </tbody> 
     
    555555         in progress”. 
    556556      </p> 
    557       <p>This Internet-Draft will expire on December 3, 2012.</p> 
     557      <p>This Internet-Draft will expire on December 23, 2012.</p> 
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    680680      <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 
    681681      </p> 
    682       <p id="rfc.section.1.1.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 
     682      <p id="rfc.section.1.1.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 
    683683         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 
    684684         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 
     
    14931493      <ul> 
    14941494         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/358">http://tools.ietf.org/wg/httpbis/trac/ticket/358</a>&gt;: "ABNF list expansion code problem" 
     1495         </li> 
     1496         <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" 
    14951497         </li> 
    14961498      </ul> 
  • draft-ietf-httpbis/latest/p5-range.xml

    r1667 r1682  
    182182</t> 
    183183<t> 
    184    Unless noted otherwise, Recipients &MAY; take steps to recover a usable 
    185    protocol element from an invalid construct. However, HTTP does not define 
     184   Unless noted otherwise, Recipients &MUST; be able to parse all protocol 
     185   elements matching the ABNF rules defined for them and &MAY; take steps to 
     186   recover a usable protocol element from an invalid construct. However, HTTP does not define 
    186187   specific error handling mechanisms, except in cases where it has direct 
    187188   impact on security. This is because different uses of the protocol require 
     
    17171718      "ABNF list expansion code problem" 
    17181719    </t> 
     1720    <t> 
     1721      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 
     1722      "ABNF requirements for recipients" 
     1723    </t> 
    17191724  </list> 
    17201725</t> 
  • draft-ietf-httpbis/latest/p6-cache.html

    r1675 r1682  
    452452  }  
    453453  @bottom-center { 
    454        content: "Expires December 13, 2012";  
     454       content: "Expires December 23, 2012";  
    455455  }  
    456456  @bottom-right { 
     
    494494      <meta name="dct.creator" content="Reschke, J. F."> 
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 
    496       <meta name="dct.issued" scheme="ISO8601" content="2012-06-11"> 
     496      <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    498498      <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 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> 
     
    520520            </tr> 
    521521            <tr> 
    522                <td class="left">Expires: December 13, 2012</td> 
     522               <td class="left">Expires: December 23, 2012</td> 
    523523               <td class="right">M. Nottingham, Editor</td> 
    524524            </tr> 
     
    537537            <tr> 
    538538               <td class="left"></td> 
    539                <td class="right">June 11, 2012</td> 
     539               <td class="right">June 21, 2012</td> 
    540540            </tr> 
    541541         </tbody> 
     
    567567         in progress”. 
    568568      </p> 
    569       <p>This Internet-Draft will expire on December 13, 2012.</p> 
     569      <p>This Internet-Draft will expire on December 23, 2012.</p> 
    570570      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    571571      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    772772      <p id="rfc.section.1.3.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.4</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 
    773773      </p> 
    774       <p id="rfc.section.1.3.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 
     774      <p id="rfc.section.1.3.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 
    775775         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 
    776776         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 
     
    20222022         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/356">http://tools.ietf.org/wg/httpbis/trac/ticket/356</a>&gt;: "Spurious 'MAY's" 
    20232023         </li> 
     2024         <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" 
     2025         </li> 
    20242026      </ul> 
    20252027      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1675 r1682  
    326326</t> 
    327327<t> 
    328    Unless noted otherwise, Recipients &MAY; take steps to recover a usable 
    329    protocol element from an invalid construct. However, HTTP does not define 
     328   Unless noted otherwise, Recipients &MUST; be able to parse all protocol 
     329   elements matching the ABNF rules defined for them and &MAY; take steps to 
     330   recover a usable protocol element from an invalid construct. However, HTTP does not define 
    330331   specific error handling mechanisms, except in cases where it has direct 
    331332   impact on security. This is because different uses of the protocol require 
     
    25072508      "Spurious 'MAY's" 
    25082509    </t> 
     2510    <t> 
     2511      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 
     2512      "ABNF requirements for recipients" 
     2513    </t> 
    25092514  </list> 
    25102515</t> 
  • draft-ietf-httpbis/latest/p7-auth.html

    r1681 r1682  
    645645      <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 
    646646      </p> 
    647       <p id="rfc.section.1.1.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 
     647      <p id="rfc.section.1.1.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 
    648648         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 
    649649         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 
     
    11501150         </li> 
    11511151         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/357">http://tools.ietf.org/wg/httpbis/trac/ticket/357</a>&gt;: "Authentication exchanges" 
     1152         </li> 
     1153         <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" 
    11521154         </li> 
    11531155      </ul> 
  • draft-ietf-httpbis/latest/p7-auth.xml

    r1681 r1682  
    167167</t> 
    168168<t> 
    169    Unless noted otherwise, Recipients &MAY; take steps to recover a usable 
    170    protocol element from an invalid construct. However, HTTP does not define 
     169   Unless noted otherwise, Recipients &MUST; be able to parse all protocol 
     170   elements matching the ABNF rules defined for them and &MAY; take steps to 
     171   recover a usable protocol element from an invalid construct. However, HTTP does not define 
    171172   specific error handling mechanisms, except in cases where it has direct 
    172173   impact on security. This is because different uses of the protocol require 
     
    11641165      "Authentication exchanges" 
    11651166    </t> 
     1167    <t> 
     1168      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 
     1169      "ABNF requirements for recipients" 
     1170    </t> 
    11661171  </list> 
    11671172</t> 
Note: See TracChangeset for help on using the changeset viewer.