Changeset 335
- Timestamp:
- 06/11/08 17:39:32 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r334 r335 476 476 <tr> 477 477 <td class="header left"></td> 478 <td class="header right">November 5, 2008</td>478 <td class="header right">November 6, 2008</td> 479 479 </tr> 480 480 </table> … … 522 522 </li> 523 523 <li class="tocline0">2. <a href="#notation">Notational Conventions and Generic Grammar</a><ul class="toc"> 524 <li class="tocline1">2.1 <a href="#notation.abnf">Augmented BNF</a></li> 524 <li class="tocline1">2.1 <a href="#notation.abnf">Augmented BNF</a><ul class="toc"> 525 <li class="tocline1">2.1.1 <a href="#rfc.section.2.1.1">#rule</a></li> 526 <li class="tocline1">2.1.2 <a href="#implied.LWS">implied *LWS</a></li> 527 </ul> 528 </li> 525 529 <li class="tocline1">2.2 <a href="#basic.rules">Basic Rules</a></li> 526 530 <li class="tocline1">2.3 <a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li> … … 890 894 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="notation" href="#notation">Notational Conventions and Generic Grammar</a></h1> 891 895 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <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 "<" and ">") 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 "<n>*<m>element" indicating at least <n> and 921 at most <m> 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: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> 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 "<n>#<m>element" indicating at 938 least <n> and at most <m> 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> #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 "<n>#<m>element" indicating at 903 least <n> and at most <m> 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> <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> 965 918 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="basic.rules" href="#basic.rules">Basic Rules</a></h2> 966 919 <div id="core.rules"> … … 2276 2229 <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p> 2277 2230 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <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="#RFC 822ABNF" 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 and2231 <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 2279 2232 Internet mail message formats. 2280 2233 </p> … … 2357 2310 </tr> 2358 2311 <tr> 2359 <td class="reference"><b id="RFC 822ABNF">[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 11, RFC 822, August 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 68, RFC 5234, January 2008. 2361 2314 </td> 2362 2315 </tr> … … 2788 2741 <ul> 2789 2742 <li>Use "/" instead of "|" for alternatives.</li> 2743 <li>Get rid of RFC822 dependency; use RFC5234 plus extensions instead.</li> 2790 2744 </ul> 2791 2745 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> … … 2965 2919 </li> 2966 2920 <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 <a class="iref" href="#rfc.iref.i.2"><b>2.1 </b></a></li>2921 <li class="indline1">implied *LWS <a class="iref" href="#rfc.iref.i.2"><b>2.1.2</b></a></li> 2968 2922 <li class="indline1">inbound <a class="iref" href="#rfc.iref.i.1">1.3</a></li> 2969 2923 <li class="indline1"><em>ISO-8859-1</em> <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> … … 3075 3029 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1">9.3</a>, <a class="iref" href="#RFC4288"><b>12.2</b></a></li> 3076 3030 <li class="indline1"><em>RFC4395</em> <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> <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> 3077 3032 <li class="indline1"><em>RFC5322</em> <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"> 3078 3033 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.RFC5322.3">4.2</a></li> … … 3082 3037 </li> 3083 3038 <li class="indline1"><em>RFC822</em> <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> <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>3085 3039 <li class="indline1"><em>RFC959</em> <a class="iref" href="#rfc.xref.RFC959.1">1.1</a>, <a class="iref" href="#RFC959"><b>12.2</b></a></li> 3086 3040 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r334 r335 670 670 <t> 671 671 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 "<" and ">") 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 "<n>*<m>element" indicating at least <n> and at most 726 <m> 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: "<n>(element)" is equivalent to 746 "<n>*<n>(element)"; that is, exactly <n> 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 "<n>#<m>element" indicating at least 758 <n> and at most <m> 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 "<n>#<m>element" indicating at least 682 <n> and at most <m> 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"> 793 706 <iref item="implied *LWS" primary="true"/> 794 implied *LWS795 <list>796 707 <t> 797 708 The grammar described by this specification is word-based. Except … … 804 715 single token. 805 716 </t> 806 </list> 807 </t> 717 </section> 808 718 </section> 809 719 … … 3320 3230 <t> 3321 3231 This specification makes heavy use of the augmented BNF and generic 3322 constructs defined by David H. Crocker for <xref target="RFC 822ABNF"/>. Similarly, it3232 constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it 3323 3233 reuses many of the definitions provided by Nathaniel Borenstein and 3324 3234 Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this … … 3575 3485 </reference> 3576 3486 3577 <reference anchor="RFC 822ABNF">3487 <reference anchor="RFC5234"> 3578 3488 <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"/> 3585 3514 </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"/> 3588 3517 </reference> 3589 3518 … … 4714 4643 Use "/" instead of "|" for alternatives. 4715 4644 </t> 4645 <t> 4646 Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 4647 </t> 4716 4648 </list> 4717 4649 </t>
Note: See TracChangeset
for help on using the changeset viewer.