RFC2234 日本語訳

Network Working Group                                     D. Crocker, Ed.
Request for Comments: 2234                       Internet Mail Consortium
Category: Standards Track                                      P. Overell
                                                      Demon Internet Ltd.
                                                            November 1997

ワーキンググループのD.クロッカー、エドをネットワークでつないでください。コメントのために以下を要求してください。 2234年のインターネットメール共同体カテゴリ: 標準化過程P.Overell悪霊インターネット株式会社1997年11月

             Augmented BNF for Syntax Specifications: ABNF

構文仕様のための増大しているBNF: ABNF

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Copyright(C)インターネット協会(1997)。 All rights reserved。

TABLE OF CONTENTS

目次

   1. INTRODUCTION ..................................................  2

1. 序論… 2

   2. RULE DEFINITION ...............................................  2
   2.1 RULE NAMING ..................................................  2
   2.2 RULE FORM ....................................................  3
   2.3 TERMINAL VALUES ..............................................  3
   2.4 EXTERNAL ENCODINGS ...........................................  5

2. 定義を統治してください… 2 2.1 命名を統治してください… 2 2.2 フォームを統治してください… 3 2.3 端末の値… 3 2.4 外部のENCODINGS… 5

   3. OPERATORS .....................................................  5
   3.1 CONCATENATION    RULE1     RULE2 .............................  5
   3.2 ALTERNATIVES RULE1 / RULE2 ...................................  6
   3.3 INCREMENTAL ALTERNATIVES   RULE1 =/ RULE2 ....................  6
   3.4 VALUE RANGE ALTERNATIVES   %C##-## ...........................  7
   3.5 SEQUENCE GROUP (RULE1 RULE2) .................................  7
   3.6 VARIABLE REPETITION *RULE ....................................  8
   3.7 SPECIFIC REPETITION NRULE ....................................  8
   3.8 OPTIONAL SEQUENCE [RULE] .....................................  8
   3.9 ; COMMENT ....................................................  8
   3.10 OPERATOR PRECEDENCE .........................................  9

3. オペレータ… 5 3.1 連結RULE1 RULE2… 5 3.2 代替手段RULE1 / RULE2… 6 3.3 増加の代替手段RULE1=/RULE2… 6 3.4 範囲代替手段%C####、を評価してください… 7 3.5 系列グループ(RULE1 RULE2)… 7 3.6の可変反復*は統治されます… 8 3.7 特定の反復NRULE… 8 3.8 任意の系列[規則]… 8 3.9 ; コメントしてください… 8 3.10 オペレータ先行… 9

   4. ABNF DEFINITION OF ABNF .......................................  9

4. ABNFのABNF定義… 9

   5. SECURITY CONSIDERATIONS ....................................... 10

5. セキュリティ問題… 10

Crocker & Overell           Standards Track                     [Page 1]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[1ページ]。

   6. APPENDIX A - CORE ............................................. 11
   6.1 CORE RULES ................................................... 11
   6.2 COMMON ENCODING .............................................. 12

6. 付録A--芯を取ります。 11 6.1コアは統治されます… 11 6.2 コモンコード化… 12

   7. ACKNOWLEDGMENTS ............................................... 12

7. 承認… 12

   8. REFERENCES .................................................... 13

8. 参照… 13

   9. CONTACT ....................................................... 13

9. 連絡します。 13

   10. FULL COPYRIGHT STATEMENT ..................................... 14

10. 完全な著作権宣言文… 14

1.   INTRODUCTION

1. 序論

   Internet technical specifications often need to define a format
   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
   have come to be the common citations for defining ABNF.  The current
   document separates out that definition, to permit selective
   reference.  Predictably, it also provides some modifications and
   enhancements.

