RFC4234 日本語訳

Network Working Group                                    D. Crocker, Ed.
Request for Comments: 4234                   Brandenburg InternetWorking
Obsoletes: 2234                                               P. Overell
Category: Standards Track                                      THUS plc.
                                                            October 2005

ワーキンググループのD.クロッカー、エドをネットワークでつないでください。コメントのために以下を要求してください。 4234年のブランデンブルクインターネットワーキングは以下を時代遅れにします。 2234年のP.Overellカテゴリ: 規格Track THUS plc。 2005年10月

             Augmented BNF for Syntax Specifications: ABNF

構文仕様のための増大しているBNF: 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.

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

インターネット技術仕様書は、しばしば正式な構文を定義する必要があります。 数年間、Augmented BNF(ABNF)と呼ばれるBN記法(BNF)の変更されたバージョンは多くのインターネット仕様の中でポピュラーです。 現在の仕様はABNFを記録します。 それは妥当な具象主義のパワーとコンパクト性と簡単さのバランスをとっています。 標準のBNFとABNFの違いは、規則、反復、代替手段、オーダー独立、および値を範囲と命名することを伴います。 また、この仕様はいくつかのインターネット仕様に共通のタイプのコアの語彙分析器のための付則定義とコード化を供給します。

Crocker & Overell           Standards Track                     [Page 1]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[1ページ]。

Table of Contents

目次

   1. INTRODUCTION ....................................................2
   2. RULE DEFINITION .................................................3
      2.1. Rule Naming ................................................3
      2.2. Rule Form ..................................................3
      2.3. Terminal Values ............................................4
      2.4. External Encodings .........................................5
   3. OPERATORS .......................................................6
      3.1. Concatenation:  Rule1 Rule2 ................................6
      3.2. Alternatives:  Rule1 / Rule2 ...............................6
      3.3. Incremental Alternatives: Rule1 =/ Rule2 ...................7
      3.4. Value Range Alternatives:  %c##-## .........................7
      3.5. Sequence Group:  (Rule1 Rule2) .............................8
      3.6. Variable Repetition:  *Rule ................................8
      3.7. Specific Repetition:  nRule ................................9
      3.8. Optional Sequence:  [RULE] .................................9
      3.9. Comment:  ; Comment ........................................9
      3.10. Operator Precedence .......................................9
   4. ABNF DEFINITION OF ABNF ........................................10
   5. SECURITY CONSIDERATIONS ........................................11
   6. References .....................................................11
      6.1. Normative References ......................................11
      6.2. Informative References ....................................11
   Appendix A.  ACKNOWLEDGEMENTS .....................................13
   Appendix B.  APPENDIX - CORE ABNF OF ABNF .........................13
      B.1.  Core Rules ...............................................13
      B.2.  Common Encoding ..........................................14

1. 序論…2 2. 定義を統治してください…3 2.1. 命名を統治してください…3 2.2. フォームを統治してください…3 2.3. 端末の値…4 2.4. 外部のEncodings…5 3. オペレータ…6 3.1. 連結: Rule1 Rule2…6 3.2. 代替手段: Rule1 / Rule2…6 3.3. 増加の代替手段: Rule1=/Rule2…7 3.4. 範囲代替手段を評価してください: %c####…7 3.5. 系列グループ: (Rule1 Rule2) .............................8 3.6. 可変反復: *統治してください…8 3.7. 特定の反復: nRule…9 3.8. 任意の系列: [規則]…9 3.9. コメント: ; コメントしてください…9 3.10. オペレータ先行…9 4. ABNFのABNF定義…10 5. セキュリティ問題…11 6. 参照…11 6.1. 標準の参照…11 6.2. 有益な参照…11 付録A.承認…13付録B.付録--ABNFのコアABNF…13 B.1。 コアは統治されます…13 B.2。 一般的なコード化…14

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.

インターネット技術仕様書は、しばしば正式な構文を定義するのが必要であり、無料で、彼らの作者が役に立つと考えるどんな記法も使うことができます。 数年間、Augmented BNF(ABNF)と呼ばれるBN記法(BNF)の変更されたバージョンは多くのインターネット仕様の中でポピュラーです。 それは妥当な具象主義のパワーとコンパクト性と簡単さのバランスをとっています。 Arpanetの初期では、各仕様はそれ自身のABNFの定義を含みました。 メール仕様、[RFC733]が含まれていて、次にABNFを定義するための一般的な引用であることを来た[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

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

Crocker & Overell           Standards Track                     [Page 2]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[2ページ]。

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

セクション3.7、句で: 「すなわち、まさに<要素>の<N>発生」、以下のことのために修正されました。 「すなわち、まさに<要素>の<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).

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

   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.

オリジナルの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つ以上の規則名、そして/または、値の定義の系列を形成します、代替手段や反復のように。

Crocker & Overell           Standards Track                     [Page 3]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[3ページ]。

   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進と等しいです。

   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 a separation of characters within that
   value.  Hence:

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

         CRLF        =  %d13.10

CRLF=%d13.10

   ABNF permits the specification of literal text strings directly,
   enclosed in quotation-marks.  Hence:

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

         command     =  "command string"

