Internet Research Task Force (IRTF) S. Symington
Request for Comments: 6258 The MITRE Corporation
Category: Experimental May 2011
ISSN: 2070-1721
Internet Research Task Force (IRTF) S. Symington
Request for Comments: 6258 The MITRE Corporation
Category: Experimental May 2011
ISSN: 2070-1721
Delay-Tolerant Networking Metadata Extension Block
容错网络元数据扩展块
Abstract
摘要
This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
本文档定义了可与延迟容忍网络（DTN）捆绑协议一起使用的扩展块。此元数据扩展块设计用于承载附加信息，DTN节点可以使用这些信息来做出有关捆绑包的处理决策，例如决定是否存储捆绑包或确定将捆绑包转发给哪些节点。元数据块中携带的元数据必须根据块的元数据类型字段中标识的元数据类型进行格式化。本文档中定义了一种特定的元数据类型，用于将URI作为元数据携带。其他元数据类型可以在单独的文档中定义。本文件是耐延迟网络研究小组的产品，该小组已对其进行了审查。没有人反对将其作为RFC出版。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay-Tolerant Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。该RFC代表了互联网研究任务组（IRTF）的延迟容忍网络研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6258.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6258.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Metadata Block Format ...........................................4
3. Metadata Block Processing .......................................5
3.1. Bundle Transmission ........................................6
3.2. Bundle Forwarding ..........................................6
3.3. Bundle Reception ...........................................6
4. Predefined Metadata Types .......................................6
4.1. URI Metadata Type ..........................................6
4.2. Private Metadata Types .....................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
6.1. Metadata Type Codes ........................................8
6.2. Block Type Code for the Metadata Block .....................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Metadata Block Format ...........................................4
3. Metadata Block Processing .......................................5
3.1. Bundle Transmission ........................................6
3.2. Bundle Forwarding ..........................................6
3.3. Bundle Reception ...........................................6
4. Predefined Metadata Types .......................................6
4.1. URI Metadata Type ..........................................6
4.2. Private Metadata Types .....................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
6.1. Metadata Type Codes ........................................8
6.2. Block Type Code for the Metadata Block .....................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
This document defines an extension block that may be used with the Bundle Protocol [RFC5050] within the context of a Delay-Tolerant Networking architecture [RFC4838]. The DTN Bundle Protocol [RFC5050] defines the bundle as its protocol data unit. This document defines a bundle block called a "metadata block". This block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles.
本文档定义了一个扩展块，该扩展块可在容错网络体系结构[RFC4838]的上下文中与捆绑协议[RFC5050]一起使用。DTN捆绑协议[RFC5050]将捆绑定义为其协议数据单元。本文档定义了一个称为“元数据块”的捆绑包块。此块设计用于承载DTN节点可用于做出有关捆绑包的处理决策的附加信息。
The metadata block has been deliberately defined to be flexible enough that it would be capable of supporting a variety of metadata types and formats. Indeed, the only restriction imposed on the metadata to be used is that its type and format be predefined and registered (if public) so that it can be parsed and processed by DTN nodes that support metadata of that type. Section 4 defines a
元数据块被刻意定义为足够灵活，能够支持多种元数据类型和格式。实际上，对要使用的元数据施加的唯一限制是其类型和格式必须预定义和注册（如果是公共的），以便支持该类型元数据的DTN节点可以对其进行解析和处理。第4节定义了
specific metadata type and discusses the use of other metadata types that may be defined elsewhere. As mentioned, it is the intention that the metadata that is carried in this block be application-related information. For example, the metadata might be information that is associated with the payload of a bundle. Additional extension blocks could be (and have been) defined for carrying additional network-related information.
具体的元数据类型，并讨论可能在其他地方定义的其他元数据类型的使用。如前所述，该块中携带的元数据是与应用程序相关的信息。例如，元数据可能是与包的有效负载相关联的信息。可以（并且已经）定义额外的扩展块来承载额外的网络相关信息。
While the bundle payload may be processed opaquely by DTN nodes, metadata is intended to serve as a mechanism for providing DTN nodes with access to additional information that they can use to process the bundle. Examples of such additional information include keywords found in the payload; payload provenance information; GPS coordinates (if the payload is a map, for instance); message IDs; and artist, album, and track name (if the payload is a song). Even though the metadata is additional information related to the application, its purpose is to be used by DTN nodes to make decisions regarding how to process bundles within the network, such as whether or not a bundle should be stored or to which nodes a bundle should be forwarded. Metadata that is about bundle payload, for example, might serve as a content-based index of bundles that are stored in a DTN cache. So, in response to a request for bundles related to a certain subject or related to specific GPS coordinates, for example, the metadata of stored bundles could be searched, and all bundles with metadata matching the search criteria could be retrieved and returned to the requestor.
虽然捆绑负载可由DTN节点不透明地处理，但元数据旨在作为一种机制，为DTN节点提供对其可用于处理捆绑的附加信息的访问。此类附加信息的示例包括在有效载荷中找到的关键字；有效载荷来源信息；GPS坐标（例如，如果有效载荷是地图）；消息ID；以及艺术家、专辑和曲目名称（如果有效负载是一首歌曲）。尽管元数据是与应用程序相关的附加信息，但其目的是供DTN节点用于决定如何在网络中处理捆绑包，例如是否应存储捆绑包或将捆绑包转发到哪个节点。例如，关于捆绑负载的元数据可以用作存储在DTN缓存中的捆绑包的基于内容的索引。因此，为了响应与特定主题或特定GPS坐标相关的捆绑包请求，例如，可以搜索存储捆绑包的元数据，并且可以检索元数据与搜索条件匹配的所有捆绑包并将其返回给请求者。
This document defines the general format of and the processing required to support the metadata block. The actual metadata to be inserted into a metadata block MUST be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying Uniform Resource Identifiers (URIs) [RFC3986] as metadata, is defined in this document. Other metadata types may be defined in separate documents, along with the steps required to process records of that type, if necessary. If such other metadata types are defined, they should be registered to ensure global uniqueness (see the IANA Considerations section).
本文档定义了支持元数据块所需的一般格式和处理。要插入元数据块的实际元数据必须根据块的元数据类型字段中标识的元数据类型进行格式化。本文档中定义了一种特定的元数据类型，用于携带统一资源标识符（URI）[RFC3986]作为元数据。其他元数据类型可以在单独的文档中定义，如有必要，还可以在处理该类型记录所需的步骤中定义。如果定义了此类其他元数据类型，则应注册它们以确保全局唯一性（请参阅IANA注意事项部分）。
The capabilities described in this document are OPTIONAL for deployment with the Bundle Protocol. As defined in this document, Bundle Protocol implementations claiming to support the metadata block MUST be capable of:
本文档中描述的功能对于捆绑协议的部署是可选的。如本文档所定义，声称支持元数据块的捆绑协议实现必须能够：
- generating a metadata block and inserting it into a bundle,
- 生成元数据块并将其插入捆绑包，
- receiving bundles containing a metadata block and making the information contained in this metadata block's metadata field available for use, e.g., in bundle storage or forwarding decisions, and
- 接收包含元数据块的捆绑包，并使此元数据块的元数据字段中包含的信息可供使用，例如，在捆绑包存储或转发决策中，以及
- deleting a metadata block from a received bundle before forwarding the bundle.
- 在转发包之前从接收到的包中删除元数据块。
Bundle Protocol implementations claiming to support a specific metadata type must both support the metadata block as defined above and be capable of parsing and processing the metadata itself according to the definition of the metadata type in which the metadata is expressed. This metadata type may be the URI metadata type (see the URI metadata type section), or it may be another metadata type defined in a separate document.
声称支持特定元数据类型的捆绑协议实现必须既支持上面定义的元数据块，又能够根据表示元数据的元数据类型的定义解析和处理元数据本身。此元数据类型可能是URI元数据类型（请参阅URI元数据类型部分），也可能是在单独文档中定义的另一种元数据类型。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The metadata block uses the Canonical Bundle Block Format as defined in the Bundle Protocol [RFC5050]. That is, it is comprised of the following elements, which are defined as in all bundle protocol blocks except the primary bundle block. (Note that Self-Delimiting Numeric Value (SDNV) encoding is described in the Bundle Protocol.):
元数据块使用捆绑协议[RFC5050]中定义的规范捆绑块格式。也就是说，它由以下元素组成，这些元素定义为除主捆绑包块之外的所有捆绑包协议块中的元素。（请注意，捆绑协议中描述了自定界数值（SDNV）编码。）
- Block-type code (1 byte) - defined as in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol). The block-type code for the metadata block is 0x08.
- 块类型代码（1字节）-定义为除主捆绑包块外的所有捆绑包协议块（如捆绑包协议中所述）。元数据块的块类型代码为0x08。
- Block processing control flags (SDNV) - defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol. There are no constraints on the use of the block processing control flags. If a bundle node receives a bundle with a metadata block and it is capable of supporting the metadata block but it is not able to parse and process the metadata itself, either because it does not support the metadata type being used or because the metadata is not well-formed according to the metadata type definition, the bundle node must process the bundle as if it cannot process the metadata block. That is, it must operate according to the settings of the block processing control flags, including the "Delete bundle if block can't be processed" flag and the "Discard block if it can't be processed" flag.
- 块处理控制标志（SDNV）-在除主捆绑包块之外的所有捆绑包协议块中定义。捆绑协议中描述了SDNV编码。块处理控制标志的使用没有限制。如果bundle节点接收到带有元数据块的bundle，并且它能够支持元数据块，但由于它不支持正在使用的元数据类型，或者由于元数据的格式不符合元数据类型定义，因此无法解析和处理元数据本身，bundle节点必须像处理元数据块一样处理bundle。也就是说，它必须根据块处理控制标志的设置进行操作，包括“块无法处理时删除捆绑”标志和“块无法处理时丢弃”标志。
- Block EID-reference count and EID-references (optional) - composite field defined in the Bundle Protocol that is present if and only if the metadata block references EID elements in the primary block's dictionary. Presence of this field is indicated by the setting of the "Block contains an EID-reference field" bit of the block processing control flags. If EIDs are referenced in the metadata block, then their interpretation is defined by the particular metadata type that is being used in this metadata block, as indicated in the metadata type field.
- 块EID引用计数和EID引用（可选）—在捆绑协议中定义的复合字段，当且仅当元数据块引用主块字典中的EID元素时才存在。该字段的存在由块处理控制标志的“块包含EID参考字段”位的设置指示。如果在元数据块中引用了EID，则它们的解释由该元数据块中使用的特定元数据类型定义，如元数据类型字段中所示。
- Block data length (SDNV) - defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol.
- 块数据长度（SDNV）-定义为除主捆绑包块之外的所有捆绑包协议块。捆绑协议中描述了SDNV编码。
- Block-type-specific data fields as follows:
- 块类型特定的数据字段如下所示：
- Metadata Type field (SDNV) - indicates which metadata type is to be used to interpret both the metadata in the metadata field and the EID-references in the optional Block EID-reference count and EID-references field (if present). One metadata type is defined in this document. Other metadata types may be defined in separate documents.
- 元数据类型字段（SDNV）-指示要用于解释元数据字段中的元数据以及可选块EID引用计数和EID引用字段（如果存在）中的EID引用的元数据类型。本文档中定义了一种元数据类型。其他元数据类型可以在单独的文档中定义。
- Metadata field - contains the metadata itself, formatted according to the metadata type that has been specified for this block. One metadata type is defined in Section 4.1. Other metadata types may be defined elsewhere, as discussed in Section 4.
- 元数据字段-包含元数据本身，根据为此块指定的元数据类型进行格式化。第4.1节定义了一种元数据类型。其他元数据类型可以在其他地方定义，如第4节所述。
The structure of a metadata block is as follows:
元数据块的结构如下所示：
Metadata Block Format:
+-----+------+--------------------+------+----------+----------|
|Type |Flags |EID-Reference count |Len | Metadata | Metadata |
| |(SDNV)| and list (opt) |(SDNV)| Type | |
+-----+------+--------------------+------+----------+----------+
Metadata Block Format:
+-----+------+--------------------+------+----------+----------|
|Type |Flags |EID-Reference count |Len | Metadata | Metadata |
| |(SDNV)| and list (opt) |(SDNV)| Type | |
+-----+------+--------------------+------+----------+----------+
Figure 1
图1
The following are the processing steps that a bundle node may take relative to generation, reception, and processing of metadata blocks.
以下是捆绑节点可能采取的与元数据块的生成、接收和处理相关的处理步骤。
When an outbound bundle is created per the parameters of the bundle transmission request, this bundle MAY (as influenced by local policy and the metadata type being used) include one or more metadata blocks (as defined in this specification).
当根据捆绑包传输请求的参数创建出站捆绑包时，该捆绑包可能（受本地策略和使用的元数据类型的影响）包括一个或多个元数据块（如本规范中所定义）。
A node MAY insert one or more metadata blocks into a bundle before forwarding it; and a node MAY delete one or more metadata blocks from a bundle before forwarding it, as dictated by local policy and the metadata type being used.
节点可以在转发包之前将一个或多个元数据块插入包中；并且，根据本地策略和所使用的元数据类型的指示，节点可以在转发包之前从包中删除一个或多个元数据块。
If the bundle includes one or more metadata blocks, the metadata information records in these blocks SHALL be made available for use at this node (e.g., in bundle storage or forwarding decisions, or, if the receiving node is the bundle-destination, the metadata information records may be provided to the receiving application).
如果捆绑包包括一个或多个元数据块，则这些块中的元数据信息记录应可供此节点使用（例如，捆绑包存储或转发决策中，或者，如果接收节点是捆绑包目的地，则可向接收应用程序提供元数据信息记录）。
As mentioned in the previous section, any number of different metadata types may be defined to indicate the format of both the metadata field and the EID-references in the optional Block EID-reference count and EID-references field (if present) and, if necessary, how metadata of this type should be processed. One metadata type is defined in this document, URI metadata type (0x01). In addition, a range of metadata type values is reserved for private use.
如前一节所述，可以定义任意数量的不同元数据类型，以指示可选块EID引用计数和EID引用字段（如果存在）中元数据字段和EID引用的格式，以及在必要时如何处理此类型的元数据。本文档中定义了一种元数据类型，即URI元数据类型（0x01）。此外，还保留了一系列元数据类型值供私人使用。
It is believed that use of URIs will, in many cases, be adequate for encoding metadata, although it is recognized that use of URIs may not be the most efficient method for such encoding. Because of the expected utility of using URI encoding for metadata, the metadata type value of 0x01 is defined to indicate a metadata type of URI. Metadata type values other than 0x01 will be used to indicate alternative metadata types.
人们相信，在许多情况下，使用URI将足以对元数据进行编码，尽管人们认识到使用URI可能不是进行这种编码的最有效方法。由于对元数据使用URI编码的预期效用，定义了元数据类型值0x01以指示URI的元数据类型。0x01以外的元数据类型值将用于指示替代元数据类型。
The Metadata field for metadata of metadata type URI (0x01) consists of an array of bytes formed by concatenating one or more null-terminated URIs. Unless determined by local policy, the specific processing steps that must be performed on bundles with metadata blocks containing metadata of type URI are expected to be indicated
元数据类型URI（0x01）的元数据的元数据字段由一个字节数组组成，字节数组由一个或多个以null结尾的URI连接而成。除非由本地策略确定，否则应指示必须在元数据块包含URI类型元数据的捆绑包上执行的特定处理步骤
as part of the URI encoding of the metadata. It is envisioned that users might define URI schemes for this purpose. Metadata blocks containing metadata of type URI MUST NOT include a Block EID-reference count and EID-references field. The absence of this field MUST be indicated by a value of 0 for the "Block contains an EID-reference field" flag in the block processing control flags. Support for the URI metadata type is OPTIONAL.
作为元数据URI编码的一部分。设想用户可以为此定义URI方案。包含URI类型元数据的元数据块不得包含块EID引用计数和EID引用字段。对于块处理控制标志中的“块包含EID参考字段”标志，此字段的缺失必须用0值表示。对URI元数据类型的支持是可选的。
Metadata type values 192 through 255 are not defined in this specification and are available for private and/or experimental use. Such private metadata types are not required to be registered. All other values of the metadata type are reserved for future use and, when defined, should be registered to ensure global uniqueness (see the IANA Considerations section). Local policy will define how private metadata types are handled.
元数据类型值192到255未在本规范中定义，可供私人和/或实验使用。这种私有元数据类型不需要注册。元数据类型的所有其他值保留供将来使用，并且在定义时，应注册以确保全局唯一性（请参阅IANA注意事项部分）。本地策略将定义如何处理私有元数据类型。
The DTN Bundle Security Protocol [RFC6257] defines security-related blocks to provide hop-by-hop authentication, end-to-end authentication, end-to-end confidentiality of bundles or parts of bundles, and an extension security block to provide confidentiality and integrity for extension blocks, as well as a set of standard ciphersuites that may be used to calculate security-results carried in these security blocks. All ciphersuites that use the strict canonicalization algorithm [RFC6257] to calculate and verify security-results (e.g., many hop-by-hop authentication ciphersuites) apply to all blocks in the bundle and so would apply to bundles that include an optional metadata block and would include that block in the calculation of their security-result. In particular, bundles including the optional metadata block would be protected in their entirety for the duration of a single hop, from a forwarding node to an adjacent receiving node (but not from source to destination over multiple hops), using the standard BAB-HMAC (Bundle Authentication Block - Hashed Message Authentication Code) ciphersuite defined in the Bundle Security Protocol.
DTN捆绑包安全协议[RFC6257]定义了安全相关块，以提供逐跳身份验证、端到端身份验证、捆绑包或捆绑包部分的端到端机密性，以及扩展安全块，以提供扩展块的机密性和完整性，以及一组标准密码套件，可用于计算这些安全块中携带的安全结果。使用严格规范化算法[RFC6257]计算和验证安全结果的所有密码套件（例如，许多逐跳验证密码套件）适用于捆绑包中的所有块，因此将适用于包含可选元数据块的捆绑包，并将该块包括在其安全结果的计算中。特别是，使用标准BAB-HMAC（Bundle Authentication block-散列消息认证码），在从转发节点到相邻接收节点（但不是通过多个跃点从源到目的地）的单跳期间，包括可选元数据块的Bundle将受到整体保护捆绑安全协议中定义的密码套件。
Ciphersuites that use the mutable canonicalization algorithm to calculate and verify security-results (e.g., the mandatory PSH-RSA-SHA256 ciphersuite and most end-to-end authentication ciphersuites) will omit the metadata block from their calculation. Therefore, the fact that metadata in the metadata block may be modified or that metadata blocks themselves may be added to or deleted from a bundle as it transits the network will not interfere with end-to-end security protection when using ciphersuites that use mutable canonicalization.
使用可变规范化算法计算和验证安全结果的密码套件（例如，强制性的PSH-RSA-SHA256密码套件和大多数端到端验证密码套件）将从计算中忽略元数据块。因此，当使用使用可变规范化的密码套件时，元数据块中的元数据可能会被修改，或者元数据块本身可能会在包传输到网络时添加到包中或从包中删除，这一事实不会干扰端到端的安全保护。
The metadata block will not be encrypted by the mandatory CH-RSA-AES-PAYLOAD-PSH end-to-end confidentiality ciphersuite, which only allows for payload and PSH encryption.
元数据块不会通过强制CH-RSA-AES-PAYLOAD-PSH端到端保密密码套件进行加密，该密码套件仅允许有效负载和PSH加密。
In order to provide the metadata block with end-to-end confidentiality and authentication independent of any confidentiality or authentication that is provided for the payload or other parts of the bundle, the extension security block may be used to encrypt and authenticate the metadata block. A bundle may contain multiple metadata extension blocks. In some cases, multiple metadata blocks may be carried in the bundle, possibly with each being encrypted separately from each other and from the payload. Such separate encryption of metadata from payload would enable bundle nodes to perform content-based searching and routing on bundle metadata that they are able to decrypt, even if they are not able to decrypt the bundle payload.
为了为元数据块提供端到端的机密性和认证，独立于为有效负载或捆绑包的其他部分提供的任何机密性或认证，扩展安全块可用于加密和认证元数据块。捆绑包可以包含多个元数据扩展块。在某些情况下，捆绑包中可能携带多个元数据块，可能每个元数据块都彼此单独加密，并且与有效负载分开加密。这种元数据与有效负载的单独加密将使捆绑包节点能够对能够解密的捆绑包元数据执行基于内容的搜索和路由，即使它们无法解密捆绑包有效负载。
Given that metadata can be modified by forwarding nodes, it may be desirable to eventually support the ability to audit changes to the metadata at the individual record level. No such capability has been provided in this specification as currently written.
鉴于元数据可以通过转发节点进行修改，因此可能需要最终支持在单个记录级别审核元数据更改的能力。本规范中未提供当前编写的此类功能。
The metadata block carried in the Metadata Extension Block has a Metadata Type Code field (see Sections 2 and 3). An IANA registry has been set up as follows.
元数据扩展块中携带的元数据块具有元数据类型代码字段（请参见第2节和第3节）。IANA注册已按如下方式建立。
Metadata Type Codes Registry
元数据类型代码注册表
The registration policy for this registry is: 0-191: Specification Required 192-255: Private and/or Experimental Use. No assignment by IANA.
此注册表的注册策略为：0-191：所需规范192-255：专用和/或实验性使用。没有IANA的任务。
The Value range is unsigned 8-bit integer.
值范围为无符号8位整数。
+---------+---------------------------------+---------------+
| Value | Description | Reference |
+---------+---------------------------------+---------------+
| 0 | Reserved | This document |
| 1 | URI | This document |
| 2-191 | Unassigned | |
| 192-255 | Private and/or experimental use | This document |
+---------+---------------------------------+---------------+
+---------+---------------------------------+---------------+
| Value | Description | Reference |
+---------+---------------------------------+---------------+
| 0 | Reserved | This document |
| 1 | URI | This document |
| 2-191 | Unassigned | |
| 192-255 | Private and/or experimental use | This document |
+---------+---------------------------------+---------------+
This specification allocates a codepoint from the Bundle Block Type Codes registry defined in [RFC6255] (see Section 2 of this document):
本规范从[RFC6255]中定义的包块类型代码注册表中分配一个代码点（见本文件第2节）：
Additional Entry for the Bundle Block Type Codes Registry:
+-------+----------------------------------------+----------------+
| Value | Description + Reference |
+-------+----------------------------------------+----------------+
| 8 | Metadata Extension Block + This document |
+-------+----------------------------------------+----------------+
Additional Entry for the Bundle Block Type Codes Registry:
+-------+----------------------------------------+----------------+
| Value | Description + Reference |
+-------+----------------------------------------+----------------+
| 8 | Metadata Extension Block + This document |
+-------+----------------------------------------+----------------+
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[RFC5050]Scott，K.和S.Burleigh，“捆绑协议规范”，RFC 50502007年11月。
[RFC6255] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle Protocol IANA Registries", RFC 6255, May 2010.
[RFC6255]Blanchet，M.“延迟容忍网络（DTN）捆绑协议IANA注册表”，RFC 6255，2010年5月。
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007.
[RFC4838]Cerf，V.，Burleigh，S.，Hooke，A.，Torgerson，L.，Durst，R.，Scott，K.，Fall，K.，和H.Weiss，“延迟容忍网络架构”，RFC 48382007年4月。
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011.
[RFC6257]Symington，S.，Farrell，S.，Weiss，H.，和P.Lovell，“捆绑包安全协议规范”，RFC 6257，2011年5月。
Author's Address
作者地址
Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US
美国弗吉尼亚州麦克莱恩科尔郡大道7515号米特尔公司苏珊·弗林·西明顿邮编：22102
Phone: +1 (703) 983-7209
EMail: susan@mitre.org
URI: http://mitre.org/
Phone: +1 (703) 983-7209
EMail: susan@mitre.org
URI: http://mitre.org/