インターネット技術仕様書は、しばしば形式構文を定義するのが必要であり、無料で、彼らの作者が役に立つと考えるどんな記法も使うことができます。 数年間、Augmented BNF(ABNF)と呼ばれるBN記法(BNF)の変更されたバージョンは多くのインターネット仕様の中でポピュラーです。 それは妥当な具象主義のパワーとコンパクト性と簡単さのバランスをとっています。 Arpanetの初期では、各仕様はそれ自身のABNFの定義を含みました。 これは、ABNFを定義するためにメール仕様、RFC733を含んでいて、次に、一般的な引用であることを来たRFC822を含んでいました。 現在のドキュメントは、選択している参照を可能にするためにその定義を分離します。 また、予想どおりに、それはいくつかの変更と増進を提供します。

   The differences between standard BNF and ABNF involve naming rules,
   repetition, alternatives, order-independence, and value ranges.
   Appendix A (Core) 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.

標準のBNFとABNFの違いは、規則、反復、代替手段、オーダー独立、および値を範囲と命名することを伴います。 付録A(コア)はいくつかのインターネット仕様に共通のタイプのコアの語彙分析器のための規則定義とコード化を供給します。 それは、便利として提供されて、そうでなければ、このドキュメントのボディーで定義されたメタ言語から別々であって、正式な状態から別々です。

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).

規則の名前は単に名前自体です。 すなわち、英字で始まって、alphabeticsの組み合わせ、ケタ、およびハイフン(ダッシュ)があとに続いたキャラクタの系列。

        NOTE:     Rule names are case-insensitive

以下に注意してください。 規則名は大文字と小文字を区別しないです。

   The names <rulename>, <Rulename>, <RULENAME> and <rUlENamE> all refer
   to the same rule.

名前の<rulename>、<Rulename>、<RULENAME>、および<rUlENamE>は同じ規則をすべて示します。

Crocker & Overell           Standards Track                     [Page 2]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[2ページ]。

   Unlike original BNF, angle brackets ("<", ">") are not  required.
   However, angle brackets may be used around a rule name whenever their
   presence will facilitate 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.

オリジナルのBNFと異なって、角ブラケット("<"、">")は必要ではありません。 しかしながら、それらの存在が、規則名の使用について明察するのを容易にするときはいつも、角ブラケットは規則名の周りで使用されるかもしれません。 これは、自由形式散文における名前参照を統治するか、または以下の反復についての議論で示されて、余白によって分離されなかったストリングに結合する部分的な規則を区別するために通常制限されます。

2.2  Rule Form

2.2 規則フォーム

   A rule is defined by the following sequence:

規則は以下の系列によって定義されます:

        name =  elements crlf

名前=要素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.

-<名前>が規則の名前であり、<要素>が1つ以上の規則名か端末の仕様であり、<crlf>が終わりであるところに、線インディケータでは、改行で復帰は続きました。 等号は規則の定義と名前を切り離します。 要素は本書では定義された様々なオペレータによると、結合された1つ以上の規則名、そして/または、値の定義の系列を形成します、代替手段や反復のように。

   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では、キャラクタは単に非負の整数です。 ある文脈では、文字の組(ASCIIなどの)への値の特定のマッピング(コード化する)は指定されるでしょう。

   Terminals are specified by one or more numeric characters with the
   base interpretation of those characters indicated explicitly.  The
   following bases are currently defined:

それらのキャラクタのベース解釈が明らかに示されている状態で、端末は1つ以上の数字によって指定されます。 以下のベースは現在、定義されます:

        b           =  binary

bはバイナリーと等しいです。

        d           =  decimal

dは小数と等しいです。

        x           =  hexadecimal

xは16進と等しいです。

Crocker & Overell           Standards Track                     [Page 3]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[3ページ]。

   Hence:

したがって:

        CR          =  %d13

CR=%d13

        CR          =  %x0D

CR=%x0D

   respectively specify the decimal and hexadecimal representation of
   [US-ASCII] for carriage return.

それぞれ復帰のための[米国-ASCII]の小数と16進表現を指定してください。

   A concatenated string of such values is specified compactly, using a
   period (".") to indicate separation of characters within that value.
   Hence:

そのような値の連結されたストリングはコンパクトに指定されます、期間を費やして(「」、)、その値の中にキャラクタの離別を示すために。 したがって:

        CRLF        =  %d13.10

CRLF=%d13.10

   ABNF permits specifying literal text string directly, enclosed in
   quotation-marks.  Hence:

ABNFは、引用符で同封されて、直接文字通りのテキスト文字列を指定するのを可能にします。 したがって:

        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.

以下に注意してください。 ABNFストリングが大文字と小文字を区別しなく、これらのストリングのための文字の組が大文字と小文字を区別しない、私たち、-、ASCII

   Hence:

したがって:

        rulename = "abc"

rulenameは"abc"と等しいです。

   and:

そして、:

        rulename = "aBc"

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 which IS case SENSITIVE,
                   specify the characters individually.

規則を指定するために、キャラクタは、ケースSENSITIVEがどれであるかと個別に指定します。

   For example:

例えば:

        rulename    =  %d97 %d98 %d99

rulename=%d97%d98%d99

   or

または

        rulename    =  %d97.98.99

rulename=%d97.98.99

Crocker & Overell           Standards Track                     [Page 4]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[4ページ]。

   will match only the string which comprises only lowercased
   characters, abc.

小文字で印刷されたキャラクタ、abcだけを含むストリングだけを合わせるでしょう。

2.4  External Encodings

2.4 外部のEncodings

   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.

格納かトランスミッション環境における規制に従って、端末の値のキャラクタの外部の表現は異なるでしょう。 16ビットのユニコードが使用されているとき、したがって、同じABNFベースの文法には、7ビットの米国-ASCII環境、2進の八重奏環境のための別のもの、およびそれでも、異なったもののためのものなどの外部の複数のencodingsがあるかもしれません。 コード化の詳細はABNFの範囲を超えています、Appendix A(コア)は一般的であったように7ビットの米国-ASCII環境のための定義をインターネットの大部分に提供しますが。

   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 連結Rule1 Rule2

   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

foo=%x61。 a

        bar         =  %x62           ; b

=%x62を禁じてください。 b

        mumble      =  foo bar foo

もぐもぐ=fooバーfoo

        So that the rule <mumble> matches the lowercase string "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 freelyPand
        implicitlyPinterspersed around major constructs, such as
        delimiting special characters or atomic strings.

直線的な余白: 連結がABNF構文解析モデルのコアにあります。 ABNFで定義された規則に従って、一連の隣接のキャラクタ(値)が分析されます。 インターネット仕様のために、主要な構造物の周りに直線的な余白(スペースと水平タブ)がfreelyPand implicitlyPinterspersedであることを許可する何らかの歴史があります、特殊文字か原子ストリングを区切るのなどように。

        NOTE:     This specification for ABNF does not
                  provide for implicit specification of linear white
                  space.

以下に注意してください。 ABNFのためのこの仕様は直線的な余白の暗黙の仕様に備えません。

   Any grammar which 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

直線的に可能にするというそれの願望がスペースを空白にするどんな文法もデリミタかストリング・セグメントの周りで明らかにそれを指定しなければなりません。 「コア」規則でそのような余白に備えるのはしばしば役に立ちます。

Crocker & Overell           Standards Track                     [Page 5]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[5ページ]。

   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.

よりハイレベルの規則の中でさまざまに使用されるその時。 「コア」規則は、語彙分析器の中に形成されるか、単に主なrulesetの一部であるかもしれません。

3.2  Alternatives                               Rule1 / Rule2

3.2 代替手段Rule1 / Rule2

   Elements separated by forward slash ("/") are alternatives.
   Therefore,

前進のスラッシュ(「/」)によって切り離された要素は代替手段です。 したがって

        foo / bar

foo/バー

   will accept <foo> or <bar>.

<foo>か<バー>を受け入れるでしょう。

        NOTE:     A quoted string containing alphabetic
                  characters is 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 増加の代替手段Rule1=/Rule2

   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 which derive from the same parent rule set, such as
   often occurs with parameter lists.  ABNF permits this incremental
   definition through the construct:

断片となって代替手段のリストを指定するのは時々便利です。 すなわち、初期の規則は1つ以上の選択肢に合うかもしれません、後の規則定義が代替手段のセットに加えていて。 これが特に同じ親規則セットに由来しているそうでなければ、独立している仕様の役に立つ、そのようなものは同じくらいしばしばパラメータ・リストで起こります。 ABNFは構造物を通したこの増加の定義を可能にします:

        oldrule     =/ additional-alternatives

