Changeset 335


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)

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.