ネットワーク作業部会 D. Crocker, Ed. Request for Comments: 5234 Brandenburg InternetWorking STD: 68 P. Overell Obsoletes: 4234 THUS plc. Category: Standards Track January 2008 構文仕様のための拡張BNF：ABNF 本文書の位置づけ 本文書は、インターネットコミュニティのためのインターネット 標準化過程プロトコルを規定し、改善のための議論および提案を 求めるものである。このプロトコルの標準化状況および状態については、 「Internet Official Protocol Standards」（STD 1）の最新版を参照 されたい。本メモの配布に制限はない。 要旨 インターネット技術仕様では、しばしば形式構文を定義する必要が ある。長年にわたり、Backus-Naur Form（BNF）の修正版である Augmented BNF（ABNF）は、多くのインターネット仕様の間で広く 用いられてきた。本仕様はABNFを文書化するものである。これは、 簡潔さおよび単純さと、妥当な表現能力との均衡をとる。標準BNFと ABNFの相違点は、規則の命名、反復、代替、順序独立性、および 値範囲に関するものである。本仕様はまた、いくつかのインターネット 仕様に共通する種類の中核字句解析器のための追加の規則定義および 符号化も提供する。 Crocker & Overell Standards Track [Page 1]
RFC 5234 ABNF January 2008 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 規則定義 . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. 規則の命名 . . . . . . . . . . . . . . . . . . . . . 3 2.2. 規則の形式 . . . . . . . . . . . . . . . . . . . . . 4 2.3. 終端値 . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. 外部符号化 . . . . . . . . . . . . . . . . . . . . . 6 3. 演算子 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. 連結: Rule1 Rule2 . . . . . . . . . . . . . . . . . 6 3.2. 代替: Rule1 / Rule2 . . . . . . . . . . . . . . . . 7 3.3. 増分的代替: Rule1 =/ Rule2 . . . . . . . . . . . . . 7 3.4. 値範囲代替: %c##-## . . . . . . . . . . . . . . . . 8 3.5. 列グループ: (Rule1 Rule2) . . . . . . . . . . . . . 8 3.6. 可変反復: *Rule . . . . . . . . . . . . . . . . . 9 3.7. 指定反復: nRule . . . . . . . . . . . . . . . . . 9 3.8. 省略可能列: [RULE] . . . . . . . . . . . . . . . . 9 3.9. コメント: ; Comment . . . . . . . . . . . . . . . 9 3.10. 演算子の優先順位 . . . . . . . . . . . . . . . . . 10 4. ABNFによるABNFの定義 . . . . . . . . . . . . . . . . . . 10 5. セキュリティ上の考慮事項 . . . . . . . . . . . . . . . 12 6. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. 規範参考文献 . . . . . . . . . . . . . . . . . . . . 12 6.2. 参考参考文献 . . . . . . . . . . . . . . . . . . . . 12 Appendix A. 謝辞 . . . . . . . . . . . . . . . . . . . . . 13 Appendix B. ABNFの中核ABNF . . . . . . . . . . . . . . . . . 13 B.1. 中核規則 . . . . . . . . . . . . . . . . . . . . . . 13 B.2. 共通符号化 . . . . . . . . . . . . . . . . . . . . 15 Crocker & Overell Standards Track [Page 2]
RFC 5234 ABNF January 2008 1. はじめに インターネット技術仕様では、しばしば形式構文を定義する必要があり、 その著者が有用と考える任意の記法を用いることができる。長年に わたり、Backus-Naur Form（BNF）の修正版であるAugmented BNF （ABNF）は、多くのインターネット仕様の間で広く用いられてきた。 これは、簡潔さおよび単純さと、妥当な表現能力との均衡をとる。 Arpanetの初期には、各仕様が独自のABNF定義を含んでいた。これには 電子メール仕様、[RFC733] およびその後の [RFC822] が含まれ、 これらはABNFを定義するための共通の引用文献となった。現在の 文書は、選択的な参照を可能にするため、これらの定義を分離する。 予想されるとおり、本書はまた、いくつかの修正および拡張も提供する。 標準BNFとABNFの相違点は、規則の命名、反復、代替、順序独立性、 および値範囲に関するものである。Appendix B は、いくつかの インターネット仕様に共通する種類の中核字句解析器のための規則定義 および符号化を提供する。これは便宜のために提供されるものであり、 それ以外の点では、本文で定義されるメタ言語からも、その形式的な 地位からも分離されている。 2. 規則定義 2.1. 規則の命名 規則の名前は単にその名前そのものであり、英字で始まり、その後に 英字、数字、およびハイフン（ダッシュ）の組み合わせが続く文字列で ある。 注記: 規則名では大文字と小文字は区別されない。 <rulename>、<Rulename>、<RULENAME>、および <rUlENamE> は すべて同じ規則を参照する。 元のBNFとは異なり、山括弧（"<"、">"）は必須ではない。 しかし、規則名の使用を判別しやすくする場合には、規則名の周囲に 山括弧を使用してもよい。これは通常、自由形式の散文中の規則名 参照、または以下の反復に関する説明で示されるように、空白で 区切られずに文字列へ結合される部分規則を区別する場合に限られる。 Crocker & Overell Standards Track [Page 3]
RFC 5234 ABNF January 2008 2.2. 規則の形式 規則は次の列によって定義される。 name = elements crlf ここで、<name> は規則の名前、<elements> は1個以上の規則名 または終端仕様、<crlf> は行末指示子（復帰の後に改行が続くもの） である。等号は、名前を規則の定義から分離する。要素は、本文書で 定義される各種演算子（代替および反復など）に従って結合される、 1個以上の規則名および/または値定義の列を形成する。 見やすくするため、規則定義は左揃えにされる。規則が複数行を 必要とする場合、継続行はインデントされる。左揃えおよび インデントは、ABNF規則の最初の行を基準とするものであり、文書の 左余白と一致している必要はない。 2.3. 終端値 規則は終端値の文字列へ解決され、これは文字と呼ばれることもある。 ABNFにおいて、文字は単に非負整数である。特定の文脈では、値を 文字集合（ASCIIなど）へ対応付ける具体的な対応（符号化）が指定 される。 終端は1個以上の数字文字によって指定され、その文字の基数解釈は 明示的に示される。現在、次の基数が定義されている。 b = binary d = decimal x = hexadecimal したがって: CR = %d13 CR = %x0D はそれぞれ、復帰に対する [US-ASCII] の10進表現および16進表現を 指定する。 Crocker & Overell Standards Track [Page 4]
RFC 5234 ABNF January 2008 そのような値の連結文字列は、値内の文字の区切りを示すために ピリオド（"."）を用いて、簡潔に指定される。したがって: CRLF = %d13.10 ABNFでは、引用符で囲んでリテラルテキスト文字列を直接指定する ことができる。したがって: command = "command string" リテラルテキスト文字列は、印字可能文字の連結集合として解釈される。 注記: ABNF文字列では大文字と小文字は区別されず、これらの文字列の 文字集合はUS-ASCIIである。 したがって: rulename = "abc" および: rulename = "aBc" は、"abc"、"Abc"、"aBc"、"abC"、"ABc"、"aBC"、"AbC"、および "ABC" に一致する。 大文字と小文字を区別する規則を指定するには、文字を個別に 指定する。 例: rulename = %d97 %d98 %d99 または rulename = %d97.98.99 は、小文字の文字 abc のみから成る文字列だけに一致する。 Crocker & Overell Standards Track [Page 5]
RFC 5234 ABNF January 2008 2.4. 外部符号化 終端値文字の外部表現は、保存環境または伝送環境における制約に 従って変化する。したがって、同一のABNFベースの文法は、複数の 外部符号化を持ち得る。たとえば、7ビットUS-ASCII環境用のもの、 バイナリオクテット環境用のもの、さらに16ビットUnicodeを用いる 場合の別のものなどである。符号化の詳細はABNFの範囲外であるが、 Appendix B は、インターネットの多くで一般的であった7ビット US-ASCII環境のための定義を提供する。 構文から外部符号化を分離することにより、同じ構文に対して代替の 符号化環境を利用できるようにすることが意図されている。 3. 演算子 3.1. 連結: Rule1 Rule2 規則は、規則名の列を列挙することにより、値の単純な順序付き文字列 （すなわち、連続する文字の連結）を定義できる。例: foo = %x61 ; a bar = %x62 ; b mumble = foo bar foo これにより、規則 <mumble> は小文字文字列 "aba" に一致する。 線形空白: 連結はABNF解析モデルの中核にある。連続する文字（値）の 文字列は、ABNFで定義された規則に従って解析される。インターネット 仕様では、特殊文字や原子的文字列を区切るような主要構成要素の周囲に、 線形空白（スペースおよび水平タブ）を自由かつ暗黙的に挿入することを 許す歴史がいくらかある。 注記: 本ABNF仕様は、線形空白を暗黙的に指定する仕組みを提供しない。 区切り記号または文字列セグメントの周囲に線形空白を許容したい 文法は、それを明示的に指定しなければならない。そのような空白は、 さまざまな上位レベル規則の間で用いられる「中核」規則で提供する と有用な場合が多い。「中核」規則は、字句解析器として形成される 場合もあれば、単に主要な規則集合の一部である場合もある。 Crocker & Overell Standards Track [Page 6]
RFC 5234 ABNF January 2008 3.2. 代替: Rule1 / Rule2 スラッシュ（"/"）で区切られた要素は代替である。したがって、 foo / bar は <foo> または <bar> を受け入れる。 注記: 英字を含む引用文字列は、代替文字を指定する特殊な形式であり、 含まれる文字を指定された順序で持ち、大文字と小文字の任意の 混在を許す組合せ文字列の集合を表す非終端として解釈される。 3.3. 増分的代替: Rule1 =/ Rule2 代替のリストを断片に分けて指定すると便利な場合がある。すなわち、 初期規則が1個以上の代替に一致し、後続の規則定義が代替集合へ 追加する場合である。これは、同じ親規則集合から派生する、相互に 独立した仕様で特に有用である。たとえば、パラメータリストでよく 生じる。ABNFは、次の構成によってこの増分的定義を許す。 oldrule =/ additional-alternatives したがって、規則集合 ruleset = alt1 / alt2 ruleset =/ alt3 ruleset =/ alt4 / alt5 は、次を指定することと同じである。 ruleset = alt1 / alt2 / alt3 / alt4 / alt5 Crocker & Overell Standards Track [Page 7]
RFC 5234 ABNF January 2008 3.4. 値範囲代替: %c##-## 代替となる数値の範囲は、その代替値の範囲を示すためにダッシュ （"-"）を用いて簡潔に指定できる。したがって: DIGIT = %x30-39 は次と等価である。 DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 連結された数値と数値範囲は、同じ文字列内で指定することはできない。 数値は、連結のためにドット記法を用いることも、1個の値範囲を 指定するためにダッシュ記法を用いることもできる。したがって、 行末列の間に1個の印字可能文字を指定するには、仕様は次のように 書くことができる。 char-line = %x0D.0A %x20-7E %x0D.0A 3.5. 列グループ: (Rule1 Rule2) 括弧で囲まれた要素は単一の要素として扱われ、その内容は厳密に 順序付けられる。したがって、 elem (foo / bar) blat は (elem foo blat) または (elem bar blat) に一致し、 elem foo / bar blat は (elem foo) または (bar blat) に一致する。 注記: 代替が複数の規則名またはリテラルから成る場合には、「裸の」 代替の正しい読み取りに依存するのではなく、グループ化記法を 用いることが強く推奨される。 したがって、次の形式を使用することが推奨される。 (elem foo) / (bar blat) これにより、何気ない読者による誤解を避けられる。 Crocker & Overell Standards Track [Page 8]
RFC 5234 ABNF January 2008 列グループ記法は、自由文中で要素列を散文から区切るためにも用いられる。 3.6. 可変反復: *Rule 要素の前に置かれる演算子 "*" は反復を示す。完全な形式は次の通り である。 <a>*<b>element ここで、<a> および <b> は省略可能な10進値であり、要素の出現が 少なくとも <a> 回、最大で <b> 回であることを示す。 既定値は0および無限大であるため、*<element> は0回を含む任意の 回数を許し、1*<element> は少なくとも1回を要求し、3*3<element> はちょうど3回を許し、1*2<element> は1回または2回を許す。 3.7. 指定反復: nRule 次の形式の規則: <n>element は次と等価である。 <n>*<n>element すなわち、<element> がちょうど <n> 回出現することである。 したがって、2DIGIT は2桁の数であり、3ALPHA は3文字の英字から 成る文字列である。 3.8. 省略可能列: [RULE] 角括弧は省略可能な要素列を囲む。 [foo bar] は次と等価である。 *1(foo bar). 3.9. コメント: ; Comment セミコロンは、行末まで続くコメントを開始する。これは、仕様と並行して 有用な注記を含めるための単純な方法である。 Crocker & Overell Standards Track [Page 9]
RFC 5234 ABNF January 2008 3.10. 演算子の優先順位 上で述べた各種機構には次の優先順位があり、上が最も高い （最も強く結合する）もの、下が最も低い（最も緩く結合する）もの である。 Rule name, prose-val, Terminal value Comment Value range Repetition Grouping, Optional Concatenation Alternative 代替演算子を連結と自由に混在させると、混乱を招く可能性がある。 繰り返しになるが、連結グループを明示するためにグループ化演算子を 用いることが推奨される。 4. ABNFによるABNFの定義 注記: 1. この構文は、比較的厳密な規則の書式化を要求する。したがって、 仕様に含められる規則集合の版は、ABNFパーサによって解釈 できることを保証するために前処理が必要となる場合がある。 2. この構文は Appendix B で提供される規則を用いる。 rulelist = 1*( rule / (*c-wsp c-nl) ) rule = rulename defined-as elements c-nl ; continues if next line starts ; with white space rulename = ALPHA *(ALPHA / DIGIT / "-") Crocker & Overell Standards Track [Page 10]
RFC 5234 ABNF January 2008 defined-as = *c-wsp ("=" / "=/") *c-wsp ; basic rules definition and ; incremental alternatives elements = alternation *c-wsp c-wsp = WSP / (c-nl WSP) c-nl = comment / CRLF ; comment or newline comment = ";" *(WSP / VCHAR) CRLF alternation = concatenation *(*c-wsp "/" *c-wsp concatenation) concatenation = repetition *(1*c-wsp repetition) repetition = [repeat] element repeat = 1*DIGIT / (*DIGIT "*" *DIGIT) element = rulename / group / option / char-val / num-val / prose-val group = "(" *c-wsp alternation *c-wsp ")" option = "[" *c-wsp alternation *c-wsp "]" char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE ; quoted string of SP and VCHAR ; without DQUOTE num-val = "%" (bin-val / dec-val / hex-val) bin-val = "b" 1*BIT [ 1*("." 1*BIT) / ("-" 1*BIT) ] ; series of concatenated bit values ; or single ONEOF range dec-val = "d" 1*DIGIT [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ] hex-val = "x" 1*HEXDIG [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ] Crocker & Overell Standards Track [Page 11]
RFC 5234 ABNF January 2008 prose-val = "<" *(%x20-3D / %x3F-7E) ">" ; bracketed string of SP and VCHAR ; without angles ; prose description, to be used as ; last resort 5. セキュリティ上の考慮事項 セキュリティは本文書には実際に無関係であると考えられている。 6. 参考文献 6.1. 規範参考文献 [US-ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. 6.2. 参考参考文献 [RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, November 1977. [RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. Crocker & Overell Standards Track [Page 12]
RFC 5234 ABNF January 2008 Appendix A. 謝辞 ABNFの構文は、もともと RFC 733 で規定された。SRI International のKen L. Harrenstienは、BNFを、表現をより小さく、より理解しやすく するAugmented BNFへ再符号化する責任を担った。 この最近のプロジェクトは、電子メール仕様ではない仕様の著者によって 繰り返し引用されてきた RFC 822 の部分、すなわちAugmented BNFの 説明を切り出す単純な作業として始まった。単に既存のテキストを 別文書へ機械的に変換するのではなく、作業部会は、既存仕様および 過去15年間に利用可能となった関連仕様の欠点と利点の双方を慎重に 検討することを選び、そのため拡張を追求した。これにより、この プロジェクトは当初意図されたものよりもかなり野心的なものとなった。 興味深いことに、結果はその原型と大きく異なるものではないが、 リスト記法の削除などの決定は驚きをもって受け止められた。 この仕様の「分離」版はDRUMS作業部会の一部であり、Jerome Abela、 Harald Alvestrand、Robert Elz、Roger Fajman、Aviva Garrett、Tom Harsch、Dan Kohn、Bill McQuillan、Keith Moore、Chris Newman、Pete Resnick、およびHenning Schulzrinneから重要な貢献があった。 Julian Reschkeには、Draft Standard版をXMLソース形式へ変換したことに 対して特別な謝意を表する。 Appendix B. ABNFの中核ABNF この付録には、共通して使用されるいくつかの基本規則が含まれる。 基本規則は大文字で表記される。これらの規則は、7ビットASCIIで 符号化されたABNF、または7ビットASCIIの上位集合である文字集合に おいてのみ有効であることに注意されたい。 B.1. 中核規則 SP、HTAB、CRLF、DIGIT、ALPHAなど、特定の基本規則は大文字である。 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z BIT = "0" / "1" CHAR = %x01-7F ; any 7-bit US-ASCII character, ; excluding NUL Crocker & Overell Standards Track [Page 13]
RFC 5234 ABNF January 2008 CR = %x0D ; carriage return CRLF = CR LF ; Internet standard newline CTL = %x00-1F / %x7F ; controls DIGIT = %x30-39 ; 0-9 DQUOTE = %x22 ; " (Double Quote) HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HTAB = %x09 ; horizontal tab LF = %x0A ; linefeed LWSP = *(WSP / CRLF WSP) ; Use of this linear-white-space rule ; permits lines containing only white ; space that are no longer legal in ; mail headers and have caused ; interoperability problems in other ; contexts. ; Do not use when defining mail ; headers and use with caution in ; other contexts. OCTET = %x00-FF ; 8 bits of data SP = %x20 VCHAR = %x21-7E ; visible (printing) characters WSP = SP / HTAB ; white space Crocker & Overell Standards Track [Page 14]
RFC 5234 ABNF January 2008 B.2. 共通符号化 外部的には、データは「ネットワーク仮想ASCII」（すなわち、8ビット フィールド内の7ビットUS-ASCII）として表現され、高位（8番目）の ビットは0に設定される。値の文字列は「ネットワークバイト順」で あり、より高位のバイトが左側に表現され、ネットワーク上で先に送信 される。 著者の連絡先 Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 US Phone: +1.408.246.8253 EMail: dcrocker@bbiw.net Paul Overell THUS plc. 1/2 Berkeley Square, 99 Berkeley Street Glasgow G3 7HR UK EMail: paul.overell@thus.net Crocker & Overell Standards Track [Page 15]
RFC 5234 ABNF January 2008 完全な著作権表示 Copyright (C) The IETF Trust (2008). 本文書は BCP 78 に含まれる権利、ライセンスおよび制限の対象であり、 そこで定められている場合を除き、著者はすべての権利を保持する。 本文書およびここに含まれる情報は「AS IS」ベースで提供され、 CONTRIBUTOR、HE/SHEを代表する組織またはHE/SHEを支援する組織 （もしあれば）、INTERNET SOCIETY、IETF TRUST、およびINTERNET ENGINEERING TASK FORCEは、明示または黙示を問わず、ここに含まれる 情報の使用がいかなる権利も侵害しないことの保証、または商品性もしくは 特定目的適合性の黙示の保証を含むがこれらに限定されない、すべての 保証を否認する。 知的財産 IETFは、本文書に記述された技術の実装または使用に関係すると主張 され得る知的財産権その他の権利の有効性または範囲、ならびにそのような 権利に基づくライセンスが利用可能であるか否か、または利用可能となる 範囲について、いかなる立場も取らない。また、そのような権利を特定 するために独自の努力を行ったことを表明するものでもない。RFC文書に おける権利に関する手続きについての情報は、BCP 78 および BCP 79 に記載されている。 IETF事務局に提出されたIPR開示の写し、および実装者または利用者が 本仕様を使用するために必要となる可能性のある専有的権利の使用について、 一般ライセンスまたは許可を取得しようとした結果、もしくは提供される ライセンスの保証は、IETFオンラインIPRリポジトリ http://www.ietf.org/ipr から取得できる。 IETFは、本標準を実装するために必要となる可能性のある技術を対象とする 著作権、特許、特許出願、またはその他の専有的権利を、関心のある者が IETFの注意に持ち込むことを歓迎する。その情報はIETF宛 ietf-ipr@ietf.org に送付されたい。 Crocker & Overell Standards Track [Page 16]