oldruleの追加=/代替手段

   So that the rule set

規則がセットしたように

        ruleset     =  alt1 / alt2

rulesetはalt1 / alt2と等しいです。

        ruleset     =/ alt3

ruleset=/alt3

        ruleset     =/ alt4 / alt5

rulesetは/ alt4 / alt5と等しいです。

   is the same as specifying

指定するのと同じです。

        ruleset     =  alt1 / alt2 / alt3 / alt4 / alt5

rulesetはalt1/alt2/alt3/alt4/alt5と等しいです。

Crocker & Overell           Standards Track                     [Page 6]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[6ページ]。

3.4  Value Range Alternatives                           %c##-##

3.4 値の範囲代替手段%c####

   A range of alternative numeric values can be specified compactly,
   using dash ("-") to indicate the range of alternative values.  Hence:

代替の値の範囲を示すのにダッシュ(「-」)を使用して、コンパクトにさまざまな代替の数値を指定できます。 したがって:

        DIGIT       =  %x30-39

ケタ=%x30-39

   is equivalent to:

同等物はそうすることになっていますか?:

        DIGIT       =  "0" / "1" / "2" / "3" / "4" / "5" / "6" /

ケタ=、「0インチ/、「1インチ/、「2インチ/、「3インチ/、「4インチ/、「5インチ/「6インチ/」

                           "7" / "8" / "9"

"7" / "8" / "9"

   Concatenated numeric values and numeric value ranges can not 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:

同じストリングで連結された数値と数値範囲を指定できません。 数値が連結に点を打たされた記法を使用するかもしれませんか、またはそれは、1つの値の範囲を指定するのにダッシュ記法を使用するかもしれません。 したがって、行末系列の間では、仕様は、1つの印刷可能なキャラクタを指定するためには、以下の通りであるかもしれません。

        char-line = %x0D.0A %x20-7E %x0D.0A

炭線=%x0D.0A%x20-7ユーロの%x0D.0A

3.5  Sequence Group                             (Rule1 Rule2)

3.5 系列グループ(Rule1 Rule2)

   Elements enclosed in parentheses are treated as a single element,
   whose contents are STRICTLY ORDERED.   Thus,

括弧に同封された要素はコンテンツがSTRICTLY ORDEREDであるただ一つの要素として扱われます。 このようにして

        elem (foo / bar) blat

elem(foo/バー)blat

   which matches (elem foo blat) or (elem bar blat).

(elem foo blat)か(elemバーblat)を合わせます。

        elem foo / bar blat

elem foo/バーblat

   matches (elem foo) or (bar blat).

マッチ(elem foo)か(バーblat。)

        NOTE:     It is strongly advised to use grouping
                  notation, rather than to rely on proper reading of
                  "bare" alternations, when alternatives consist of
                  multiple rule names or literals.

以下に注意してください。 「むき出し」の交互の適切な読書を当てにするよりそれがむしろ組分け記法を使用するように強くアドバイスされます、代替手段が複数の規則名か誤字誤植から成ると。

   Hence it is recommended that instead of the above form, the form:

したがって、それは上のフォーム、フォームの代わりにそれに推薦されます:

        (elem foo) / (bar blat)

(elem foo)/(バーblat)

   be used.  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.

また、系列グループ記法は、散文から要素系列を引きたたせるのに無料のテキストの中で使用されます。

Crocker & Overell           Standards Track                     [Page 7]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[7ページ]。

3.6  Variable Repetition                                *Rule

3.6の可変反復*定規

   The operator "*" preceding an element indicates repetition. The full
   form is:

要素に先行する「*」というオペレータは反復を示します。 完全形は以下の通りです。

        <a>*<b>element

<は>*<b>要素です。

   where <a> and <b> are optional decimal values, indicating at least
   <a> and at most <b> occurrences of element.

要素の少なくとも<a>と高々<b>発生を示して、<a>と<b>が任意のデシマル値であるところで。

   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.

*デフォルト値が0と無限であるので、<要素>はゼロを含むどんな数も許容します。 1*<要素>は少なくとも1を必要とします。 3*3<要素>はちょうど>が許容する3と1*2<要素に1か2を許容します。

3.7  Specific Repetition                                  nRule

3.7 特定の反復nRule

   A rule of the form:

フォームの規則:

        <n>element

<n>要素

   is equivalent to

相当

        <n>*<n>element

<n>*<n>要素

   That is, exactly  <N>  occurrences  of <element>. Thus 2DIGIT is a
   2-digit number, and 3ALPHA is a string of three alphabetic
   characters.

すなわち、まさに<要素>の<N>発生。 したがって、2DIGITは2桁数です、そして、3ALPHAは一連の3つの英字です。

3.8  Optional Sequence                                   [RULE]

3.8 任意の系列[規則]

   Square brackets enclose an optional element sequence:

角括弧は随意的な要素系列を同封します:

        [foo bar]

[fooバー]

   is equivalent to

相当

        *1(foo bar).

*1 (fooバー。)

3.9  ; 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.

セミコロンは行末に続くコメントを始めます。 これは仕様と平行して役に立つ注意を含む簡単な方法です。

Crocker & Overell           Standards Track                     [Page 8]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[8ページ]。

3.10 Operator Precedence

3.10 オペレータ先行

   The various mechanisms described above have the following precedence,
   from highest (binding tightest) at the top, to lowest and loosest at
   the bottom:

上で説明された様々なメカニズムは以下の先行を持っています、先端の最も高さ(最もきつく付いて)から、下部で最も低く最もゆるく:

        Strings, Names formation
        Comment
        Value range
        Repetition
        Grouping, Optional
        Concatenation
        Alternative

ストリング、Names構成Comment Value範囲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. ABNFのABNF定義

   This syntax uses the rules provided in Appendix A (Core).

この構文はAppendix A(コア)に提供された規則を使用します。

        rulelist       =  1*( rule / (*c-wsp c-nl) )

rulelist=1*(規則/(*c-wsp c-nl))

        rule           =  rulename defined-as elements c-nl
                               ; continues if next line starts
                               ;  with white space

規則=rulenameは要素c-nlを定義づけました。 次の線が始動するなら、続きます。 余白で

        rulename       =  ALPHA *(ALPHA / DIGIT / "-")

rulenameはアルファー*と等しいです。(アルファ/ケタ/「-」)

        defined-as     =  *c-wsp ("=" / "=/") *c-wsp
                               ; basic rules definition and
                               ;  incremental alternatives

定義づけている=*c-wsp(「=」/「=/」)*c-wsp。 そして、基本的なルール定義、。 増加の代替手段

        elements       =  alternation *c-wsp

要素は交互*c-wspと等しいです。

        c-wsp          =  WSP / (c-nl WSP)

c-wspはWSP/と等しいです。(c-nl WSP)

        c-nl           =  comment / CRLF
                               ; comment or newline

c-nlはコメント/CRLFと等しいです。 コメントかニューライン

        comment        =  ";" *(WSP / VCHAR) CRLF

「コメント=」;、」 *(WSP / VCHAR) CRLF

        alternation    =  concatenation
                          *(*c-wsp "/" *c-wsp concatenation)

交互は連結*と等しいです。「(*c-wsp、」 /」 *c-wsp、連結)

Crocker & Overell           Standards Track                     [Page 9]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[9ページ]。

        concatenation  =  repetition *(1*c-wsp repetition)

連結は反復*と等しいです。(1*c-wsp反復)

        repetition     =  [repeat] element

反復は要素と等しいです[繰り返します]。

        repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)

=1*DIGIT/を繰り返してください。(*ケタ「*」*ケタ)

        element        =  rulename / group / option /
                          char-val / num-val / prose-val

要素=散文炭rulename/グループ/オプション/val/num-val/val

        group          =  "(" *c-wsp alternation *c-wsp ")"

「(「*c-wsp交互*c-wsp」)」というグループ=

        option         =  "[" *c-wsp alternation *c-wsp "]"