コマンド=「コマンドストリング」

   Literal text strings are interpreted as a concatenated set of
   printable characters.

文字通りのテキスト文字列は連結されたセットの印刷可能なキャラクタとして解釈されます。

Crocker & Overell           Standards Track                     [Page 4]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[4ページ]。

   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 that 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

   will match only the string that comprises only the 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.

構文からの外部のコード化を切り離すことによって、同じ構文に環境をコード化する補欠は使用できることを意図します。

Crocker & Overell           Standards Track                     [Page 5]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[5ページ]。

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 freely and implicitly interspersed around major
   constructs, such as delimiting special characters or atomic strings.

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

   NOTE:

以下に注意してください。

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

ABNFのためのこの仕様は直線的な余白の暗黙の仕様に備えません。

   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.

それがデリミタかストリング・セグメントの周りの直線的な余白を可能にしたがっているどんな文法も明らかにそれを指定しなければなりません。 次によりハイレベルの規則の中でさまざまに使用される「コア」規則でそのような余白に備えるのはしばしば役に立ちます。 「コア」規則は、語彙分析器の中に形成されるか、単に主なrulesetの一部であるかもしれません。

3.2.  Alternatives:  Rule1 / Rule2

3.2. 代替手段: Rule1 / Rule2

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

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

         foo / bar

foo/バー

   will accept <foo> or <bar>.

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

Crocker & Overell           Standards Track                     [Page 6]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[6ページ]。

   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. 増加の代替手段: 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 that 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と等しいです。

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

同じストリングで連結された数値と数値範囲を指定できません。 数値が連結に点を打たされた記法を使用するかもしれませんか、またはそれは、指定するのにダッシュ記法を使用するかもしれません。

Crocker & Overell           Standards Track                     [Page 7]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[7ページ]。

   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

   matches (elem foo blat) or (elem bar blat), and

そしてマッチ(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 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)

(elem foo)/(バー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

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

   where <a> and <b> are optional decimal values, indicating at least
   <a> and at most <b> occurrences of the 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を許容します。

Crocker & Overell           Standards Track                     [Page 8]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[8ページ]。

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:  ; 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

ストリング、Names構成

         Comment

コメント

         Value range

値の範囲

         Repetition

反復

         Grouping, Optional

分類していて、任意です。

         Concatenation

連結

         Alternative

代替手段

Crocker & Overell           Standards Track                     [Page 9]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[9ページ]。

   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定義

   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. この構文は規則の比較的厳しい形式を必要とします。 したがって、仕様にrulesetを含むバージョンは、ABNFパーサでそれを解釈できるのを保証するために前処理する必要があるかもしれません。

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

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

         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、連結)

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

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

         repetition     =  [repeat] element

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

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

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

Crocker & Overell           Standards Track                    [Page 10]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[10ページ]。

         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と等しいです。 SPとVCHARに関する引用文字列。 DQUOTEなしで

         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.

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

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.

[米国-ASCII] American National Standards Institut、「7コード化文字集合--ビット、情報交換用米国標準コード、」、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.

[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

Crocker & Overell           Standards Track                    [Page 11]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[11ページ]。

   [RFC733]   Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
              "Standard for the format of ARPA network text messages",
              RFC 733, November 1977.

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

   [RFC822]   Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

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

Crocker & Overell           Standards Track                    [Page 12]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[12ページ]。

Appendix A.  ACKNOWLEDGEMENTS

付録A.承認

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

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

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

   Julian Reschke warrants a special thanks for converting the Draft
   Standard version to XML source form.

ジュリアンReschkeは、Draft StandardバージョンをXMLソースに変換することの感謝が形成されるのを特別番組に保証します。

Appendix B.  APPENDIX - CORE ABNF OF ABNF

付録B.付録--ABNFのコアABNF

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

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

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          =  %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等しいです。 どんな7ビットの米国-ASCII文字も。 NULを除いて

Crocker & Overell           Standards Track                    [Page 13]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[13ページ]。

         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

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

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

         WSP            =  SP / HTAB
                                ; white space

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

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.

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

Crocker & Overell           Standards Track                    [Page 14]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[14ページ]。

Authors' Addresses

作者のアドレス

   Dave Crocker (editor)
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale, CA  94086
   US

デーヴ医者(エディタ)ブランデンブルクインターネットワーキング675は米国でサニーベル博士、カリフォルニア 94086を小綺麗にします。

   Phone: +1.408.246.8253
   EMail: dcrocker@bbiw.net

以下に電話をしてください。 +1.408 .246 .8253 メール: dcrocker@bbiw.net

   Paul Overell
   THUS plc.
   1/2 Berkeley Square
   99 Berkeley Street
   Glasgow
   G3 7HR
   UK

ポールOverell THUS plc。 1/2バークレー・スクエア99バークリー・ストリートグラスゴーG3 7HRイギリス

   EMail: paul.overell@thus.net

メール: paul.overell@thus.net

Crocker & Overell           Standards Track                    [Page 15]

RFC 4234                          ABNF                      October 2005

クロッカーとOverell規格はABNF2005年10月にRFC4234を追跡します[15ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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はこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Crocker & Overell           Standards Track                    [Page 16]

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