この文書は、インターネット・コミュニティーのためにインターネット標準路線プロトコルを定め、かつ改善のための議論と提案とを求めるものである。 このプロトコルの標準化状況と位置づけとについては、“Internet Official Protocol Standards” (STD 1) の最新版を参照されたい。 このメモの配布に制限はない。
インターネットの技術仕様では、形式的構文を定義することがしばしば必要となる。 ここ何年もの間、多くのインターネット仕様では ABNF (Augmented BNF、拡張 BNF) と呼ばれる BNF (Backus-Naur Form、バッカス・ナウア記法) の修正版が一般的になっている。 本仕様は ABNF を文書化するものである。 ABNF では、簡潔さおよび単純さと、十分な表現力とを両立させている。 標準の BNF と ABNF との相違点には、命名規約、反復、選択肢、順序非依存、値の範囲が含まれる。 本仕様ではまた、いくつかのインターネット仕様に共通するような中核的な字句解析のために、補助的な規則定義と符号化法とを提供する。
1. はじめに
2. 規則の定義
2.1. 規則の命名
2.2. 規則の形式
2.3. 終端値
2.4. 外部符号化法
3. 演算子
3.1. 連接: Rule1 Rule2
3.2. 選択肢: Rule1 / Rule2
3.3. 増分選択肢: Rule1 =/ Rule2
3.4. 範囲選択肢: %c##-##
3.5. 並びグループ: (Rule1 Rule2)
3.6. 可変回数反復: *Rule
3.7. 特定回数反復: nRule
3.8. 省略可能並び: [Rule]
3.9. コメント: ; Comment
3.10. 演算子の優先順位
4. ABNF の ABNF による定義
5. セキュリティーに関する考慮事項
6. 参照
6.1. 規格文献
6.2. 参考文献
付録 A. 謝辞
付録 B. ABNF による中核 ABNF
B.1. 中核規則
B.2. 共通の符号化法
インターネットの技術仕様では形式的構文を定義することがしばしば必要となるが、その執筆者が有用であると考えるものならば何を採用しようと自由である。 ここ何年もの間、多くのインターネット仕様では ABNF (Augmented BNF、拡張 BNF) と呼ばれる BNF (Backus-Naur Form、バッカス・ナウア記法) の修正版が一般的になっている。 それは、簡潔さおよび単純さと、十分な表現力とを両立させたものである。 Arpanet の初期には、それぞれの仕様が独自の ABNF の定義を収容していた。 電子メールの仕様 [RFC733] とその後の [RFC822] もそのような仕様のひとつであったが、これが ABNF の定義に頻繁に引用されるようになった。 本文書は、選択的な参照を可能にするため、それらの定義を分離するものである。 予想のつくように、いくつかの変更や拡張も加えられている。
標準の BNF と ABNF との相違点には、命名規約、反復、選択肢、順序非依存、値の範囲が含まれる。 付録 B では、いくつかのインターネット仕様に共通するような中核的な字句解析のための規則定義と符号化法とを与える。 これは便宜のために提供するものであって、この文書の本文で定義されているメタ言語とは別個のものであり、その公式の位置づけからも独立したものである。
規則の名前は、単純にその名前自身である。 つまり、英字で始まり、英字・数字・ハイフン (ダッシュ) の組み合わせが後続する、文字の並びである。
注意
規則名では大文字小文字は区別されない。
<rulename>、<Rulename>、<RULENAME>、<rUlENamE> という名前はすべて同一の規則を指す。
オリジナルの BNF とは異なり、アングル・ブラケット ("<"、">") は必須ではない。 とはいえ、規則名の前後にアングル・ブラケットがあることで規則名の用いられていることが見分けやすくなる場合にはいつでも使用してよい。 それは通常、自由形式の散文の中で規則名に言及する場合や、下の反復についての議論に見られるような、空白類による分割のない文字列として結び付いている規則の一部を目立たせる場合に限られる。
ひとつの規則は次のような並びによって定義される。
name = elements crlf
ここで、<name> は規則の名前、<elements> はひとつ以上の規則名ないし終端指定、<crlf> は行末指示子 (キャリッジ・リターン〔復帰〕とそれに続くライン・フィード〔行送り〕) である。 等号は、名前をその規則の定義から分離している。 elements は、この文書で定義する選択肢や反復などのさまざまな演算子によって結び付けられた、ひとつ以上の規則名ないし値定義の並びを形成する。
見やすいように、規則定義は左詰めにされる。 規則が複数の行にまたがる場合、継続行は字下げされる。 左詰めおよび字下げは、ABNF 規則群の最初の行から見た相対的なものであり、文書の左マージンに一致する必要はない。
規則は、終端値——文字と呼ばれることもある——の列に分解される。 ABNF においては、文字とは非負の整数でしかない。 場合によっては、値を (ASCII などの) 文字集合へ写像する特定の符号化法が指定されることになる。
終端値は、ひとつ以上の数字によって指定され、それらの数字の解釈を明示する基数法が添えられる(1)。 現在のところ、以下の基数法が定義されている。
b = binary (二進法) d = decimal (十進法) x = hexadecimal (十六進法)
よって、
CR = %d13 CR = %x0D
これらは [US-ASCII] のキャリッジ・リターンを、それぞれ十進表現および十六進表現で示している。
このような値どうしが連接している場合、その値の間に文字の分離を表わすピリオド (".") を使ってコンパクトに指定される。 次のごとし。
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 にのみ適合する。
終端値の文字の外部表現は、記憶環境や伝送環境の制約に応じて異なることになろう。 それゆえ、ひとつは 7 ビット US-ASCII 環境用の符号化法、もうひとつはバイナリー・オクテット環境用の符号化法、16 ビット Unicode が用いられる場合にはさらに別の符号化法といったように、ABNF ベースの同じひとつの文法であっても複数の外部符号化法がありうる。 符号化法の詳細は ABNF の範囲を超えるが、インターネットの大部分に共通している 7 ビット US-ASCII 環境用の定義を付録 B で与える。
外部符号化法を構文から分離することで、同じ構文に対して代替の符号化環境が利用できるようにしようというわけである。
規則は、規則名の並びを掲げることで、単純な値の順序列 (すなわち文字どうしの隣接する連なり) を定義することができる。 たとえば、次のように定義することで、
foo = %x61 ; a bar = %x62 ; b mumble = foo bar foo
規則 <mumble> は小文字の文字列 "aba" に適合するようになる。
線形空白類 (linear white space) について——。 連接は ABNF の構文解析モデルの中核にある。 隣接する文字 (値) の列は、ABNF で定義される規則に従って構文解析される。 インターネットの仕様には、区切りとなる特殊文字や不可分な文字列などの主要な構文要素の前後に、自由かつ暗黙裡に線形の空白類 (空白および水平タブ) を入れることを許してきたという歴史がある。
注意
本 ABNF 仕様では、線形空白類という暗黙の仕様を提供することはしない。
いかなる文法も、区切り文字や文字列部分の前後に線形空白類を認めたいと望むならば、それを明示的に指定しなければならない。 より高水準の諸規則の中でさまざまに利用される「中核」規則においてそうした空白類を提供しておくことは有用であることが多い。 「中核」規則は、字句解析器 (lexical analyzer) として形成することもできようし、あるいは単純に主要な規則集合の一部とすることもできよう。
フォワード・スラッシュ ("/") で区切られた要素は選択肢である。 したがって、
foo / bar
という定義は <foo> または <bar> を受け容れる。
注意
英字を含んだ引用符つき文字列は、文字の選択肢を指定するための特殊形式であり、含まれている文字の順序は指定どおりではあるが大文字と小文字とが混合する文字列のあらゆる組み合わせの集合を表わす非終端値であると解釈される。
選択肢のリストを断片に分けて指定したほうが時に便利なこともある。 つまり、ひとつ以上の選択肢に適合する最初の規則に対し、後の規則定義で選択肢の集合を増大させるのである。 これは、パラメーターのリストにおいてよく見られるような、同じ規則集合を母体としてそこから別個の独立した仕様を派生させる場合には特に有用である。 ABNF では次の構文によってこの増分定義を可能にしている。
oldrule =/ additional-alternatives
したがって以下の規則集合は、
ruleset = alt1 / alt2 ruleset =/ alt3 ruleset =/ alt4 / alt5
次のように指定するのと同じである。
ruleset = alt1 / alt2 / alt3 / alt4 / alt5
数値による選択肢の範囲は、選択肢の値の範囲を表わすダッシュ ("-") を使ってコンパクトに指定できる。 ゆえに、
DIGIT = %x30-39
これは次のものと等価である。
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
数値連接と数値範囲とを同じ文字列の中に指定することはできない。 ひとつの数値に対して使ってよいのは、連接を表わすドット記法か、または単一の範囲を指定するダッシュ記法かのいずれかである。 よって、ふたつの行末シーケンスに挟まれたひとつの印字可能文字は、次のように指定されよう。
char-line = %x0D.0A %x20-7E %x0D.0A
カッコに囲まれた要素は、正確に順序づけられた中身をもつ単一の要素として扱われる。 したがって、
elem (foo / bar) blat
これは (elem foo blat) または (elem bar blat) に適合する。 一方、
elem foo / bar blat
こちらは (elem foo) または (bar blat) に適合する。
注意
選択肢が複数の規則名やリテラルからなる場合、“裸” の選択肢が正しく読解されることを当てにするよりも、グループ化記法を用いることを強くお勧めする。
すなわち、次の形式を用いることが推奨される。
(elem foo) / (bar blat)
こうすることで無頓着な読者による誤解は避けられよう。
並びグループの記法はまた、自由形式の文章の中で要素の並びを地の文から目立たせるのにも用いられる。
要素の前に置かれる演算子 "*" は反復を表わす。 完全な形式は次のとおり。
<a>*<b>element
ここで、<a> と <b> とは省略可能な十進数値で、要素 (element) が少なくとも <a> 回、多くとも <b> 回、生起しうることを示す。
デフォルト値は 0 および無限大であるため、*<element> とすればゼロを含む任意の回数の生起を許す。 1*<element> とすれば少なくとも 1 回の生起を要する。 3*3<element> とすればきっちり 3 回の生起を許す。 そして 1*2<element> ならば 1 回ないし 2 回の生起を許す。
次の形式の規則は、
<n>element
次のものと等価である。
<n>*<n>element
すなわち、<element> のちょうど <n> 回の生起である。 したがって、2DIGIT は 2 桁の数字であり、3ALPHA は英字 3 字の文字列である。
スクウェア・ブラケットは次のように省略可能な要素の並びを囲む。
[foo bar]
これは次のものと等価である。
*1(foo bar)
セミコロンはコメント (注釈) の始まりであり、コメントは行末まで継続する。 これは構文指定と並行して有用な注記を含める簡単な方法である。
上で説明したさまざまなメカニズムは以下の優先順位をもつ。 上端に示すものの優先度が最上位 (結び付きが最も強い) で、下端に示すものが最下位 (最も弱い) である。
規則名、散文値 (prose-val)、終端値
コメント
値の範囲
反復
グループ化、省略可能
連接
選択肢
選択肢演算子は、連接と入り乱れて使用されると分かりにくくなる可能性がある。
繰り返すが、連接のグループを明示するためにグループ化演算子を用いることが推奨される。
注意
この構文は、比較的厳密な規則の書式整形を必要としている。 そのため、ひとつの仕様に含まれる規則集合を ABNF パーサーで解釈できるようにするには前処理が必要になるかもしれない。
この構文では、付録 B で示される諸規則を利用している。
rulelist = 1*( rule / (*c-wsp c-nl) )
rule = rulename defined-as elements c-nl
; 次の行が空白類で始まる場合、継続する。
rulename = ALPHA *(ALPHA / DIGIT / "-")
defined-as = *c-wsp ("=" / "=/") *c-wsp
; 基本的な規則定義と増分選択肢
elements = alternation *c-wsp
c-wsp = WSP / (c-nl WSP)
c-nl = comment / CRLF
; コメントまたは改行 (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
; DQUOTE を除く VCHAR と SP からなる
; 引用符つき文字列
num-val = "%" (bin-val / dec-val / hex-val)
bin-val = "b" 1*BIT
[ 1*("." 1*BIT) / ("-" 1*BIT) ]
; 連接するビット値の連続、または単一の
; 範囲選択肢。
dec-val = "d" 1*DIGIT
[ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
hex-val = "x" 1*HEXDIG
[ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
prose-val = "<" *(%x20-3D / %x3F-7E) ">"
; アングル・ブラケットで囲まれた
; SP および VCHAR からなる文字列。
; アングル・ブラケットは除く。(2)
; 散文 (prose) 説明、最後の手段として
; 用いる。
セキュリティーは、この文書にはまったく関係ないものと思われる。
| [US-ASCII] | American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. |
| [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. |
ABNF のための構文は最初、RFC 733 において指定された。 BNF から表現を小さく理解し易いものにする拡張 BNF への書き直しには、SRI International の Ken L. Harrenstien 氏が寄与してくれた。
この最近のプロジェクトは、RFC 822 から、電子メール以外の仕様の執筆者たちが繰り返し引用してきた部分、すなわち拡張 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 ソース形式への変換に関し、とくに謝意を表する。
この付録では、よく使われる基本的な規則をいくつか示す。 基本規則は大文字で示される。 これらの規則は、7 ビット ASCII か、または 7 ビット ASCII の上位集合となっている文字集合で符号化された ABNF についてのみ通用することに注意されたい。
数は多くはないが、基本規則は、SP、HTAB、CRLF、DIGIT、ALPHA などのように大文字で示される。
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
BIT = "0" / "1"
CHAR = %x01-7F
; NUL を除く任意の
; 7 ビット US-ASCII 文字
CR = %x0D
; キャリッジ・リターン (復帰)
CRLF = CR LF
; インターネット標準の改行 (newline)
CTL = %x00-1F / %x7F
; 制御文字
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (ダブル・クォート)
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB = %x09
; 水平タブ
LF = %x0A
; ライン・フィード (行送り)
LWSP = *(WSP / CRLF WSP)
; この線形空白類 (linear-white-space)
; 規則の使用は、メール・ヘッダーでは
; すでに非合法となった空白類のみから
; なる行を認めるものであり、他の文脈
; では相互運用上の問題を引き起こすこ
; とになった。
; メール・ヘッダーを定義する際に用いて
; はならず、他の文脈においては慎重に
; 用いること。
OCTET = %x00-FF
; 8 ビットのデータ
SP = %x20
VCHAR = %x21-7E
; 可視 (印字) 文字
WSP = SP / HTAB
; 空白類 (white space)
外部的には、データは「ネットワーク仮想 ASCII」(すなわち、上位 (8 番目) のビットをゼロに設定した 8 ビット・フィールドにおける 7 ビット US-ASCII)(3) によって表現される。 値の列は「ネットワーク・バイト順序」であり、より大きい値をもつバイトが左側に表現され、最初にネットワーク上へ送られる。
Dave Crocker (編)
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
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書は、BCP 78 に含まれる権利・許諾・制約の適用下にあり、そこに規定のある場合を除き、著者がそのすべての権利を保有する。
この文書およびここに含まれる情報は「現状有姿」方式で提供されるものであり、寄稿者、(もしあれば) その寄稿者が代表するかまたはその寄稿者を後援する組織、Internet Society、IETF Trust、ならびに Internet Engineering Task Force は、明示的であるか黙示的であるかを問わず、一切を保証しない。 ここでいう保証には、ここにある情報の利用がいかなる権利をも侵害しないという保証や、特定の目的に対する市場性ないし適合性についての暗黙の保証が含まれるが、それらのみに限定されない。
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、この文書に記述された技術の実装ないし利用に付随すると主張されうる知的財産権 (IPR) やその他の権利の正当性ないし適用範囲に関して、あるいはそのような権利の下でなされる許諾がどの程度まで有効かまたは無効かということに関して、いかなる立場をも取らない。 また、そのような権利を確認するためのいかなる自主的な取り組みもなされていないことを明言する。 RFC 文書の権利に関する手続きについての情報は BCP 78 および BCP 79 にある。
IETF 事務局に対して開示された IPR 情報の写しと利用可能となる許諾についての保証、またはそのような所有権の利用のために一般的な許諾もしくは許可を得ようと本仕様の実装者ないし利用者が行った試みの結果は、IETF のオンライン IPR リポジトリー http://www.ietf.org/ipr から入手できる。
IETF はすべての利害関係者に対し、本規格の実装に必要となる技術を対象としうるあらゆる著作権、特許ないし特許出願、またはその他の所有権について目配りをするよう要請するものである。 ietf-ipr@ietf.org 宛てに IETF まで情報をお寄せいただきたい。
| (1) | 基数に先立ってパーセント記号 (%) をつける必要があるが、それについての説明はない。 | |
| (2) | 原文には "without angles" と複数形が用いられていて、"<" と ">" の双方がともに除外されるということになりそうだが、規則定義の "%x20-3D / %x3F-7E" という記述からすれば、除外されるのは ">" だけである。 | |
| (3) | 原文では "with the high (8th) bit set to zero" という説明がカッコの外に出ているが、ここは常識的に考えて、カッコの中に入れて訳した。 参考までに付言すれば、RFC 327 では "Network ASCII" を "7-bit ASCII in 8-bit field with 8th bit zero" と説明している。 |