オプションは「[「*c-wsp交互*c-wsp」]」と等しいです。

        char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                               ; quoted string of SP and VCHAR
                                  without DQUOTE

炭-valはDQUOTE*(%x20-21/%x23-7E)DQUOTEと等しいです。 DQUOTEのないSPとVCHARに関する引用文字列

        num-val        =  "%" (bin-val / dec-val / hex-val)

num-val=「%」(十六進法DEC社容器-val/val/val)

        bin-val        =  "b" 1*BIT
                          [ 1*("." 1*BIT) / ("-" 1*BIT) ]
                               ; series of concatenated bit values
                               ; or single ONEOF range

容器-valが「b」1*BITと等しい、[1*、(「. 」 1*ビット) /(「-」1*ビット]。 連結された噛み付いている値のシリーズ。 または、独身のONEOFは及びます。

        dec-val        =  "d" 1*DIGIT
                          [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]

DEC社-valは「d」1*DIGITと等しいです。[1*、(「. 」 1*ケタ) /(「-」1*ケタ]

        hex-val        =  "x" 1*HEXDIG
                          [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]

十六進法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

散文-valは"<"*(%x3F%x20 3D/7E)">"と等しいです。 角度のないSPとVCHARの腕木を付けられたストリング。 記述に散文を書かせて、切り札として使用されてください。

5.   SECURITY CONSIDERATIONS

5. セキュリティ問題

   Security is truly believed to be irrelevant to this document.

本当に、セキュリティがこのドキュメントと無関係であると信じられています。

Crocker & Overell           Standards Track                    [Page 10]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[10ページ]。

6.   APPENDIX A - CORE

6. 付録A--コア

   This Appendix is provided as a convenient core for specific grammars.
   The definitions may be used as a core set of rules.

特定の文法のための便利なコアとしてこのAppendixを提供します。 定義は1人の巻き癖の規則として使用されるかもしれません。

6.1  Core Rules

6.1 コア規則

   Certain  basic  rules  are  in uppercase, such as SP, HTAB, CRLF,
   DIGIT, ALPHA, etc.

SP、HTAB、CRLF、DIGIT、アルファーなどの大文字には、ある基本的なルールがあります。

        ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z

アルファー=%x41-5A/%x61-7A。 a A-Z/z

        BIT            =  "0" / "1"

ビット=、「0インチ/「1インチ」

        CHAR           =  %x01-7F
                               ; any 7-bit US-ASCII character,
                                  excluding NUL

炭は%x01と-7F等しいです。 NULを除いたどんな7ビットの米国-ASCII文字

        CR             =  %x0D
                               ; carriage return

CR=%x0D。 復帰

        CRLF           =  CR LF
                               ; Internet standard newline

CRLFはCR LFと等しいです。 インターネット標準ニューライン

        CTL            =  %x00-1F / %x7F
                               ; controls

CTL=%のx00-1F/%のx7F。 コントロール

        DIGIT          =  %x30-39
                               ; 0-9

ケタ=%x30-39。 0-9

        DQUOTE         =  %x22
                               ; " (Double Quote)

DQUOTE=%x22。 " (二重引用文)

        HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

HEXDIGは/「B」/ケタ/「C」/「D」/「E」/「F」と等しいです。

        HTAB           =  %x09
                               ; horizontal tab

HTAB=%x09。 水平タブ

        LF             =  %x0A
                               ; linefeed

LF=%x0A。 ラインフィード

        LWSP           =  *(WSP / CRLF WSP)
                               ; linear white space (past newline)

LWSPは*(WSP / CRLF WSP)と等しいです。 直線的な余白(過去のニューライン)

        OCTET          =  %x00-FF
                               ; 8 bits of data

八重奏は%x00ffと等しいです。 8ビットのデータ

        SP             =  %x20

SP=%x20

Crocker & Overell           Standards Track                    [Page 11]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[11ページ]。

                               ; space

; スペース

        VCHAR          =  %x21-7E
                               ; visible (printing) characters

VCHARは%x21と-7E等しいです。 目に見える(印刷)キャラクタ

        WSP            =  SP / HTAB
                               ; white space

WSPはSP / HTABと等しいです。 余白

6.2  Common Encoding

6.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" with the
   higher-valued bytes represented on the left-hand side and being sent
   over the network first.

外部的に、「仮想のASCIIをネットワークでつなぐ」とき、データは表されます、すなわち、ゼロに設定された(8番目)の7ビットの8ビットの分野の高値による米国のASCIIのビット。 より高く評価されたバイトを左の方に表して、最初にネットワークの上に送る「ネットワークバイトオーダー」には一連の値があります。

7.   ACKNOWLEDGMENTS

7. 承認

   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.

ABNFのための構文は元々、RFC733で指定されました。 SRIインターナショナルのケンL.Harrenstienは、より小さくて、表現をより簡単にさせる増大しているBNFへのBNFを再コード化するのに理解している責任がありました。

   This recent project began as a simple effort to cull out the portion
   of RFC 822 which 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 available over the last 15 years and therefore
   to pursue enhancement.  This turned the project into something rather
   more ambitious than first intended.  Interestingly the result is not
   massively different from that original, although decisions such as
   removing the list notation came as a surprise.

この最近のプロジェクトは非メール仕様作家によって繰り返して引用された、RFC822の一部、すなわち、増大しているBNFの記述をえりのけるための簡単な努力として始まりました。 簡単に盲目的に既存のテキストを別々のドキュメントに変換するよりむしろ、ワーキンググループは、欠乏への熟慮、およびここ15年間利用可能な既存の仕様と関連する仕様の利益を与えて、したがって、増進を追求するのを選びました。 これはプロジェクトを最初に意図するよりかなり何か野心満々のものに変えました。 おもしろく、結果はそのオリジナルと膨大に異なっていません、リスト記法を取り除くことなどの決定が意外でしたが。

   The current round of 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ワーキンググループの一部でした、ジェロームAbelaからの重要な貢献、ハラルドAlvestrand、ロバートElz、ロジャーFajman、Avivaギャレット、トムHarsch、ダン・コーン、ビル・マッキラン、キース・ムーア、クリス・ニューマン、ピートレズニック、およびヘニングSchulzrinneと共に。

Crocker & Overell           Standards Track                    [Page 12]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[12ページ]。

8.   REFERENCES

8. 参照

   [US-ASCII]     Coded Character Set--7-Bit American Standard Code for
   Information Interchange, ANSI X3.4-1986.

[米国-ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。

   [RFC733]  Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
   "Standard for the Format of ARPA Network Text Message," RFC 733,
   November 1977.

[RFC733] クロッカー、D.、Vittal、J.、Pogran、K.、およびD.ヘンダーソン、「アーパネットテキストメッセージの形式の規格」、RFC733(1977年11月)。

   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822, August 1982.

[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。

9.   CONTACT

9. 接触

   David H. Crocker                 Paul Overell

デヴィッドH.医者ポールOverell

   Internet Mail Consortium         Demon Internet Ltd
   675 Spruce Dr.                   Dorking Business Park
   Sunnyvale, CA 94086 USA          Dorking
                                    Surrey, RH4 1HN
                                    UK

インターネットメール共同体悪霊インターネットLtd675えぞ松ドーキングビジネスパークサニーベル博士、カリフォルニア94086米国DorkingサリーRH4 1HNイギリス

   Phone:    +1 408 246 8253
   Fax:      +1 408 249 6205
   EMail:    dcrocker@imc.org       paulo@turnpike.com

以下に電話をしてください。 +1 408 246、8253Fax: +1 6205年の408 249メール: dcrocker@imc.org paulo@turnpike.com

Crocker & Overell           Standards Track                    [Page 13]

RFC 2234             ABNF for Syntax Specifications        November 1997

クロッカーとOverell規格は1997年11月に構文仕様のためにRFC2234ABNFを追跡します[13ページ]。

10.  Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Copyright(C)インターネット協会(1997)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Crocker & Overell           Standards Track                    [Page 14]

クロッカーとOverell標準化過程[14ページ]