Ignore:
Timestamp:
Nov 6, 2008, 9:39:32 AM (11 years ago)
Author:
julian.reschke@…
Message:

reference RFC5234 instead of RFC822 for ABNF, but continue to extend it with implied LWS and #rule (related to #36)

File:
1 edited

Legend:

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

    r334 r335  
    476476         <tr>
    477477            <td class="header left"></td>
    478             <td class="header right">November 5, 2008</td>
     478            <td class="header right">November 6, 2008</td>
    479479         </tr>
    480480      </table>
     
    522522         </li>
    523523         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#notation">Notational Conventions and Generic Grammar</a><ul class="toc">
    524                <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#notation.abnf">Augmented BNF</a></li>
     524               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#notation.abnf">Augmented BNF</a><ul class="toc">
     525                     <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.1.1">#rule</a></li>
     526                     <li class="tocline1">2.1.2&nbsp;&nbsp;&nbsp;<a href="#implied.LWS">implied *LWS</a></li>
     527                  </ul>
     528               </li>
    525529               <li class="tocline1">2.2&nbsp;&nbsp;&nbsp;<a href="#basic.rules">Basic Rules</a></li>
    526530               <li class="tocline1">2.3&nbsp;&nbsp;&nbsp;<a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li>
     
    890894      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="notation" href="#notation">Notational Conventions and Generic Grammar</a></h1>
    891895      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="notation.abnf" href="#notation.abnf">Augmented BNF</a></h2>
    892       <p id="rfc.section.2.1.p.1">All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar
    893          to that used by <a href="#RFC822ABNF" id="rfc.xref.RFC822ABNF.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822ABNF]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes
    894          the following constructs:
    895       </p>
    896       <p id="rfc.section.2.1.p.2">name = definition </p>
    897       <dl class="empty">
    898          <dd>The name of a rule is simply the name itself (without any enclosing "&lt;" and "&gt;") and is separated from its definition by the
    899             equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule
    900             definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA,
    901             etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
    902          </dd>
    903       </dl>
    904       <p id="rfc.section.2.1.p.3">"literal" </p>
    905       <dl class="empty">
    906          <dd>Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.</dd>
    907       </dl>
    908       <p id="rfc.section.2.1.p.4">rule1 / rule2 </p>
    909       <dl class="empty">
    910          <dd>Elements separated by a forward slash ("/") are alternatives, e.g., "yes / no" will accept yes or no.</dd>
    911       </dl>
    912       <p id="rfc.section.2.1.p.5">(rule1 rule2) </p>
    913       <dl class="empty">
    914          <dd>Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo / bar) elem)" allows the token sequences
    915             "elem foo elem" and "elem bar elem".
    916          </dd>
    917       </dl>
    918       <p id="rfc.section.2.1.p.6">*rule </p>
    919       <dl class="empty">
    920          <dd>The character "*" preceding an element indicates repetition. The full form is "&lt;n&gt;*&lt;m&gt;element" indicating at least &lt;n&gt; and
    921             at most &lt;m&gt; occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero;
    922             "1*element" requires at least one; and "1*2element" allows one or two.
    923          </dd>
    924       </dl>
    925       <p id="rfc.section.2.1.p.7">[rule] </p>
    926       <dl class="empty">
    927          <dd>Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".</dd>
    928       </dl>
    929       <p id="rfc.section.2.1.p.8">N rule </p>
    930       <dl class="empty">
    931          <dd>Specific repetition: "&lt;n&gt;(element)" is equivalent to "&lt;n&gt;*&lt;n&gt;(element)"; that is, exactly &lt;n&gt; occurrences of (element). Thus
    932             2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
    933          </dd>
    934       </dl>
    935       <p id="rfc.section.2.1.p.9">#rule </p>
    936       <dl class="empty">
    937          <dd>A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at
    938             least &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas (",") and <em class="bcp14">OPTIONAL</em> linear white space (LWS). This makes the usual form of lists very easy; a rule such as
    939             <div id="rfc.figure.u.4"></div><pre class="text">   ( *<a href="#rule.LWS" class="smpl">LWS</a> element *( *<a href="#rule.LWS" class="smpl">LWS</a> "," *<a href="#rule.LWS" class="smpl">LWS</a> element ))</pre> </dd>
    940          <dd>can be shown as
    941             <div id="rfc.figure.u.5"></div><pre class="text">   1#element</pre> </dd>
    942          <dd>Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is,
    943             "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required,
    944             at least one non-null element <em class="bcp14">MUST</em> be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at
    945             least one; and "1#2element" allows one or two.
    946          </dd>
    947       </dl>
    948       <p id="rfc.section.2.1.p.10">; comment </p>
    949       <dl class="empty">
    950          <dd>A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is
    951             a simple way of including useful notes in parallel with the specifications.
    952          </dd>
    953       </dl>
    954       <div id="implied.LWS">
    955          <p id="rfc.section.2.1.p.11"> <span id="rfc.iref.i.2"></span> implied *LWS
    956          </p>
    957          <dl class="empty">
    958             <dd>The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included
    959                between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation
    960                of a field. At least one delimiter (LWS and/or separators) <em class="bcp14">MUST</em> exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single
    961                token.
    962             </dd>
    963          </dl>
    964       </div>
     896      <p id="rfc.section.2.1.p.1">All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (ABNF) based
     897         on that defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The extensions to ABNF
     898         used in this specification are described below.
     899      </p>
     900      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;#rule
     901      </h3>
     902      <p id="rfc.section.2.1.1.p.1">A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at
     903         least &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas (",") and <em class="bcp14">OPTIONAL</em> linear white space (LWS). This makes the usual form of lists very easy; a rule such as
     904      </p>
     905      <div id="rfc.figure.u.4"></div><pre class="text"> ( *<a href="#rule.LWS" class="smpl">LWS</a> element *( *<a href="#rule.LWS" class="smpl">LWS</a> "," *<a href="#rule.LWS" class="smpl">LWS</a> element ))</pre><p id="rfc.section.2.1.1.p.2">can be shown as </p>
     906      <div id="rfc.figure.u.5"></div><pre class="text"> 1#element</pre><p id="rfc.section.2.1.1.p.3">Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is,
     907         "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required,
     908         at least one non-null element <em class="bcp14">MUST</em> be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at
     909         least one; and "1#2element" allows one or two.
     910      </p>
     911      <div id="rfc.iref.i.2"></div>
     912      <h3 id="rfc.section.2.1.2"><a href="#rfc.section.2.1.2">2.1.2</a>&nbsp;<a id="implied.LWS" href="#implied.LWS">implied *LWS</a></h3>
     913      <p id="rfc.section.2.1.2.p.1">The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included
     914         between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation
     915         of a field. At least one delimiter (LWS and/or separators) <em class="bcp14">MUST</em> exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single
     916         token.
     917      </p>
    965918      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="basic.rules" href="#basic.rules">Basic Rules</a></h2>
    966919      <div id="core.rules">
     
    22762229      <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
    22772230      <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    2278       <p id="rfc.section.11.p.1">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC822ABNF" id="rfc.xref.RFC822ABNF.2"><cite title="Standard for the format of ARPA Internet text messages">[RFC822ABNF]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and
     2231      <p id="rfc.section.11.p.1">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and
    22792232         Internet mail message formats.
    22802233      </p>
     
    23572310         </tr>
    23582311         <tr>
    2359             <td class="reference"><b id="RFC822ABNF">[RFC822ABNF]</b></td>
    2360             <td class="top"><a title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.H.</a>, “<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>”, STD&nbsp;11, RFC&nbsp;822, August&nbsp;1982.
     2312            <td class="reference"><b id="RFC5234">[RFC5234]</b></td>
     2313            <td class="top"><a title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a title="THUS plc.">P. Overell</a>, “<a href="http://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>”, STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008.
    23612314            </td>
    23622315         </tr>
     
    27882741      <ul>
    27892742         <li>Use "/" instead of "|" for alternatives.</li>
     2743         <li>Get rid of RFC822 dependency; use RFC5234 plus extensions instead.</li>
    27902744      </ul>
    27912745      <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
     
    29652919            </li>
    29662920            <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
    2967                   <li class="indline1">implied *LWS&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.2"><b>2.1</b></a></li>
     2921                  <li class="indline1">implied *LWS&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.2"><b>2.1.2</b></a></li>
    29682922                  <li class="indline1">inbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1">1.3</a></li>
    29692923                  <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">2.2</a>, <a class="iref" href="#ISO-8859-1"><b>12.1</b></a></li>
     
    30753029                  <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4288.1">9.3</a>, <a class="iref" href="#RFC4288"><b>12.2</b></a></li>
    30763030                  <li class="indline1"><em>RFC4395</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4395.1">9.2</a>, <a class="iref" href="#RFC4395"><b>12.2</b></a></li>
     3031                  <li class="indline1"><em>RFC5234</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.1">2.1</a>, <a class="iref" href="#rfc.xref.RFC5234.2">11</a>, <a class="iref" href="#RFC5234"><b>12.1</b></a></li>
    30773032                  <li class="indline1"><em>RFC5322</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">4.1</a>, <a class="iref" href="#rfc.xref.RFC5322.3">4.2</a>, <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind">
    30783033                        <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.3">4.2</a></li>
     
    30823037                  </li>
    30833038                  <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.1">3.3.1</a>, <a class="iref" href="#RFC822"><b>12.2</b></a></li>
    3084                   <li class="indline1"><em>RFC822ABNF</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822ABNF.1">2.1</a>, <a class="iref" href="#rfc.xref.RFC822ABNF.2">11</a>, <a class="iref" href="#RFC822ABNF"><b>12.1</b></a></li>
    30853039                  <li class="indline1"><em>RFC959</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC959.1">1.1</a>, <a class="iref" href="#RFC959"><b>12.2</b></a></li>
    30863040               </ul>
Note: See TracChangeset for help on using the changeset viewer.