この文書はRFC4234の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group D. Crocker, Ed.
Request for Comments: 4234 Brandenburg InternetWorking
Obsoletes: 2234 P. Overell
Category: Standards Track THUS plc.
October 2005
Augmented BNF for Syntax Specifications: ABNF
構文のための拡張ＢＮＦ仕様：ＡＢＮＦ
Status of This Memo
このメモの状況
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化中プロトコ
ルを指定し、改良のために議論と提案を求めます。標準化状態とこのプロト
コルの状態については「インターネット公式プロトコル標準」（ＳＴＤ１）
の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Abstract
要約
Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form
(BNF), called Augmented BNF (ABNF), has been popular among many
Internet specifications. The current specification documents ABNF.
It balances compactness and simplicity, with reasonable
representational power. The differences between standard BNF and
ABNF involve naming rules, repetition, alternatives, order-
independence, and value ranges. This specification also supplies
additional rule definitions and encoding for a core lexical analyzer
of the type common to several Internet specifications.
インターネット技術仕様書がしばしば正式の構文を定義する必要があります。
これまで、拡張ＢＮＦ（ＡＢＮＦ）と呼ばれる、バッカス・ナウア記法（ＢＮ
Ｆ）の修正版、多くのインターネット仕様書の間で人気でした。この仕様書は
ＡＢＮＦを文書化します。これは、妥当な具象力で、小ささと単純さのバラン
スをとります。標準ＢＮＦとＡＢＮＦの相違は命名規則、反復、選択肢、順序
独立と値範囲を含みます。この仕様書はいくつかのインターネット仕様書に共
通の種類の核心となる語彙分析のための追加の規則定義とコーディングを供給
します。
Table of Contents
目次
1. INTRODUCTION
1. はじめに
2. RULE DEFINITION
2. 規則定義
2.1. Rule Naming
2.1. 命名規則
2.2. Rule Form
2.2. 規則形式
2.3. Terminal Values
2.3. 終端値
2.4. External Encodings
2.4. 外部コーディング
3. OPERATORS
3. 演算子
3.1. Concatenation: Rule1 Rule2
3.1. 結合：規則１ 規則２
3.2. Alternatives: Rule1 / Rule2
3.2. 選択：規則１／規則２
3.3. Incremental Alternatives: Rule1 =/ Rule2
3.3. 逐次選択：規則１＝／規則２
3.4. Value Range Alternatives: %c##-##
3.4. 価範囲選択：％ｃ##-##
3.5. Sequence Group: (Rule1 Rule2)
3.5. 順序グループ：（規則１ 規則２）
3.6. Variable Repetition: *Rule
3.6. 可変繰返：＊規則
3.7. Specific Repetition: nRule
3.7. 特定繰返し：ｎ規則
3.8. Optional Sequence: [RULE]
3.8. 任意順序：［規則］
3.9. Comment: ; Comment
3.9. コメント：；コメント
3.10. Operator Precedence
3.10. 演算子優先度
4. ABNF DEFINITION OF ABNF
4. ＡＢＮＦのＡＢＮＦでの定義
5. SECURITY CONSIDERATIONS
5. セキュリティの考慮
6. References
6. 参考文献
6.1. Normative References
6.1. 参照する参考文献
6.2. Informative References
6.2. 有益な参考文献
Appendix A. ACKNOWLEDGEMENTS
付録Ａ．謝辞
Appendix B. APPENDIX - CORE ABNF OF ABNF
付録Ｂ．付録−ＡＢＮＦの核ＡＢＮＦ
B.1. Core Rules
B.1. 核規則
B.2. Common Encoding
B.2. 共通コーディング
1. INTRODUCTION
1. はじめに
Internet technical specifications often need to define a formal
syntax and are free to employ whatever notation their authors deem
useful. Over the years, a modified version of Backus-Naur Form
(BNF), called Augmented BNF (ABNF), has been popular among many
Internet specifications. It balances compactness and simplicity,
with reasonable representational power. In the early days of the
Arpanet, each specification contained its own definition of ABNF.
This included the email specifications, [RFC733] and then [RFC822],
which came to be the common citations for defining ABNF. The current
document separates those definitions to permit selective reference.
Predictably, it also provides some modifications and enhancements.
技術的なインターネット仕様書がしばしば正式の構文を定義する必要があり、
それらの著者が有用であるとみなす任意の表記法を使用できます。何年もの
間、拡張ＢＮＦ（ＡＢＮＦ）と呼ばれる、バッカス・ナウア記法（ＢＮＦ）
の修正版が、多くのインターネット仕様書の間で人気でした。これは、妥当
な具象力で、小ささと単純さのバランスをとります。アーパーネットの初期
には、それぞれの仕様書がそれ自身のＡＢＮＦの定義を含んでいました。こ
れは電子メール仕様書、[RFC733]とその後の[RFC822]を含み、そしてこれは
ＡＢＮＦを定義する際の共通の引用になりました。現在の文書は選択的な参
照を認めるためにそれらの定義を切り離します。予想どおり、これはある修
正と拡張を供給します。
The differences between standard BNF and ABNF involve naming rules,
repetition, alternatives, order-independence, and value ranges.
Appendix B supplies rule definitions and encoding for a core lexical
analyzer of the type common to several Internet specifications. It
is provided as a convenience and is otherwise separate from the meta
language defined in the body of this document, and separate from its
formal status.
標準ＢＮＦとＡＢＮＦの相違は命名規則、反復、選択肢、順序独立と値範囲
を含みます。この仕様書はいくつかのインターネット仕様書に共通の種類の
核心となる語彙分析のための追加の規則定義とコーディングを供給します。
付録Ｂがいくつかのインターネット仕様書に共通の種類の核心の語彙分析の
ために規則定義とコーディングを供給します。これは便利な道具として供給
され、そしてこの文書の本体で定義されたメタ言語とは独立で、正式の状態
とは独立です。
Changes since [RFC2234]:
[RFC2234]からの変更：
In Section 3.7, the phrase: "That is, exactly <N> occurrences of
<element>." was corrected to: "That is, exactly <n> occurrences of
<element>."
セクション３.７で、句「それは、<element>の正確に<N>の事象です。」
は「それは、<element>の正確に<n>の事象です。」に修正されます。
Some continuation comment lines needed to be corrected to begin
with comment character (";").
ある継続コメント行がコメント文字(";")で始まるように修正されました。
2. RULE DEFINITION
2. 規則定義
2.1. Rule Naming
2.1. 命名規則
The name of a rule is simply the name itself; that is, a sequence of
characters, beginning with an alphabetic character, and followed by a
combination of alphabetics, digits, and hyphens (dashes).
規則の名前はただ名前自身であす；すなわち、アルファベット文字から始ま
り、アルファベット文字と数字文字とハイフン（ダッシュ）が続く列です。
NOTE:
重要性：
Rule names are case-insensitive
規則名は大文字小文字の違いを無視します。
The names <rulename>, <Rulename>, <RULENAME>, and <rUlENamE> all
refer to the same rule.
名前<rulename>と<Rulename>と<RULENAME>と<rUlENamE>はすべては同じ規則
を示します。
Unlike original BNF, angle brackets ("<", ">") are not required.
However, angle brackets may be used around a rule name whenever their
presence facilitates in discerning the use of a rule name. This is
typically restricted to rule name references in free-form prose, or
to distinguish partial rules that combine into a string not separated
by white space, such as shown in the discussion about repetition,
below.
オリジナルのＢＮＦと違い、山括弧（"<", ">"）は必要ありません。しかし
ながら、山括弧があることで規則名の使用の認識を容易にする時はいつでも、
規則名の周囲で使われるかもしれません。これは一般に、下記の反復の議論
で示されるように、自由形式や空白スペースで分割されていない文字列に結
合された部分規則の区別での引用での規則名の参照を制限します。
2.2. Rule Form
2.2. 規則形式
A rule is defined by the following sequence:
規則が次の列で定義されます：
name = elements crlf
where <name> is the name of the rule, <elements> is one or more rule
names or terminal specifications, and <crlf> is the end-of-line
indicator (carriage return followed by line feed). The equal sign
separates the name from the definition of the rule. The elements
form a sequence of one or more rule names and/or value definitions,
combined according to the various operators defined in this document,
such as alternative and repetition.
<name>が規則の名前で、<elements>は１つ以上の規則名か終端で、<crlf>は
「行末」表示（キャリッジリターンに続くラインフィード）です。等号は名
前を規則の定義から分離します。要素は、この文書で定義された選択や繰返
しの様な種々な演算子で結合された、１つ以上の規則名や値定義の列です。
For visual ease, rule definitions are left aligned. When a rule
requires multiple lines, the continuation lines are indented. The
left alignment and indentation are relative to the first lines of the
ABNF rules and need not match the left margin of the document.
見易さのため、規則定義は左詰めされています。規則が多数の行を必要とす
る時、継続行は字下げして書かれます。左積めと字下げは、ABNF規則の最
初の行と関係があり、文書の左端に合う必要がありません。
2.3. Terminal Values
2.3. 終端値
Rules resolve into a string of terminal values, sometimes called
characters. In ABNF, a character is merely a non-negative integer.
In certain contexts, a specific mapping (encoding) of values into a
character set (such as ASCII) will be specified.
規則は、文字と呼ばれる、最終値の列に変換されます。ABNFで文字は単純に
非負整数です。ある特定の状況で、値から（ＡＳＣＩＩのような）文字集合
への特定の対応付け（コーディング）が指定されるでしょう。
Terminals are specified by one or more numeric characters, with the
base interpretation of those characters indicated explicitly. The
following bases are currently defined:
終端は、明示的に示した文字の解釈ベースで、１つ以上の数字文字で指定さ
れます。次のベースが現在定義されます：
b = binary
２進数
d = decimal
１０進数
x = hexadecimal
１６進数
Hence:
つまり：
CR = %d13
CR = %x0D
respectively specify the decimal and hexadecimal representation of
[US-ASCII] for carriage return.
それぞれキャリッジリターンの１０進数と１６進数の[US-ASCII]での表現の
指定です。
A concatenated string of such values is specified compactly, using a
period (".") to indicate a separation of characters within that
value. Hence:
このような値の連結文字列が、ピリオド(".")を値を示す文字列の区切りに
使って、小さく指定できます。それ故：
CRLF = %d13.10
ABNF permits the specification of literal text strings directly,
enclosed in quotation-marks. Hence:
ＡＢＮＦは、引用符で括った、直接のリテラルテキスト文字列を認めます。
それ故：
command = "command string"
Literal text strings are interpreted as a concatenated set of
printable characters.
リテラルテキスト文字列がプリント可能な文字の連結集合と解釈されます。
NOTE:
重要：
ABNF strings are case-insensitive and the character set for these
strings is us-ascii.
ＡＮＦ文字列は大文字小文字の違いを無視します、そしてこれらの文字列
の文字集合はus-asciiです。
Hence:
それ故：
rulename = "abc"
and:
と：
rulename = "aBc"
will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
"ABC".
は"abc"や"Abc"や"aBc"や"abC"や"ABc"や"aBC"や"AbC"や"ABC"と一致します。
To specify a rule that IS case SENSITIVE, specify the characters
individually.
大文字小文字の違いを識別する規則を指定するためには、個々に文字を
指定してください。
For example:
例えば：
rulename = %d97 %d98 %d99
or
または
rulename = %d97.98.99
will match only the string that comprises only the lowercased
characters, abc.
は小文字のabcだけを含む文字列にだけ一致するでしょう。
2.4. External Encodings
2.4. 外部コーディング
External representations of terminal value characters will vary
according to constraints in the storage or transmission environment.
Hence, the same ABNF-based grammar may have multiple external
encodings, such as one for a 7-bit US-ASCII environment, another for
a binary octet environment, and still a different one when 16-bit
Unicode is used. Encoding details are beyond the scope of ABNF,
although Appendix A (Core) provides definitions for a 7-bit US-ASCII
environment as has been common to much of the Internet.
最終値文字の外部表現が記憶装置あるいは送信環境での制約に従って変化す
るでしょう。それ故、同じＡＢＮＦベースの文法は複数の外部コーディング
をもつかもしれません、例えば、７ビット合衆国ＡＳＣＩＩ環境のコーディ
ング、バイナリオクテット環境のコーディング、１６ビットユニコードが使
われる場合です。付録Ａ（核）が、インターネットの多くに共通の７ビット
の合衆国ＡＳＣＩＩ環境の定義を提供しますが、コーディングの細部はＡＢ
ＮＦの範囲外です。
By separating external encoding from the syntax, it is intended that
alternate encoding environments can be used for the same syntax.
外部のコーディングを構文から分離することによって、別のコーディング環
境で同じ構文を使うことができるようにします。
3. OPERATORS
3. 演算子
3.1. Concatenation: Rule1 Rule2
3.1. 結合：規則１ 規則２
A rule can define a simple, ordered string of values (i.e., a
concatenation of contiguous characters) by listing a sequence of rule
names. For example:
規則は単純で、規則名の列ことによって順序付の値列（すなわち、文字列の
結合）を定義することができます。例えば：
foo = %x61 ; a
bar = %x62 ; b
mumble = foo bar foo
So that the rule <mumble> matches the lowercase string "aba".
この場合、規則<mumble>は小文字文字列"aba"に一致します。
LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing
model. A string of contiguous characters (values) is parsed
according to the rules defined in ABNF. For Internet specifications,
there is some history of permitting linear white space (space and
horizontal tab) to be freely and implicitly interspersed around major
constructs, such as delimiting special characters or atomic strings.
線形空白スペース：結合がＡＢＮＦ解析モデルの核にあります。文字(値)の
連続の文字列が、ＡＢＮＦで定義された規則で解析されます。インターネッ
ト仕様のために、特別な区切り文字や元始文字列などの主要な構成物の前後
に、自由にそして暗黙に分散して、空白スペース（空白か水平タブ）を許す
ある歴史があります。
NOTE:
重要：
This specification for ABNF does not provide for implicit
specification of linear white space.
このＡＢＮＦ仕様は空白スペースの暗黙の仕様を供給しません。
Any grammar that wishes to permit linear white space around
delimiters or string segments must specify it explicitly. It is
often useful to provide for such white space in "core" rules that are
then used variously among higher-level rules. The "core" rules might
be formed into a lexical analyzer or simply be part of the main
ruleset.
区切文字や文字列部分の前後に空白スペースを認めることを望む文法は明示
的に存在を指定しなくてはなりません。高レベルの規則でしばしば使われる
ので、「核心」規則でこのような空白スペースを備えることはしばしば有用
です。「核心」規則は語彙の分析者の中に形成されるか、あるいはただ主な
規則集合のの一部かもしれません。
3.2. Alternatives: Rule1 / Rule2
3.2. 選択：規則１／規則２
Elements separated by a forward slash ("/") are alternatives.
Therefore,
フォワードスラッシュ("/")で分割された要素は選択肢です。
それ故に、
foo / bar
will accept <foo> or <bar>.
は<foo>か<bar>を受け入れるでしょう。
NOTE:
重要：
A quoted string containing alphabetic characters is a special form
for specifying alternative characters and is interpreted as a
non-terminal representing the set of combinatorial strings with
the contained characters, in the specified order but with any
mixture of upper and lower case.
アルファベット文字を含む引用文字列は選択文字を指定することに対する
特別な形式で、指定された順の、任意の大文字小文字の組み合の、文字か
らなる組合せ文字列集合を示す非終端と解釈されます。
3.3. Incremental Alternatives: Rule1 =/ Rule2
3.3. 逐次選択：規則１＝／規則２
It is sometimes convenient to specify a list of alternatives in
fragments. That is, an initial rule may match one or more
alternatives, with later rule definitions adding to the set of
alternatives. This is particularly useful for otherwise, independent
specifications that derive from the same parent rule set, such as
often occurs with parameter lists. ABNF permits this incremental
definition through the construct:
選択肢の断片のリストを指定することはしばしば都合が良いです。すなわち、
最初の規則がいくつかの選択肢に一致し、後の規則定義が選択を付け加える
ものです。これは特に、共通の親規則集合から生じる独立の仕様で役立ち、
これはパラメータリストでしばしば起こります。ＡＢＮＦは概念としてこの
逐次的定義を認めます：
oldrule =/ additional-alternatives
So that the rule set
規則集合
ruleset = alt1 / alt2
ruleset =/ alt3
ruleset =/ alt4 / alt5
is the same as specifying
は以下の指定と同じす。
ruleset = alt1 / alt2 / alt3 / alt4 / alt5
3.4. Value Range Alternatives: %c##-##
3.4. 価範囲選択：％ｃ##-##
A range of alternative numeric values can be specified compactly,
using dash ("-") to indicate the range of alternative values. Hence:
ダッシュを選択数値範囲として選択数値の範囲を簡単に指定できます。それ
故：
DIGIT = %x30-39
is equivalent to:
は以下と同等です：
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
Concatenated numeric values and numeric value ranges cannot be
specified in the same string. A numeric value may use the dotted
notation for concatenation or it may use the dash notation to specify
one value range. Hence, to specify one printable character between
end of line sequences, the specification could be:
連結された数値と数価範囲が同じ文字列で指定できません。数値の結合のた
めにドット表記法を使うかもしれません、あるいは１つの数値範囲を指定す
るためにダッシュ表記を使うかもしれません。それ故、行の終わりの間の印
刷可能文字を指定する仕様は以下であり得ます：
char-line = %x0D.0A %x20-7E %x0D.0A
3.5. Sequence Group: (Rule1 Rule2)
3.5. 順序グループ：（規則１ 規則２）
Elements enclosed in parentheses are treated as a single element,
whose contents are STRICTLY ORDERED. Thus,
括弧に囲まれた要素は、中身が厳密に順序付の、単一要素として取り扱われ
ます。それで、
elem (foo / bar) blat
matches (elem foo blat) or (elem bar blat), and
は(elem foo blat)あるいは(elem bar blat)に一致します、そして
elem foo / bar blat
matches (elem foo) or (bar blat).
は(elem foo)あるいは(bar blat)に一致します。
NOTE:
重要：
It is strongly advised that grouping notation be used, rather than
relying on the proper reading of "bare" alternations, when
alternatives consist of multiple rule names or literals.
選択肢が多数の規則名あるいはリテラルから成り立つ時、「露出」選択肢に
対する適切な読み方に頼るより、グループ表記を使われることが強く推奨
されます。
Hence, it is recommended that the following form be used:
それ故、次の書式が使われることが勧められます：
(elem foo) / (bar blat)
It will avoid misinterpretation by casual readers.
それは何気ない読者による誤解を避けるでしょう。
The sequence group notation is also used within free text to set off
an element sequence from the prose.
順序グループ表記はフリーテキストでも使われ、散文からの要素列を引き起こ
すはずです。
3.6. Variable Repetition: *Rule
3.6. 可変繰返：＊規則
The operator "*" preceding an element indicates repetition. The full
form is:
要素より先にある演算子"*"は反復を示します。完全形式は以下です：
<a>*<b>element
where <a> and <b> are optional decimal values, indicating at least
<a> and at most <b> occurrences of the element.
少なくとも<a>と<b>は任意指定の１０進数値で、少なくとも<a>で最大<a>の
要素の存在を示します。
Default values are 0 and infinity so that *<element> allows any
number, including zero; 1*<element> requires at least one;
3*3<element> allows exactly 3 and 1*2<element> allows one or two.
デフォルト値が０と無限で、*<element>はゼロを含む任意の数になります；
1*<element>は最小１つです；3*3<element>は正確に３を許し、ます、
1*2<element>は１か２を許します。
3.7. Specific Repetition: nRule
3.7. 特定繰返し：ｎ規則
A rule of the form:
形式の規則：
<n>element
is equivalent to
は以下と同等です。
<n>*<n>element
That is, exactly <n> occurrences of <element>. Thus, 2DIGIT is a 2-
digit number, and 3ALPHA is a string of three alphabetic characters.
これは、正確に<n>の<element>の存在です。それで2DIGITは２桁の数で、
3ALPHAは３つのアルファベット文字列です。
3.8. Optional Sequence: [RULE]
3.8. 任意順序：［規則］
Square brackets enclose an optional element sequence:
任意の要素の連続を角括弧で囲みます：
[foo bar]
is equivalent to
は以下と同等です。
*1(foo bar).
3.9. Comment: ; Comment
3.9. コメント：；コメント
A semi-colon starts a comment that continues to the end of line.
This is a simple way of including useful notes in parallel with the
specifications.
セミコロンから行の終わりまでがコメントです。これは仕様書と並列に有用
なメモを書く単純な方法です。
3.10. Operator Precedence
3.10. 演算子優先度
The various mechanisms described above have the following precedence,
from highest (binding tightest) at the top, to lowest (loosest) at
the bottom:
上に記述された種々のメカニズムは次の優先度を持ちます、上が優先（結合
が強い）で、下が非優先（緩い）です：
Strings, Names formation
文字列、名前生成
Comment
コメント
Value range
値範囲
Repetition
繰り返し
Grouping, Optional
グループ、任意
Concatenation
結合
Alternative
選択
Use of the alternative operator, freely mixed with concatenations,
can be confusing.
選択演算子の使用は、結合と入り混じると、紛らわしくなり得ます。
Again, it is recommended that the grouping operator be used to
make explicit concatenation groups.
再び、明示的な結合のグループ化のためにグループ演算子を使うことが
勧められます。
4. ABNF DEFINITION OF ABNF
4. ＡＢＮＦのＡＢＮＦでの定義
NOTES:
メモ：
1. This syntax requires a formatting of rules that is relatively
strict. Hence, the version of a ruleset included in a
specification might need preprocessing to ensure that it can be
interpreted by an ABNF parser.
1. この構文は比較的厳密な規則のフォーマット化を必要とします。それ
故、仕様書に含められた規則集合の版は、ＡＢＮＦ解析機が翻訳でき
ることを保証するため、事前処理にかける必要があるかもしれません。
2. This syntax uses the rules provided in Appendix B (Core).
2. この構文は付録Ｂ（核）で供給された規則を使います。
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 / "-")
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
; DQUOTE無しのSPとVCHARの引用文字列
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
; 連結ビット値の列、あるいはひとつの
; ONEOF範囲。
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) ">"
; bracketed string of SP and VCHAR
; without angles
; prose description, to be used as
; last resort
; SPとVCHARの文字列の、角なしの、括弧。
; 散文記述、最後の頼みの綱として用いられる。
5. SECURITY CONSIDERATIONS
5. セキュリティの考慮
Security is truly believed to be irrelevant to this document.
セキュリティがこの文書に関係がないと信ます。
6. References
6. 参考文献
6.1. Normative References
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. Informative References
6.2. 有益な参考文献
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[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.
Appendix A. ACKNOWLEDGEMENTS
付録Ａ．謝辞
The syntax for ABNF was originally specified in RFC 733. Ken L.
Harrenstien, of SRI International, was responsible for re-coding the
BNF into an augmented BNF that makes the representation smaller and
easier to understand.
ＡＢＮＦの構文は元々RFC 733で指定されました。ＳＲＩインターナショナ
ルのKen L. HarrenstienはＢＮＦを、小さくて理解しやすい拡張ＢＮＦに再
コード化の責任がありました。
This recent project began as a simple effort to cull out the portion
of RFC 822 that has been repeatedly cited by non-email specification
writers, namely the description of augmented BNF. Rather than simply
and blindly converting the existing text into a separate document,
the working group chose to give careful consideration to the
deficiencies, as well as benefits, of the existing specification and
related specifications made available over the last 15 years, and
therefore to pursue enhancement. This turned the project into
something rather more ambitious than was first intended.
Interestingly, the result is not massively different from that
original, although decisions, such as removing the list notation,
came as a surprise.
この最近のプロジェクトは、、非電子メールの仕様書の著者が繰り返したＲＦ
Ｃ８２２の一部、すなわち拡張ＢＮＦで記述したものを、切り出す単純な努
力として始まりました。ただ、そしてやみくもに既存のテキストを別の文書
に変換するより、作業班はこれまでの１５年にわたる既存の仕様書と関連し
た仕様書の、利点と欠点に注意深い考慮をする事を選択し、それ故に拡張を
追跡しました。これはプロジェクトを最初の意図より何か意欲的なものに変
えました。興味深い事に、リスト注釈を取り去るような決定はあっても、結
果は元の仕様と大きくは異ならず、驚きました。
This "separated" version of the specification was part of the DRUMS
working group, with significant contributions from Jerome Abela,
Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom
Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete
Resnick, and Henning Schulzrinne.
この仕様書の「切り離された」版は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 warrants a special thanks for converting the Draft
Standard version to XML source form.
ドラフト標準版を XML情報源形式に変換することに対して、
Julian Reschkeに特別な感謝をします。
Appendix B. APPENDIX - CORE ABNF OF ABNF
付録Ｂ．付録−ＡＢＮＦの核ＡＢＮＦ
This Appendix is provided as a convenient core for specific grammars.
The definitions may be used as a core set of rules.
この付録は便利な核として特定の文法に提供されます。定義は規則の核集合
心として用いられるかもしれません。
B.1. Core Rules
B.1. 核規則
Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT,
ALPHA, etc.
ある特定の基本的な規則が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
; NULを除く任意の７ビットASCII文字
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)
; linear white space (past newline)
; 連続空白スペース（過去の改行）。
OCTET = %x00-FF
; 8 bits of data
; ８ビットデータ
SP = %x20
VCHAR = %x21-7E
; visible (printing) characters
; 可視（印刷可能）文字
WSP = SP / HTAB
; white space
; 空白スペース
B.2. Common Encoding
B.2. 共通コーディング
Externally, data are represented as "network virtual ASCII" (namely,
7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
zero. A string of values is in "network byte order", in which the
higher-valued bytes are represented on the left-hand side and are
sent over the network first.
外部的に、「ネットワーク仮想ＡＳＣＩＩ」（８ビットフィールド内の７ビッ
ト合衆国ＡＳＣＩＩ）として描かれ、上位（第８）ビットはゼロが設定され
ます。値列は「ネットワークバイト順」で、上位バイトが左側で表され、そ
して最初にネットワークに送られます。
Authors' Addresses
著者のアドレス
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
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2005).
著作権（Ｃ）インターネット学会（２００５）。
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 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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、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@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。