この文書はRFC4234の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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
                構文のための拡張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).

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.
   インターネット技術仕様書がしばしば正式の構文を定義する必要があります。
   これまで、拡張BNF(ABNF)と呼ばれる、バッカス・ナウア記法(BN
   F)の修正版、多くのインターネット仕様書の間で人気でした。この仕様書は
   ABNFを文書化します。これは、妥当な具象力で、小ささと単純さのバラン
   スをとります。標準BNFとABNFの相違は命名規則、反復、選択肢、順序
   独立と値範囲を含みます。この仕様書はいくつかのインターネット仕様書に共
   通の種類の核心となる語彙分析のための追加の規則定義とコーディングを供給
   します。


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.  結合:規則1 規則2
      3.2.  Alternatives:  Rule1 / Rule2
      3.2.  選択:規則1/規則2
      3.3.  Incremental Alternatives: Rule1 =/ Rule2
      3.3.  逐次選択:規則1=/規則2
      3.4.  Value Range Alternatives:  %c##-##
      3.4.  価範囲選択:%c##-##
      3.5.  Sequence Group:  (Rule1 Rule2)
      3.5.  順序グループ:(規則1 規則2)
      3.6.  Variable Repetition:  *Rule
      3.6.  可変繰返:*規則
      3.7.  Specific Repetition:  nRule
      3.7.  特定繰返し:n規則
      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.  ABNFのABNFでの定義
   5.  SECURITY CONSIDERATIONS
   5.  セキュリティの考慮
   6.  References
   6.  参考文献
      6.1.  Normative References
      6.1.  参照する参考文献

      6.2.  Informative References
      6.2.  有益な参考文献
   Appendix A.  ACKNOWLEDGEMENTS
   付録A.謝辞
   Appendix B.  APPENDIX - CORE ABNF OF ABNF
   付録B.付録−ABNFの核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.
   技術的なインターネット仕様書がしばしば正式の構文を定義する必要があり、
   それらの著者が有用であるとみなす任意の表記法を使用できます。何年もの
   間、拡張BNF(ABNF)と呼ばれる、バッカス・ナウア記法(BNF)
   の修正版が、多くのインターネット仕様書の間で人気でした。これは、妥当
   な具象力で、小ささと単純さのバランスをとります。アーパーネットの初期
   には、それぞれの仕様書がそれ自身のABNFの定義を含んでいました。こ
   れは電子メール仕様書、[RFC733]とその後の[RFC822]を含み、そしてこれは
   ABNFを定義する際の共通の引用になりました。現在の文書は選択的な参
   照を認めるためにそれらの定義を切り離します。予想どおり、これはある修
   正と拡張を供給します。

   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.
   標準BNFとABNFの相違は命名規則、反復、選択肢、順序独立と値範囲
   を含みます。この仕様書はいくつかのインターネット仕様書に共通の種類の
   核心となる語彙分析のための追加の規則定義とコーディングを供給します。
   付録Bがいくつかのインターネット仕様書に共通の種類の核心の語彙分析の
   ために規則定義とコーディングを供給します。これは便利な道具として供給
   され、そしてこの文書の本体で定義されたメタ言語とは独立で、正式の状態
   とは独立です。

   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で、句「それは、<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.
   オリジナルのBNFと違い、山括弧("<", ">")は必要ありません。しかし
   ながら、山括弧があることで規則名の使用の認識を容易にする時はいつでも、
   規則名の周囲で使われるかもしれません。これは一般に、下記の反復の議論
   で示されるように、自由形式や空白スペースで分割されていない文字列に結
   合された部分規則の区別での引用での規則名の参照を制限します。

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>は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
                        2進数

         d           =  decimal
                        10進数

         x           =  hexadecimal
                        16進数

   Hence:
   つまり:

         CR          =  %d13

         CR          =  %x0D

   respectively specify the decimal and hexadecimal representation of
   [US-ASCII] for carriage return.
   それぞれキャリッジリターンの10進数と16進数の[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:
   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.
      ANF文字列は大文字小文字の違いを無視します、そしてこれらの文字列
      の文字集合は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.
   最終値文字の外部表現が記憶装置あるいは送信環境での制約に従って変化す
   るでしょう。それ故、同じABNFベースの文法は複数の外部コーディング
   をもつかもしれません、例えば、7ビット合衆国ASCII環境のコーディ
   ング、バイナリオクテット環境のコーディング、16ビットユニコードが使
   われる場合です。付録A(核)が、インターネットの多くに共通の7ビット
   の合衆国ASCII環境の定義を提供しますが、コーディングの細部はAB
   NFの範囲外です。

   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.  結合:規則1 規則2

   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.
   線形空白スペース:結合が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.
   区切文字や文字列部分の前後に空白スペースを認めることを望む文法は明示
   的に存在を指定しなくてはなりません。高レベルの規則でしばしば使われる
   ので、「核心」規則でこのような空白スペースを備えることはしばしば有用
   です。「核心」規則は語彙の分析者の中に形成されるか、あるいはただ主な
   規則集合のの一部かもしれません。

3.2.  Alternatives:  Rule1 / Rule2
3.2.  選択:規則1/規則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.  逐次選択:規則1=/規則2

   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:
   選択肢の断片のリストを指定することはしばしば都合が良いです。すなわち、
   最初の規則がいくつかの選択肢に一致し、後の規則定義が選択を付け加える
   ものです。これは特に、共通の親規則集合から生じる独立の仕様で役立ち、
   これはパラメータリストでしばしば起こります。ABNFは概念としてこの
   逐次的定義を認めます:

         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.  価範囲選択:%c##-##

   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:
   連結された数値と数価範囲が同じ文字列で指定できません。数値の結合のた
   めにドット表記法を使うかもしれません、あるいは1つの数値範囲を指定す
   るためにダッシュ表記を使うかもしれません。それ故、行の終わりの間の印
   刷可能文字を指定する仕様は以下であり得ます:

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

3.5.  Sequence Group:  (Rule1 Rule2)
3.5.  順序グループ:(規則1 規則2)

   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>は任意指定の10進数値で、少なくとも<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.
   デフォルト値が0と無限で、*<element>はゼロを含む任意の数になります;
   1*<element>は最小1つです;3*3<element>は正確に3を許し、ます、
   1*2<element>は1か2を許します。

3.7.  Specific Repetition:  nRule
3.7.  特定繰返し:n規則

   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は2桁の数で、
   3ALPHAは3つのアルファベット文字列です。

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.  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. この構文は比較的厳密な規則のフォーマット化を必要とします。それ
         故、仕様書に含められた規則集合の版は、ABNF解析機が翻訳でき
         ることを保証するため、事前処理にかける必要があるかもしれません。

      2. This syntax uses the rules provided in Appendix B (Core).
      2. この構文は付録B(核)で供給された規則を使います。

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

         rule           =  rulename defined-as elements c-nl
                                 ; continues if next line starts
                                 ;  with white space
                                ; もし次の行が空白スペースから始まる
                                ; なら、継続します。

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

         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
付録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の構文は元々RFC 733で指定されました。SRIインターナショナ
   ルのKen 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.
   この最近のプロジェクトは、、非電子メールの仕様書の著者が繰り返したRF
   C822の一部、すなわち拡張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作業班の仕事で、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
付録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.
   この付録は便利な核として特定の文法に提供されます。定義は規則の核集合
   心として用いられるかもしれません。

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を除く任意の7ビットASCII文字

         CR             =  %x0D
                                 ; carriage return
                                ; キャリッジリターン

         CRLF           =  CR LF
                                 ; Internet standard newline
                                ; インターネット標準改行

         CTL            =  %x00-1F / %x7F
                                 ; controls
                                ; 制御文字

         DIGIT          =  %x30-39
                                 ; 0-9
                                ; 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
                                ; 8ビットデータ

         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.
   外部的に、「ネットワーク仮想ASCII」(8ビットフィールド内の7ビッ
   ト合衆国ASCII)として描かれ、上位(第8)ビットはゼロが設定され
   ます。値列は「ネットワークバイト順」で、上位バイトが左側で表され、そ
   して最初にネットワークに送られます。


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).
   著作権(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.
   この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
   者が代表するか貢献者を後援する組織(もしあれば)とインターネット学会
   とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
   報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、全ての保証を拒否します。

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は何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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.
   IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、http://www.ietf.org/iprにあるIETFオンライン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は興味を持った誰からでもこの標準を実行するのに必要な技術をカ
   バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
   めます。どうかietf-ipr@ietf.orgのIETFに情報を伝えてください。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So