Network Working Group A. Farrel
Request for Comments: 5511 Old Dog Consulting
Category: Standards Track April 2009
Network Working Group A. Farrel
Request for Comments: 5511 Old Dog Consulting
Category: Standards Track April 2009
Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications
路由Backus Naur Form（RBNF）：用于在各种路由协议规范中形成编码规则的语法
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.
在IETF的路由区域中，使用代表消息语法的Backus-Naur形式（BNF）的通用变体指定了若干协议。然而，对于这个版本的BNF没有正式的定义。
There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.
对于通常一起使用的协议集，使用相同的BNF变体是有价值的。这减少了混乱并简化了实现。
Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.
更新现有文件以使用已正式记录的BNF的其他变体将是一项重要的工作。
This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols.
本文档提供了已使用的BNF变体（我们称之为路由BNF）的正式定义，并使其可供新协议使用。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Existing Uses ..............................................3
1.3. Applicability Statement ....................................4
2. Formal Definitions ..............................................4
2.1. Rule Definitions ...........................................5
2.1.1. Rule Name Delimitation ..............................5
2.1.2. Objects .............................................5
2.1.3. Constructs ..........................................6
2.1.4. Messages ............................................6
2.2. Operators ..................................................6
2.2.1. Assignment ..........................................6
2.2.2. Concatenation .......................................7
2.2.3. Optional Presence ...................................7
2.2.4. Alternatives ........................................8
2.2.5. Repetition ..........................................9
2.2.6. Grouping ...........................................10
2.3. Editorial Conventions .....................................11
2.3.1. White Space ........................................11
2.3.2. Line Breaks ........................................11
2.3.3. Ordering ...........................................11
2.4. Precedence ................................................11
3. Automated Validation ...........................................13
4. Security Considerations ........................................13
5. Acknowledgments ................................................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Existing Uses ..............................................3
1.3. Applicability Statement ....................................4
2. Formal Definitions ..............................................4
2.1. Rule Definitions ...........................................5
2.1.1. Rule Name Delimitation ..............................5
2.1.2. Objects .............................................5
2.1.3. Constructs ..........................................6
2.1.4. Messages ............................................6
2.2. Operators ..................................................6
2.2.1. Assignment ..........................................6
2.2.2. Concatenation .......................................7
2.2.3. Optional Presence ...................................7
2.2.4. Alternatives ........................................8
2.2.5. Repetition ..........................................9
2.2.6. Grouping ...........................................10
2.3. Editorial Conventions .....................................11
2.3.1. White Space ........................................11
2.3.2. Line Breaks ........................................11
2.3.3. Ordering ...........................................11
2.4. Precedence ................................................11
3. Automated Validation ...........................................13
4. Security Considerations ........................................13
5. Acknowledgments ................................................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
Backus-Naur Form (BNF) has been used to specify the message formats of several protocols within the Routing Area of the IETF. Unfortunately, these specifications are not based on any specific formal definition of BNF, and they differ slightly from the definitions provided in other places.
Backus-Naur表单（BNF）已被用于指定IETF路由区域内若干协议的消息格式。不幸的是，这些规范并非基于BNF的任何特定正式定义，它们与其他地方提供的定义略有不同。
It is clearly valuable to have a formal definition of the syntax-defining language that is used. It would be possible to convert all existing specifications to use an established specification of BNF (for example, Augmented BNF or ABNF [RFC5234]); however, this would require a lot of work. It should be noted that in ABNF the terminals are integers (characters/bytes), while in the BNF form used to define message formats, the terminals are "objects" (some kind of message elements, but not individual bytes or characters) or entire "messages". This means that converting existing specifications to use an established BNF specification would also require extensions to that BNF specification.
显然，对所使用的语法定义语言进行正式定义是很有价值的。可以将所有现有规范转换为使用已建立的BNF规范（例如，增强BNF或ABNF[RFC5234]）；然而，这将需要大量的工作。应注意，在ABNF中，终端是整数（字符/字节），而在用于定义消息格式的BNF格式中，终端是“对象”（某种消息元素，但不是单个字节或字符）或整个“消息”。这意味着将现有规范转换为使用已建立的BNF规范还需要对该BNF规范进行扩展。
On the other hand, the variant of BNF used by the specifications in question (which is similar to a subset of Extended BNF [EBNF]) is consistent and has only a small number of constructs. It makes sense, therefore, to provide a definition of this variant of BNF to allow ease of interpretation of existing documents and to facilitate the development of new protocol specifications using the same variant of BNF. A specification will also facilitate automated verification of the formal definitions used in future documents.
另一方面，相关规范使用的BNF变体（类似于扩展BNF[EBNF]的子集）是一致的，并且只有少量构造。因此，有必要提供BNF变体的定义，以便于解释现有文件，并促进使用相同BNF变体制定新的协议规范。规范还将有助于自动验证未来文档中使用的正式定义。
This document provides such a specification and names the BNF variant Routing BNF (RBNF).
本文档提供了此类规范，并将BNF变量命名为路由BNF（RBNF）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The first notable use of the variant of BNF that concerns us is in the specification of the Resource Reservation Protocol (RSVP) [RFC2205]. RSVP has been extended for use in Multiprotocol Label Switching (MPLS) networks to provide signaling for Traffic Engineering (TE) [RFC3209], and this has been developed for use as the signaling protocol in Generalized MPLS (GMPLS) networks [RFC3473].
我们关注的BNF变体的第一个值得注意的用途是在资源预留协议（RSVP）[RFC2205]的规范中。RSVP已扩展用于多协议标签交换（MPLS）网络，为流量工程（TE）提供信令[RFC3209]，并已开发用于通用MPLS（GMPLS）网络中的信令协议[RFC3473]。
Each of these three uses of RSVP has given rise to a large number of specifications of protocol extensions to provide additional features over and above those in the base documents. Each new feature is defined in its own document using the common variant of BNF.
RSVP的这三种用途中的每一种都产生了大量的协议扩展规范，以提供超出基础文档的附加功能。每个新特性都使用BNF的通用变体在其自己的文档中定义。
New protocols have also been specified using the same variant of BNF. This has arisen partly because the developers were familiar with the BNF used in [RFC2205], etc., but also because of the overlap between the protocols, especially with respect to the network objects controlled and operated.
还使用相同的BNF变体指定了新的协议。出现这种情况的部分原因是，开发人员熟悉[RFC2205]等中使用的BNF，但也因为协议之间存在重叠，尤其是在控制和操作的网络对象方面。
Notable among these additional protocols are the Link Management Protocol (LMP) [RFC4204] and the Path Computation Element Protocol (PCEP) [RFC5440]. In both cases, further documents that specify protocol extensions also use the same variant of BNF.
这些附加协议中值得注意的是链路管理协议（LMP）[RFC4204]和路径计算元素协议（PCEP）[RFC5440]。在这两种情况下，指定协议扩展的其他文档也使用相同的BNF变体。
RBNF as defined in this document is primarily applicable for the protocols listed in the previous section. The specification may be used to facilitate the interpretation of the pre-existing RFCs that are referenced. It should also be used in the specification of extensions to those protocols.
本文件中定义的RBNF主要适用于上一节中列出的协议。本规范可用于促进对引用的现有RFC的解释。它还应用于这些协议的扩展规范中。
RBNF could also be used for the specification of new protocols. This is most appropriate for the development of new protocols that are closely related to those that already use RBNF. For example, PCEP is closely related to RSVP-TE, and when it was developed, the PCE working group chose to use the same form of BNF as was already used in the RSVP-TE specifications.
RBNF也可用于新协议的规范。这最适合于开发与已经使用RBNF的协议密切相关的新协议。例如，PCEP与RSVP-TE密切相关，在开发PCE时，PCE工作组选择使用与RSVP-TE规范中已经使用的相同形式的BNF。
If a wholly new protocol is being developed and is not related to a protocol that already uses RBNF, the working group should consider carefully whether to use RBNF or to use a more formally specified and broader form of BNF such as ABNF [RFC5234].
如果正在开发一种全新的协议，并且与已经使用RBNF的协议无关，那么工作组应仔细考虑是否使用RBNF或使用更正式和更广泛的BNF形式，例如ABNF[RCF5244]。
The use of RBNF to specify extensions to protocols that do not already use RBNF (i.e., that use some other form of BNF) is not recommended.
不建议使用RBNF来指定尚未使用RBNF（即，使用其他形式的BNF）的协议的扩展。
The basic building blocks of BNF are rules and operators. At its simplest form, a rule in the context we are defining is a protocol object that is traditionally defined by a bit diagram in the protocol specification. Further and more complex rules are constructed by
BNF的基本构件是规则和运算符。最简单的形式是，我们定义的上下文中的规则是一个协议对象，传统上由协议规范中的位图定义。进一步的和更复杂的规则由
combining other rules using operators. The most complex rule is the message that is constructed from an organization of protocol objects as specified by the operators.
使用运算符组合其他规则。最复杂的规则是由操作员指定的协议对象组织构造的消息。
An RBNF specification consists of a sequence of rule definitions using the operators defined in Section 2.2. One rule may be constructed from a set of other rules using operators. The order of definition of rules does not matter. That is, the subordinate rules MAY be defined first and then used in subsequent definitions of further rules, or the top-level rules MAY be defined first followed by a set of definitions of the subordinate rules.
RBNF规范由使用第2.2节中定义的运算符的一系列规则定义组成。可以使用运算符从一组其他规则构造一个规则。规则的定义顺序并不重要。也就是说，可以先定义从属规则，然后在后续规则的定义中使用，或者可以先定义顶级规则，然后再定义一组从属规则的定义。
Rule definitions are read left-to-right on any line, and the lines are read top-to-bottom on the page. This becomes particularly important when considering sequences of rules and operators.
规则定义在任何一行上从左到右读取，这些行在页面上从上到下读取。在考虑规则和运算符序列时，这一点尤为重要。
No semantics should be assumed from special characters used in rule names. For example, it would be wrong to assume that a rule carries a decimal number because the rule name begins or ends with the letter "d". However, individual specifications MAY choose to assign rule names in any way that makes the human interpretation of the rule easier.
不应从规则名称中使用的特殊字符中假定语义。例如，由于规则名称以字母“d”开头或结尾，因此假设规则带有十进制数是错误的。但是，单个规范可以选择以任何方式分配规则名称，以使规则的人工解释更容易。
All rule names are enclosed by angle brackets ("<" and ">"). Rule names MAY include any printable characters, but MUST NOT include tabs or line feeds/breaks.
所有规则名称都用尖括号（“<”和“>”）括起来。规则名称可以包括任何可打印字符，但不得包括制表符或换行符/换行符。
Example: <Path Message>
示例：<Path Message>
The most basic (indivisible) rule is termed an object. The definition of an object is derived from its context.
最基本的（不可分割的）规则称为对象。对象的定义源自其上下文。
Objects are typically named in uppercase. They do not usually use spaces within the name, favoring underbars ("_").
对象通常以大写字母命名。它们通常不在名称中使用空格，而是使用下划线（“\u”）。
Example: <SENDER_TEMPLATE>
示例：<SENDER\u TEMPLATE>
Rules that are constructed from other rules using operators are termed constructs.
使用运算符从其他规则构造的规则称为构造。
Constructs are named in lowercase, although capitals are commonly used to indicate acronyms. Spaces and hyphens are used between words within names.
结构以小写字母命名，尽管大写字母通常用于表示首字母缩略词。名称中的单词之间使用空格和连字符。
Example: <sender descriptor>
示例：<sender descriptor>
The final objective is the definition of messages. These are rules that are constructed from objects and constructs using operators. The only syntactic difference between a message and a construct is that no other rule is typically constructed from a message.
最终目标是定义消息。这些规则是从对象和使用运算符的构造中构造的。消息和构造之间唯一的语法区别是，通常不会从消息构造其他规则。
Messages are typically named in title case.
消息通常以标题大小写命名。
Example: <Path Message>
示例：<Path Message>
Operators are used to build constructs and messages from objects and constructs.
运算符用于从对象和构造生成构造和消息。
Assignment is used to form constructs and messages.
赋值用于形成构造和消息。
Meaning: The named construct or message on the left-hand side is defined to be set equal to the right-hand side of the assignment.
含义：左侧的命名构造或消息定义为设置为等于赋值的右侧。
Encoding:
colon, colon, equal sign ("::=")
Encoding:
colon, colon, equal sign ("::=")
Example:
<WF flow descriptor> ::= <FLOWSPEC>
Example:
<WF flow descriptor> ::= <FLOWSPEC>
Note: The left-hand side of the assignment and the assignment operator MUST be present on the same line.
注意：赋值的左侧和赋值运算符必须位于同一行。
Objects and constructs can be combined as a sequence to form a new construct or a message.
对象和构造可以作为序列组合，以形成新的构造或消息。
Meaning: The objects or constructs MUST be present in the order specified. The order of reading RBNF is stated in Section 2.
含义：对象或构造必须按指定的顺序出现。阅读RBNF的顺序见第2节。
Encoding: A sequence of objects and constructs usually separated by spaces. The objects in a sequence MAY be separated by line breaks.
编码：通常由空格分隔的一系列对象和结构。序列中的对象可以用换行符分隔。
Example:
<SE flow descriptor> ::= <FLOWSPEC> <filter spec list>
Example:
<SE flow descriptor> ::= <FLOWSPEC> <filter spec list>
Note: See Section 2.3.3 for further comments on the ordering of objects and constructs.
注：有关对象和构件顺序的更多注释，请参见第2.3.3节。
Objects and constructs can be marked as optionally present.
对象和构造可以标记为可选的存在。
Meaning: The optional objects or constructs MAY be present or absent within the assignment. Unless indicated as optional, objects and constructs are mandatory and MUST be present. The optional operator can also be nested to give a hierarchical dependency of presence as shown in the example below.
含义：可选对象或结构可能在分配中存在或不存在。除非指示为可选，否则对象和构造是必需的，并且必须存在。可选运算符也可以嵌套，以提供存在的层次依赖关系，如下面的示例所示。
Encoding: Contained in square brackets ("[" and "]").
编码：包含在方括号（“[”和“]”）中。
Example:
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
Example:
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
Example of nesting: The optional operator can be nested. For example,
嵌套示例：可选运算符可以嵌套。例如
<construct> ::= <MAND> [ <OPT_1> [ <OPT_2> ] ]
<construct> ::= <MAND> [ <OPT_1> [ <OPT_2> ] ]
In this construction, the object OPT_2 can only be present if OPT_1 is also present.
在这种构造中，只有当OPT_1也存在时，对象OPT_2才能存在。
Note: The set of objects and constructs within the same pair of square brackets is treated as a unit (an unnamed construct). This means that when multiple objects and constructs are included within the same pair of square brackets, all MUST be included when one is included, unless nested square brackets are used as in the previous example.
注意：同一对方括号内的对象和构件集被视为一个单元（未命名构件）。这意味着，当多个对象和构件包含在同一对方括号内时，在包含一个对象和构件时必须包含所有对象和构件，除非如前一示例中所示使用嵌套方括号。
Choices can be indicated within assignments.
可以在作业中指出选择。
Meaning: Either one rule or the other MUST be present.
意思：一条规则或另一条规则必须存在。
Encoding: The pipe symbol ("|") is used between the objects or constructs that are alternatives.
编码：管道符号（“|”）用于替代对象或构件之间。
Example:
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
Example:
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
Notes: 1. Use of explicit grouping (Section 2.2.6) is RECOMMENDED to avoid confusion. Implicit grouping using line breaks (Section 2.3.2) is often used, but gives rise to potential misinterpretation and SHOULD be avoided in new definitions.
注：1。建议使用显式分组（第2.2.6节），以避免混淆。经常使用使用使用换行符的隐式分组（第2.3.2节），但会导致潜在的误解，应在新定义中避免。
2. Multiple members of alternate sets can give rise to confusion. For example:
2. 备用集的多个成员可能会引起混淆。例如：
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>
could be read to mean that an instance of <flow descriptor> must be present or that it is optional.
可以理解为<flow descriptor>的实例必须存在或是可选的。
To avoid this type of issue, explicit grouping (see Section 2.2.6), or an intermediary MUST be used in all new documents (existing uses are not deprecated, and automatic parsers need to handle existing RFCs). See also Section 2.4 for a description of precedence rules.
为避免此类问题，必须在所有新文档中使用显式分组（请参见第2.2.6节）或中介（现有用途未被弃用，自动解析器需要处理现有RFC）。有关优先规则的说明，请参见第2.4节。
Thus:
因此：
<construct> ::= <ALT_A> <ALT_B> | <ALT_C> <ALT_D>
<construct> ::= <ALT_A> <ALT_B> | <ALT_C> <ALT_D>
is not allowed in new documents and MUST be presented using grouping or using an intermediary construct. For example, and depending on intended meaning:
在新文档中不允许使用，并且必须使用分组或使用中间构造来显示。例如，根据预期含义：
<construct> ::= ( <ALT_A> <ALT_B> ) | ( <ALT_C> <ALT_D> )
<construct> ::= ( <ALT_A> <ALT_B> ) | ( <ALT_C> <ALT_D> )
or
或
<construct> ::= <ALT_A> ( <ALT_B> | <ALT_C> ) <ALT_D>
<construct> ::= <ALT_A> ( <ALT_B> | <ALT_C> ) <ALT_D>
or
或
<intermediary X> ::= <ALT_A> <ALT_B>
<intermediary Y> ::= <ALT_C> <ALT_D>
<construct> ::= <intermediary X> | <intermediary Y>
<intermediary X> ::= <ALT_A> <ALT_B>
<intermediary Y> ::= <ALT_C> <ALT_D>
<construct> ::= <intermediary X> | <intermediary Y>
or
或
<intermediary Z> ::= <ALT_B> | <ALT_C>
<construct> ::= <ALT_A> <intermediary Z> <ALT_D>
<intermediary Z> ::= <ALT_B> | <ALT_C>
<construct> ::= <ALT_A> <intermediary Z> <ALT_D>
It could be the case that a sequence of identical objects or constructs is required within an assignment.
在这种情况下，赋值中可能需要一系列相同的对象或结构。
Meaning: MAY repeat the preceding object, intermediate construct, or construct.
意思：可以重复前面的宾语、中间结构或结构。
Encoding: Three dots ("...").
编码：三个点（“…”）。
Example:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
Example:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
Notes: 1. A set of zero or more objects or constructs can be achieved by combining with the Optional concept as shown in the example above.
注：1。通过与上述示例中所示的可选概念相结合，可以实现一组零个或多个对象或构造。
2. Sequences can also be encoded by building a recursive construct using the Alternative operator. For example:
2. 序列也可以通过使用替代运算符构建递归构造来编码。例如：
<sequence> ::= <OBJECT> |
( <OBJECT> <sequence> )
<sequence> ::= <OBJECT> |
( <OBJECT> <sequence> )
3. Repetition can also be applied to a component of an assignment to indicate the optional repetition of that component. For example, the Notify message in [RFC3473] is defined as follows:
3. 重复也可以应用于作业的某个部分，以指示该部分的可选重复。例如，[RFC3473]中的通知消息定义如下：
<Notify message> ::=
<Common Header> [<INTEGRITY>]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC> <notify session list>
<Notify message> ::=
<Common Header> [<INTEGRITY>]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC> <notify session list>
In this example, there is a sequence of zero or more instances of [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]. One could argue that the use of grouping (see Section 2.2.6) or a recursive construct (see Note 2, above) would be more clear.
在本例中，存在一系列零个或多个[<MESSAGE_ID_ACK>.<MESSAGE_ID_NACK>]实例。有人可能会说，使用分组（见第2.2.6节）或递归构造（见上文注2）会更清楚。
Meaning: A group of objects or constructs to be treated together. This notation is not mandatory but is RECOMMENDED for clarity. See Section 2.4 on Precedence.
意思：一起处理的一组对象或结构。此符号不是强制性的，但为清晰起见，建议使用此符号。参见第2.4节“优先顺序”。
Encoding: Round brackets ("(" and ")") enclosing a set of objects, constructs, and operators.
编码：圆括号（“（”和“）”），包含一组对象、构造和运算符。
Example:
<group> ::= ( <this> <that> )
Example:
<group> ::= ( <this> <that> )
Notes: 1. The precedence rule in Section 2.4 means that the use of grouping is not necessary for the formal interpretation of the BNF representation. However, grouping can make the BNF easier to parse unambiguously. Either grouping or an intermediate construct MUST be used for multi-alternates (Section 2.2.4).
注：1。第2.4节中的优先规则意味着对BNF表示的正式解释不需要使用分组。然而，分组可以使BNF更容易明确地解析。多备选方案必须使用分组或中间结构（第2.2.4节）。
2. Line breaks (Section 2.3.2) are often used to clarify grouping as can be seen in the definition of <sequence> in Section 2.2.5, but these are open to misinterpretation, and explicit grouping is RECOMMENDED.
2. 换行符（第2.3.2节）通常用于澄清分组，如第2.2.5节中<sequence>的定义所示，但这些容易被误解，建议明确分组。
3. A practical alternative to grouping is the definition of intermediate constructs as illustrated in Note 2 of Section 2.2.4.
3. 分组的一个实用替代方法是定义中间结构，如第2.2.4节注释2所示。
White space (that is space characters) between operators, objects, and constructs is ignored but SHOULD be used for readability.
运算符、对象和构造之间的空白（即空格字符）将被忽略，但应用于可读性。
Line breaks within an assignment are ignored but SHOULD be used for readability.
赋值中的换行符将被忽略，但应用于可读性。
Line breaks are often used to imply grouping within the precedence rules set out in Section 2.4, but explicit grouping (Section 2.2.6) or intermediary constructs (Section 2.2.4) SHOULD be used in new definitions.
换行符通常用于暗示在第2.4节规定的优先规则内进行分组，但在新定义中应使用显式分组（第2.2.6节）或中间结构（第2.2.4节）。
A line break MUST NOT be present between the left-hand side of an assignment and the assignment operator (see Section 2.2.1).
赋值的左侧和赋值运算符之间不得出现换行符（见第2.2.1节）。
New assignments (i.e., new construct or message definitions) MUST begin on a new line.
新分配（即新构造或消息定义）必须从新行开始。
The ordering of objects and constructs in an assignment is explicit.
赋值中对象和结构的顺序是明确的。
Protocol specifications MAY opt to state that ordering is only RECOMMENDED. In this case, elements of a list of objects and constructs MAY be received in any order.
协议规范可选择声明仅建议订购。在这种情况下，可以以任何顺序接收对象和构造列表的元素。
Precedence is the main opportunity for confusion in the use of this BNF. In particular, the use of alternatives mixed with concatenations can give rise to different interpretations of the BNF. Although precedence can be deduced from a "proper" reading of the BNF using the rules defined above and the precedence ordering shown below, authors are strongly RECOMMENDED to use grouping (Section 2.2.6) and ordering (Section 2.3.3) to avoid cases where the reader would otherwise be required to understand the precedence rules.
优先权是使用本BNF时出现混淆的主要机会。特别是，混合使用串联的替代方案可能导致对BNF的不同解释。尽管可以使用上述规则和下文所示的优先顺序从BNF的“正确”阅读中推断出优先顺序，但强烈建议作者使用分组（第2.2.6节）和排序（第2.3.3节），以避免读者需要理解优先规则的情况。
Automated readers are REQUIRED to parse rules correctly with or without this use of grouping.
无论是否使用分组，都需要自动读取器正确解析规则。
The various mechanisms described in the previous sections have the following precedence, from highest (binding tightest) at the top, to lowest (and loosest) at the bottom:
前几节中描述的各种机制具有以下优先顺序，从顶部的最高（最紧密的绑定）到底部的最低（最松散的绑定）：
objects, constructs repetition grouping, optional concatenation alternative
对象、构造、重复分组、可选连接选项
Note: Precedence is the main opportunity for confusion in the use of BNF. Authors are strongly RECOMMENDED to use grouping (Section 2.2.6) in all places where there is any scope for misinterpretation even when the meaning is obvious to the authors.
注：在使用BNF时，优先顺序是造成混淆的主要原因。强烈建议作者在所有存在误解范围的地方使用分组（第2.2.6节），即使其含义对作者来说是显而易见的。
Example:
例子：
An example of the confusion in precedence can be found in Section 3.1.4 of [RFC2205] and is mentioned in Section 2.2.4.
在[RFC2205]的第3.1.4节中可以找到优先顺序混淆的示例，并在第2.2.4节中提到。
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>
The implementer MUST decide which of the following is intended:
实施者必须决定以下哪一项：
a. <flow descriptor list> ::= <empty> |
( <flow descriptor list> <flow descriptor> )
a. <flow descriptor list> ::= <empty> |
( <flow descriptor list> <flow descriptor> )
b. <flow descriptor list> ::= ( <empty> | <flow descriptor list> )
<flow descriptor>
b. <flow descriptor list> ::= ( <empty> | <flow descriptor list> )
<flow descriptor>
The line break MAY be interpreted as implying grouping, but that is not an explicit rule. However, the precedence rules say that concatenation has higher precedence than the Alternative operator. Thus, the text in [RFC2205] SHOULD be interpreted as shown in formulation a.
换行符可以解释为意味着分组，但这不是一个明确的规则。然而，优先级规则表明，串联比替代运算符具有更高的优先级。因此，[RFC2205]中的文本应如公式a所示进行解释。
Similarly (from the same section of [RFC2205]):
类似地（来自[RFC2205]的同一节）：
<flow descriptor list> ::=
<FLOWSPEC> <FILTER_SPEC> |
<flow descriptor list> <FF flow descriptor>
<flow descriptor list> ::=
<FLOWSPEC> <FILTER_SPEC> |
<flow descriptor list> <FF flow descriptor>
SHALL be interpreted as:
应解释为：
<flow descriptor list> ::=
( <FLOWSPEC> <FILTER_SPEC> ) |
( <flow descriptor list> <FF flow descriptor> )
<flow descriptor list> ::=
( <FLOWSPEC> <FILTER_SPEC> ) |
( <flow descriptor list> <FF flow descriptor> )
The use of explicit grouping or intermediary constructs is strongly RECOMMENDED in new text to avoid confusion.
强烈建议在新文本中使用显式分组或中间结构，以避免混淆。
RBNF would be appropriate for verification using automated validation tools. Validation tools need to be able to check for close conformance to the rules expressed in this document to be useful for verifying new documents, but should also be able to parse RBNF as used in existing RFCs. No tools are known at this time.
RBNF适用于使用自动验证工具进行验证。验证工具需要能够检查与本文档中表达的规则的紧密一致性，以便有助于验证新文档，但也应该能够解析现有RFC中使用的RBNF。目前还不知道任何工具。
This document does not define any network behavior and does not introduce or seek to solve any security issues.
本文档未定义任何网络行为，也未介绍或试图解决任何安全问题。
It may be noted that clear and unambiguous protocol specifications reduce the likelihood of incompatible or defective implementations that might be exploited in security attacks.
可能需要注意的是，清晰明确的协议规范降低了在安全攻击中可能被利用的不兼容或有缺陷的实现的可能性。
Thanks to Magnus Westerlund, Nic Neate, Chris Newman, Alfred Hoenes, Lou Berger, Julien Meuric, Stuart Venters, Tom Petch, Sam Hartman, and Pasi Eronen for review and useful comments.
感谢Magnus Westerlund、Nic Neate、Chris Newman、Alfred Hoenes、Lou Berger、Julien Meuria、Stuart Venters、Tom Petch、Sam Hartman和Pasi Eronen的评论和有用的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]Lang，J.，Ed.，“链路管理协议（LMP）”，RFC4204，2005年10月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[EBNF] ISO/IEC 14977, "Information technology -- Syntactic metalanguage -- Extended BNF", 1996.
[EBNF]ISO/IEC 14977，“信息技术——句法元语言——扩展BNF”，1996年。
Author's Address
作者地址
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk