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

Changeset 335


Ignore:
Timestamp:
2008-11-06 09:39:32 (6 years ago)
Author:
julian.reschke@gmx.de
Message:

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

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

    r334 r335  
    670670<t> 
    671671   All of the mechanisms specified in this document are described in 
    672    both prose and an augmented Backus-Naur Form (BNF) similar to that 
    673    used by <xref target="RFC822ABNF"/>. Implementors will need to be familiar with the 
    674    notation in order to understand this specification. The augmented BNF 
    675    includes the following constructs: 
    676 </t> 
    677 <t> 
    678    name = definition 
    679   <list> 
    680     <t> 
    681       The name of a rule is simply the name itself (without any 
    682       enclosing "&lt;" and "&gt;") and is separated from its definition by the 
    683       equal "=" character. White space is only significant in that 
    684       indentation of continuation lines is used to indicate a rule 
    685       definition that spans more than one line. Certain basic rules are 
    686       in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle 
    687       brackets are used within definitions whenever their presence will 
    688       facilitate discerning the use of rule names. 
    689     </t> 
    690   </list> 
    691 </t> 
    692 <t> 
    693    "literal" 
    694   <list> 
    695     <t> 
    696       Quotation marks surround literal text. Unless stated otherwise, 
    697       the text is case-insensitive. 
    698     </t> 
    699   </list> 
    700 </t> 
    701 <t> 
    702    rule1 / rule2 
    703   <list> 
    704     <t> 
    705       Elements separated by a forward slash ("/") are alternatives, e.g., "yes / 
    706       no" will accept yes or no. 
    707     </t> 
    708   </list> 
    709 </t> 
    710 <t> 
    711    (rule1 rule2) 
    712   <list> 
    713     <t> 
    714       Elements enclosed in parentheses are treated as a single element. 
    715       Thus, "(elem (foo / bar) elem)" allows the token sequences "elem 
    716       foo elem" and "elem bar elem". 
    717     </t> 
    718   </list> 
    719 </t> 
    720 <t> 
    721    *rule 
    722   <list> 
    723     <t> 
    724       The character "*" preceding an element indicates repetition. The 
    725       full form is "&lt;n&gt;*&lt;m&gt;element" indicating at least &lt;n&gt; and at most 
    726       &lt;m&gt; occurrences of element. Default values are 0 and infinity so 
    727       that "*(element)" allows any number, including zero; "1*element" 
    728       requires at least one; and "1*2element" allows one or two. 
    729     </t> 
    730   </list> 
    731 </t> 
    732 <t> 
    733    [rule] 
    734   <list> 
    735     <t> 
    736       Square brackets enclose optional elements; "[foo bar]" is 
    737       equivalent to "*1(foo bar)". 
    738     </t> 
    739   </list> 
    740 </t> 
    741 <t> 
    742    N rule 
    743   <list> 
    744     <t> 
    745       Specific repetition: "&lt;n&gt;(element)" is equivalent to 
    746       "&lt;n&gt;*&lt;n&gt;(element)"; that is, exactly &lt;n&gt; occurrences of (element). 
    747       Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three 
    748       alphabetic characters. 
    749     </t> 
    750   </list> 
    751 </t> 
    752 <t> 
    753    #rule 
    754   <list> 
    755     <t> 
    756       A construct "#" is defined, similar to "*", for defining lists of 
    757       elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at least 
    758       &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas 
    759       (",") and &OPTIONAL; linear white space (LWS). This makes the usual 
    760       form of lists very easy; a rule such as 
    761       <figure><artwork type="example"> 
    762    ( *<x:ref>LWS</x:ref> element *( *<x:ref>LWS</x:ref> "," *<x:ref>LWS</x:ref> element ))</artwork></figure> 
    763     </t> 
    764     <t> 
    765       can be shown as 
    766       <figure><artwork type="example"> 
    767    1#element</artwork></figure> 
    768     </t> 
    769     <t> 
    770       Wherever this construct is used, null elements are allowed, but do 
    771       not contribute to the count of elements present. That is, 
    772       "(element), , (element) " is permitted, but counts as only two 
    773       elements. Therefore, where at least one element is required, at 
    774       least one non-null element &MUST; be present. Default values are 0 
    775       and infinity so that "#element" allows any number, including zero; 
    776       "1#element" requires at least one; and "1#2element" allows one or 
    777       two. 
    778     </t> 
    779   </list> 
    780 </t> 
    781 <t> 
    782    ; comment 
    783   <list> 
    784     <t> 
    785       A semi-colon, set off some distance to the right of rule text, 
    786       starts a comment that continues to the end of line. This is a 
    787       simple way of including useful notes in parallel with the 
    788       specifications. 
    789     </t> 
    790   </list> 
    791 </t> 
    792 <t anchor="implied.LWS"> 
     672   both prose and an augmented Backus-Naur Form (ABNF) based on that 
     673   defined in <xref target="RFC5234"/>. Implementors will need to be 
     674   familiar with the notation in order to understand this specification. The 
     675   extensions to ABNF used in this specification are described below. 
     676</t> 
     677 
     678<section title="#rule"> 
     679  <t> 
     680    A construct "#" is defined, similar to "*", for defining lists of 
     681    elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at least 
     682    &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas 
     683    (",") and &OPTIONAL; linear white space (LWS). This makes the usual 
     684    form of lists very easy; a rule such as 
     685    <figure><artwork type="example"> 
     686 ( *<x:ref>LWS</x:ref> element *( *<x:ref>LWS</x:ref> "," *<x:ref>LWS</x:ref> element ))</artwork></figure> 
     687  </t> 
     688  <t> 
     689    can be shown as 
     690    <figure><artwork type="example"> 
     691 1#element</artwork></figure> 
     692  </t> 
     693  <t> 
     694    Wherever this construct is used, null elements are allowed, but do 
     695    not contribute to the count of elements present. That is, 
     696    "(element), , (element) " is permitted, but counts as only two 
     697    elements. Therefore, where at least one element is required, at 
     698    least one non-null element &MUST; be present. Default values are 0 
     699    and infinity so that "#element" allows any number, including zero; 
     700    "1#element" requires at least one; and "1#2element" allows one or 
     701    two. 
     702  </t> 
     703</section> 
     704 
     705<section title="implied *LWS" anchor="implied.LWS"> 
    793706  <iref item="implied *LWS" primary="true"/> 
    794    implied *LWS 
    795   <list> 
    796707    <t> 
    797708      The grammar described by this specification is word-based. Except 
     
    804715      single token. 
    805716    </t> 
    806   </list> 
    807 </t> 
     717</section> 
    808718</section> 
    809719 
     
    33203230<t> 
    33213231   This specification makes heavy use of the augmented BNF and generic 
    3322    constructs defined by David H. Crocker for <xref target="RFC822ABNF"/>. Similarly, it 
     3232   constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it 
    33233233   reuses many of the definitions provided by Nathaniel Borenstein and 
    33243234   Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this 
     
    35753485</reference> 
    35763486 
    3577 <reference anchor="RFC822ABNF"> 
     3487<reference anchor="RFC5234"> 
    35783488  <front> 
    3579     <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> 
    3580     <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> 
    3581       <organization>University of Delaware, Dept. of Electrical Engineering</organization> 
    3582       <address><email>DCrocker@UDel-Relay</email></address> 
    3583     </author> 
    3584     <date month="August" day="13" year="1982"/> 
     3489    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> 
     3490    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> 
     3491      <organization>Brandenburg InternetWorking</organization> 
     3492      <address> 
     3493      <postal> 
     3494      <street>675 Spruce Dr.</street> 
     3495      <city>Sunnyvale</city> 
     3496      <region>CA</region> 
     3497      <code>94086</code> 
     3498      <country>US</country></postal> 
     3499      <phone>+1.408.246.8253</phone> 
     3500      <email>dcrocker@bbiw.net</email></address>   
     3501    </author> 
     3502    <author initials="P." surname="Overell" fullname="Paul Overell"> 
     3503      <organization>THUS plc.</organization> 
     3504      <address> 
     3505      <postal> 
     3506      <street>1/2 Berkeley Square</street> 
     3507      <street>99 Berkely Street</street> 
     3508      <city>Glasgow</city> 
     3509      <code>G3 7HR</code> 
     3510      <country>UK</country></postal> 
     3511      <email>paul.overell@thus.net</email></address> 
     3512    </author> 
     3513    <date month="January" year="2008"/> 
    35853514  </front> 
    3586   <seriesInfo name="STD" value="11"/> 
    3587   <seriesInfo name="RFC" value="822"/> 
     3515  <seriesInfo name="STD" value="68"/> 
     3516  <seriesInfo name="RFC" value="5234"/> 
    35883517</reference> 
    35893518 
     
    47144643      Use "/" instead of "|" for alternatives. 
    47154644    </t> 
     4645    <t> 
     4646      Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 
     4647    </t> 
    47164648  </list> 
    47174649</t> 
Note: See TracChangeset for help on using the changeset viewer.