1.1. Objectives

1.1. 目的

The objectives of CBOR, roughly in decreasing order of importance, are:

CBORの目的は、おおよそ重要度の低い順に以下のとおりです。

1. The representation must be able to unambiguously encode most common data formats used in Internet standards.

   • It must represent a reasonable set of basic data types and structures using binary encoding. "Reasonable" here is largely influenced by the capabilities of JSON, with the major addition of binary byte strings. The structures supported are limited to arrays and trees; loops and lattice-style graphs are not supported.
   • There is no requirement that all data formats be uniquely encoded; that is, it is acceptable that the number "7" might be encoded in multiple different ways.

2. The code for an encoder or decoder must be able to be compact in order to support systems with very limited memory, processor power, and instruction sets.

   • An encoder and a decoder need to be implementable in a very small amount of code (for example, in class 1 constrained nodes as defined in [RFC7228]).
   • The format should use contemporary machine representations of data (for example, not requiring binary-to-decimal conversion).

3. Data must be able to be decoded without a schema description.

   • Similar to JSON, encoded data should be self-describing so that a generic decoder can be written.

4. The serialization must be reasonably compact, but data compactness is secondary to code compactness for the encoder and decoder.

   • "Reasonable" here is bounded by JSON as an upper bound in size and by the implementation complexity, which limits the amount of effort that can go into achieving that compactness. Using either general compression schemes or extensive bit-fiddling violates the complexity goals.

5. The format must be applicable to both constrained nodes and high-volume applications.

   • This means it must be reasonably frugal in CPU usage for both encoding and decoding. This is relevant both for constrained nodes and for potential usage in applications with a very high volume of data.

6. The format must support all JSON data types for conversion to and from JSON.

   • It must support a reasonable level of conversion as long as the data represented is within the capabilities of JSON. It must be possible to define a unidirectional mapping towards JSON for all types of data.

7. The format must be extensible, and the extended data must be decodable by earlier decoders.

   • The format is designed for decades of use.
   • The format must support a form of extensibility that allows fallback so that a decoder that does not understand an extension can still decode the message.
   • The format must be able to be extended in the future by later IETF standards.

1. 表現は、インターネット標準で使用される一般的なデータ形式のほとんどを明確に符号化できる必要があります。

   • バイナリーエンコーディングを使用して、合理的な基本データ型と構造のセットを表現する必要があります。ここでの「合理的」とは、主にJSONの機能に大きく影響を受け、バイナリーバイトストリングの主要な追加を含みます。サポートされる構造は、配列とツリーに限定されており、ループや格子状のグラフはサポートされていません。
   • すべてのデータ形式が一意にエンコードされる必要はありません。つまり、数字の「7」が複数の異なる方法でエンコードされることが許容されます。

2. エンコーダーまたはデコーダーのコードは、非常に限られたメモリ、プロセッサのパワー、および命令セットを持つシステムをサポートするためにコンパクトである必要があります。

   • エンコーダーまたはデコーダーは、非常に小さなコードで実装できる必要があります（たとえば、[RFC7228]で定義されたクラス1制約ノードで）。
   • フォーマットは、データの現代的なマシン表現を使用する必要があります（たとえば、バイナリーから10進数への変換を必要としない）。

3. スキーマの説明なしでデータをデコードできる必要があります。

   • JSONと同様に、エンコードされたデータは自己記述的である必要があり、汎用デコーダーを記述できるようにする必要があります。

4. シリアル化は、比較的コンパクトである必要がありますが、エンコーダーとデコーダーのコードのコンパクトさが優先されます。

   • ここでの「合理的」とは、JSONを上限としたサイズであり、実装の複雑さによっても制限されます。コンパクトさを実現するために投入できる労力が制限されるため、一般的な圧縮スキームや広範なビット操作を使用することは、複雑性の目標に反します。

5. フォーマットは、制約ノードと高容量アプリケーションの両方に適用できる必要があります。

   • つまり、エンコードとデコードの両方でCPU使用量が比較的少なくなければなりません。これは、制約ノードと非常に高いデータ量のアプリケーションでの使用に関連しています。

6. フォーマットは、JSONデータ型をすべてサポートし、JSONからの変換およびJSONへの変換を行う必要があります。

   • JSONの機能に大きく影響を受け、表現されたデータがJSONの機能範囲内である限り、合理的な変換レベルをサポートする必要があります。すべてのデータ型に対してJSONへの単方向マッピングを定義することができる必要があります。

7. フォーマットは拡張可能であり、拡張されたデータは以前のデコーダーでデコードできる必要があります。

   • このフォーマットは、数十年にわたる使用を想定しています。
   • フォーマットは、拡張機能をサポートする必要があり、拡張機能を理解できないデコーダーでもメッセージをデコードできるようにフォールバックすることができる形式をサポートする必要があります。
   • フォーマットは、将来のIETF標準によって拡張できる必要があります。

1.2. Terminology

1.2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「しなければなりません（MUST）」、「してはなりません（MUST NOT）」、 「要求されています（REQUIRED）」、 「することになります（SHALL）」、「することはありません（SHALL NOT）」、 「すべきです（SHOULD）」、「すべきではありません（SHOULD NOT）」、 「推奨されます（RECOMMENDED）」、「推奨されません（NOT RECOMMENDED）」、 「してもよいです（MAY）」、「選択できます（OPTIONAL）」は、 BCP 14 [RFC2119] [RFC8174]に記載されているとおりに解釈されるものとします。 ただし、ここに示すようにすべて大文字で表示される場合に限ります。

The term "byte" is used in its now-customary sense as a synonym for "octet". All multi-byte values are encoded in network byte order (that is, most significant byte first, also known as "big-endian").

「バイト（byte）」という用語は、現在の慣習的な意味で「オクテット（octet）」の同義語として使用されます。すべてのマルチバイト値は、ネットワークバイトオーダー（つまり、最上位バイトが先に来る「ビッグエンディアン」とも呼ばれる）でエンコードされます。

This specification makes use of the following terminology:

This specification makes use of the following terminology:

Data item:

A single piece of CBOR data. The structure of a data item may contain zero, one, or more nested data items. The term is used both for the data item in representation format and for the abstract idea that can be derived from that by a decoder; the former can be addressed specifically by using the term "encoded data item".

Decoder:

A process that decodes a well-formed encoded CBOR data item and makes it available to an application. Formally speaking, a decoder contains a parser to break up the input using the syntax rules of CBOR, as well as a semantic processor to prepare the data in a form suitable to the application.

Encoder:

A process that generates the (well-formed) representation format of a CBOR data item from application information.

Data Stream:

A sequence of zero or more data items, not further assembled into a larger containing data item (see [RFC8742] for one application). The independent data items that make up a data stream are sometimes also referred to as "top-level data items".

Well-formed:

A data item that follows the syntactic structure of CBOR. A well-formed data item uses the initial bytes and the byte strings and/or data items that are implied by their values as defined in CBOR and does not include following extraneous data. CBOR decoders by definition only return contents from well-formed data items.

Valid:

A data item that is well-formed and also follows the semantic restrictions that apply to CBOR data items (Section 5.3).

Expected:

Besides its normal English meaning, the term "expected" is used to describe requirements beyond CBOR validity that an application has on its input data. Well-formed (processable at all), valid (checked by a validity-checking generic decoder), and expected (checked by the application) form a hierarchy of layers of acceptability.

Stream decoder:

A process that decodes a data stream and makes each of the data items in the sequence available to an application as they are received.

データアイテム（Data Item）：

単一のCBORデータ。データアイテムの構造には、ゼロ、1つ、または複数のネストされたデータアイテムが含まれる場合があります。この用語は、表現形式のデータアイテムと、デコーダーによって得られる抽象的なアイデアの両方に使用されます。前者は「エンコードされたデータアイテム」という用語を使用して特定できます。

デコーダー（Decoder）：

ウェルフォームされたエンコードされたCBORデータアイテムをデコードし、アプリケーションで使用できるようにします。形式的には、デコーダーには、CBORの構文規則を使用して入力を分割するパーサーと、アプリケーションに適した形式でデータを準備する意味処理器が含まれます。

エンコーダー（Encoder）：

アプリケーション情報からCBORデータアイテムの（ウェルフォームされた）表現形式を生成するプロセス。

データストリーム（Data Stream）：

より大きな含まれるデータアイテムにさらに組み立てられていない、ゼロ個以上のデータアイテムのシーケンス（1つのアプリケーションについては、[RFC8742]を参照）。データストリームを構成する独立したデータアイテムは、時に「トップレベルのデータアイテム」とも呼ばれます。

ウェルフォーム（Well-formed）:

CBORの構文構造にしたがうデータアイテム。ウェルフォームなデータアイテムは、CBORで定義された初期バイトと、その値によって暗示されるバイト文字列および/またはデータアイテムを使用し、その後の余分なデータを含みません。CBORデコーダーは、定義上、ウェルフォームなデータアイテムからのコンテンツのみを返します。

有効（Valid）：

CBORデータアイテムに適用される意味的制限にしたがう、ウェルフォームであるデータアイテム (Section 5.3を参照)。

期待される（Expected）：

通常の英語の意味に加えて、「期待される」という用語は、アプリケーションが入力データに対して持つCBORの有効性を超えた要件を説明するために使用されます。ウェルフォーム（処理可能）、有効（有効性チェックを行う汎用デコーダーによってチェックされる）、期待される（アプリケーションによってチェックされる）は、受け入れ可能性のレイヤーの階層を形成します (Section 5.3を参照)。

ストリームデコーダー：

データストリームをデコードし、データアイテムが受信されるたびにアプリケーションで利用可能にします。

Terms and concepts for floating-point values such as Infinity, NaN (not a number), negative zero, and subnormal are defined in [IEEE754].

無限大、NaN（非数）、負のゼロ、および非正規化数などの浮動小数点値に関する用語や概念は、[IEEE754]で定義されています。

Where bit arithmetic or data types are explained, this document uses the notation familiar from the programming language C [C], except that ".." denotes a range that includes both ends given, and superscript notation denotes exponentiation. For example, 2 to the power of 64 is notated: 2⁶⁴. In the plain-text version of this specification, superscript notation is not available and therefore is rendered by a surrogate notation. That notation is not optimized for this RFC; it is unfortunately ambiguous with C's exclusive-or (which is only used in the appendices, which in turn do not use exponentiation) and requires circumspection from the reader of the plain-text version.

ビット演算やデータ型の説明において、本文書ではCプログラミング言語でお馴染みの表記法を使用しています ([C])。ただし、".."は両端を含む範囲を表し、上付き文字は累乗を表します。たとえば、2の64乗は2⁶⁴と表記されます。 この仕様書のプレーンテキスト版では、上付き文字は使用できないため、代替表記でレンダリングされます。この表記法はRFCに最適化されておらず、Cの排他的論理和と曖昧になることがあります（これは付録でのみ使用され、さらに累乗は使用されません）。プレーンテキスト版の読者は注意が必要です。

Examples and pseudocode assume that signed integers use two's complement representation and that right shifts of signed integers perform sign extension; these assumptions are also specified in Sections 6.8.1 (basic.fundamental) and 7.6.7 (expr.shift) of the 2020 version of C++ (currently available as a final draft, [Cplusplus20]).

例と疑似コード 符号付き整数が2の補数表現を使用し、符号付き整数の右シフトが符号拡張することを前提とします。これらの前提条件は、C++の2020年版のセクション6.8.1（basic.fundamental）および7.6.7（expr.shift）でも指定されています（現在、最終ドラフトとして[Cplusplus20]が利用可能です）。

Similar to the "0x" notation for hexadecimal numbers, numbers in binary notation are prefixed with "0b". Underscores can be added to a number solely for readability, so 0b00100001 (0x21) might be written 0b001_00001 to emphasize the desired interpretation of the bits in the byte; in this case, it is split into three bits and five bits. Encoded CBOR data items are sometimes given in the "0x" or "0b" notation; these values are first interpreted as numbers as in C and are then interpreted as byte strings in network byte order, including any leading zero bytes expressed in the notation.

16進数の"0x"表記法にならって、"0b"接頭辞を2進数の表記法として使用します。可読性を向上させるために、数字にアンダースコアを追加することがあります。たとえば、0b00100001 (0x21) は、バイト内のビットの解釈を強調するために、0b001_00001 のように書くことがあります。この場合、3ビットと5ビットに分割されます。エンコードされたCBORデータアイテムは、ときには"0x"または"0b"表記法で与えられます。これらの値は、まずC言語の数値として解釈され、次にネットワークバイトオーダーでバイト文字列として解釈されます。表記法で表される先頭のゼロバイトも含まれます。

Words may be italicized for emphasis; in the plain text form of this specification, this is indicated by surrounding words with underscore characters. Verbatim text (e.g., names from a programming language) may be set in monospace type; in plain text, this is approximated somewhat ambiguously by surrounding the text in double quotes (which also retain their usual meaning).

強調するために、単語を斜体にすることがあります。この仕様書のプレーンテキスト版では、これは単語をアンダースコアで囲むことで示されます。プログラミング言語の名前などの原文のままのテキストは、等幅フォントで表示されることがあります。プレーンテキストでは、テキストを二重引用符で囲むことで、やや曖昧に近似されます（二重引用符は通常の意味も保持します）。

2.1. Extended Generic Data Models

2.1. 拡張ジェネリックデータモデル

This basic generic data model has been extended in this document by the registration of a number of simple values and tag numbers, such as:

基本ジェネリックデータモデルは、このドキュメントによって、次のようなシンプル値とタグ番号の登録によって拡張されています。

• false, true, null, and undefined (simple values identified by 20..23, Section 3.3)
• integer and floating-point values with a larger range and precision than the above (tag numbers 2 to 5, Section 3.4)
• application data types such as a point in time or date/time string defined in RFC 3339 (tag numbers 1 and 0, Section 3.4)

• false、true、null、およびundefined（20..23で識別されるシンプル値、Section 3.3）
• 上記よりも大きな範囲と精度を持つ整数値および浮動小数点値 （タグ番号2から5、Section 3.4）
• RFC 3339で定義された時刻または日付/時刻文字列などのアプリケーションデータ型 （タグ番号1および0、Section 3.4）

Additional elements of the extended generic data model can be (and have been) defined via the IANA registries created for CBOR. Even if such an extension is unknown to a generic encoder or decoder, data items using that extension can be passed to or from the application by representing them at the application interface within the basic generic data model, i.e., as generic simple values or generic tags.

拡張ジェネリックデータモデルの追加要素は、CBORのために作成されたIANAレジストリを介して定義されることができます（実際に定義されています）。このような拡張が一般的なエンコーダーやデコーダーには不明でも、その拡張を使用するデータアイテムは、基本ジェネリックデータモデル内のジェネリックなシンプル値またはジェネリックなタグとして、アプリケーションインタフェース内で表現することによって、アプリケーションによって受け渡すことができます。

In other words, the basic generic data model is stable as defined in this document, while the extended generic data model expands by the registration of new simple values or tag numbers, but never shrinks.

つまり、基本ジェネリックデータモデルは、このドキュメントで定義されたものとして安定しています。一方、拡張ジェネリックデータモデルは、新しいシンプル値またはタグ番号の登録によって拡張されますが、縮小することはありません。

While there is a strong expectation that generic encoders and decoders can represent false, true, and null (undefined is intentionally omitted) in the form appropriate for their programming environment, the implementation of the data model extensions created by tags is truly optional and a matter of implementation quality.

ジェネリックなエンコーダーやデコーダーが、プログラミング環境に適した形式でfalse、true、およびnull（undefinedは意図的に省略されています）を表現できることが強く期待されていますが、タグによって作成されたデータモデルの拡張の実装は本当にオプションであり、実装品質の問題です。

2.2. Specific Data Models

2.2. 特定データモデル

The specific data model for a CBOR-based protocol usually takes a subset of the extended generic data model and assigns application semantics to the data items within this subset and its components. When documenting such specific data models and specifying the types of data items, it is preferable to identify the types by their generic data model names ("negative integer", "array") instead of referring to aspects of their CBOR representation ("major type 1", "major type 4").

CBORベースのプロトコルの特定データモデルは、通常、拡張ジェネリックデータモデルのサブセットを取り、このサブセットとそのコンポーネント内のデータアイテムにアプリケーションの意味を割り当てます。 このような特定データモデルを文書化し、データアイテムのタイプを指定する場合、CBOR表現の側面（「メジャータイプ1」、「メジャータイプ4」）ではなく、ジェネリックデータモデルの名前（「負の整数」、「配列」）でタイプを識別することが望ましいです。

Specific data models can also specify value equivalency (including values of different types) for the purposes of map keys and encoder freedom. For example, in the generic data model, a valid map MAY have both 0 and 0.0 as keys, and an encoder MUST NOT encode 0.0 as an integer (major type 0, Section 3.1). However, if a specific data model declares that floating-point and integer representations of integral values are equivalent, using both map keys 0 and 0.0 in a single map would be considered duplicates, even while encoded as different major types, and so invalid; and an encoder could encode integral-valued floats as integers or vice versa, perhaps to save encoded bytes.

特定データモデルでは、マップキーとエンコーダーの自由度のために、値の等価性（異なる型の値を含む）を指定できます。たとえば、ジェネリックデータモデルでは、有効なマップには0と0.0の両方がキーとして含まれる場合があります（MAY）。エンコーダーは0.0を整数（メジャータイプ0、Section 3.1）としてエンコードしてはなりません（MUST NOT）。
ただし、特定データモデルが整数値の浮動小数点表現と整数表現を等価と宣言する場合、単一のマップ内で両方のマップキー0と0.0を使用することは、重複とみなされます。異なるメジャータイプとしてエンコードされていても無効になります。なぜなら、エンコードされたバイトを節約するために、エンコーダーは整数値を持つ浮動小数点数を整数としてエンコードできるためです。その逆を行うこともできます。

3.1. Major Types

3.1. メジャータイプ

The following lists the major types and the additional information and other bytes associated with the type.

以下は、メジャータイプとタイプに関連する追加情報およびその他のバイトを示しています。

Major type 0:

An unsigned integer in the range 0..2⁶⁴-1 inclusive. The value of the encoded item is the argument itself. For example, the integer 10 is denoted as the one byte 0b000_01010 (major type 0, additional information 10). The integer 500 would be 0b000_11001 (major type 0, additional information 25) followed by the two bytes 0x01f4, which is 500 in decimal.

Major type 1:

A negative integer in the range -2⁶⁴..-1 inclusive. The value of the item is -1 minus the argument. For example, the integer -500 would be 0b001_11001 (major type 1, additional information 25) followed by the two bytes 0x01f3, which is 499 in decimal.

Major type 2:

A byte string. The number of bytes in the string is equal to the argument. For example, a byte string whose length is 5 would have an initial byte of 0b010_00101 (major type 2, additional information 5 for the length), followed by 5 bytes of binary content. A byte string whose length is 500 would have 3 initial bytes of 0b010_11001 (major type 2, additional information 25 to indicate a two-byte length) followed by the two bytes 0x01f4 for a length of 500, followed by 500 bytes of binary content.

Major type 3:

A text string (Section 2) encoded as UTF-8 [RFC3629]. The number of bytes in the string is equal to the argument. A string containing an invalid UTF-8 sequence is well-formed but invalid (Section 1.2). This type is provided for systems that need to interpret or display human-readable text, and allows the differentiation between unstructured bytes and text that has a specified repertoire (that of Unicode) and encoding (UTF-8). In contrast to formats such as JSON, the Unicode characters in this type are never escaped. Thus, a newline character (U+000A) is always represented in a string as the byte 0x0a, and never as the bytes 0x5c6e (the characters "\" and "n") nor as 0x5c7530303061 (the characters "\", "u", "0", "0", "0", and "a").

Major type 4:

An array of data items. In other formats, arrays are also called lists, sequences, or tuples (a "CBOR sequence" is something slightly different, though [RFC8742]). The argument is the number of data items in the array. Items in an array do not need to all be of the same type. For example, an array that contains 10 items of any type would have an initial byte of 0b100_01010 (major type 4, additional information 10 for the length) followed by the 10 remaining items.

Major type 5:

A map of pairs of data items. Maps are also called tables, dictionaries, hashes, or objects (in JSON). A map is comprised of pairs of data items, each pair consisting of a key that is immediately followed by a value. The argument is the number of pairs of data items in the map. For example, a map that contains 9 pairs would have an initial byte of 0b101_01001 (major type 5, additional information 9 for the number of pairs) followed by the 18 remaining items. The first item is the first key, the second item is the first value, the third item is the second key, and so on. Because items in a map come in pairs, their total number is always even: a map that contains an odd number of items (no value data present after the last key data item) is not well-formed. A map that has duplicate keys may be well-formed, but it is not valid, and thus it causes indeterminate decoding; see also Section 5.6.

Major type 6:

A tagged data item ("tag") whose tag number, an integer in the range 0..2⁶⁴-1 inclusive, is the argument and whose enclosed data item (tag content) is the single encoded data item that follows the head. See Section 3.4.

Major type 7:

Floating-point numbers and simple values, as well as the "break" stop code. See Section 3.3.

メジャータイプ0：

0から2⁶⁴-1までの範囲の符号なし整数。エンコードされたアイテムの値は引数自体です。たとえば、整数10は1バイトの0b000_01010（メジャータイプ0、追加情報10）として表されます。整数500は0b000_11001（メジャータイプ0、追加情報25）に続いて、10進数で500を表す2バイトの0x01f4が続きます。

メジャータイプ1：

-2⁶⁴から-1までの範囲の負の整数。アイテムの値は、-1から引数を引いたものです。たとえば、整数-500は0b001_11001（メジャータイプ1、追加情報25）に続いて、10進数で499を表す2バイトの0x01f3が続きます。

メジャータイプ2：

バイト文字列。文字列のバイト数は引数と等しい。たとえば、長さが5のバイト文字列は、初期バイトが0b010_00101（メジャータイプ2、追加情報5で長さを示す）であるバイナリコンテンツの5バイトに続きます。長さが500のバイト文字列は、長さを示すための2バイトの0x01f4に続く3つの初期バイト0b010_11001（メジャータイプ2、追加情報25）を持ち、500バイトのバイナリコンテンツが続きます。

メジャータイプ3：

UTF-8でエンコードされたテキスト文字列（Section 2）。文字列のバイト数は引数と等しい。無効なUTF-8シーケンスを含む文字列は、ウェルフォームではあるが無効である（Section 1.2）。このタイプは、人間が読めるテキストを解釈または表示する必要があるシステム向けに提供され、構造化されていないバイトと、指定されたレパートリー（Unicodeのレパートリー）とエンコーディング（UTF-8）を持つテキストとの区別を可能にします。JSONなどのフォーマットとは異なり、このタイプのUnicode文字はエスケープされません。したがって、改行文字（U+000A）は常にバイト0x0aとして表され、文字"\"と"n"のバイト0x5c6eや、文字"\"、"u"、"0"、"0"、"0"、および"a"のバイト0x5c7530303061として表されることはありません。

メジャータイプ4：

データアイテムの配列。他のフォーマットでは、配列はリスト、シーケンス、またはタプルとも呼ばれます（「CBORシーケンス」は、[RFC8742]でわずかに異なるものです）。 引数は、配列内のデータアイテムの数です。 配列内のアイテムはすべて同じタイプである必要はありません。たとえば、任意のタイプの10個のアイテムを含む配列は、初期バイトが0b100_01010（メジャータイプ4、追加情報10で長さを示す）であることに続き、残りの10個のアイテムが続きます。

メジャータイプ5：

データアイテムのペアのマップ。マップは、テーブル、ディクショナリ、ハッシュ、またはオブジェクト（JSONでは）とも呼ばれます。マップは、キーと値のペアで構成され、各ペアはすぐに値が続くキーで構成されます。引数は、マップ内のデータアイテムのペア数です。たとえば、9つのペアを含むマップは、初期バイトが0b101_01001（メジャータイプ5、追加情報9でペア数を示す）であることに続き、残りの18個のアイテムが続きます。最初のアイテムは最初のキー、2番目のアイテムは最初の値、3番目のアイテムは2番目のキーであり、以降続きます。マップ内のアイテムはペアであるため、その総数は常に偶数です。アイテムの数が奇数であるマップ（最後のキーデータアイテムの後に値データが存在しない場合）はウェルフォームではありません。重複するキーを持つマップはウェルフォームである場合がありますが、有効ではなく、したがって不確定なデコードを引き起こします。詳細については、Section 5.6も参照してください。

メジャータイプ6：

タグ番号が引数であるタグ付きデータアイテム（「タグ」）であり、タグ番号は0から2⁶⁴-1までの範囲の整数であり、タグコンテンツはヘッドに続く単一のエンコードされたデータアイテムです。 Section 3.4を参照してください。

メジャータイプ7：

浮動小数点数と単純な値、および「break」ストップコード。詳細については、Section 3.3を参照してください。

These eight major types lead to a simple table showing which of the 256 possible values for the initial byte of a data item are used (Table 7).

これらの8つのメジャータイプにより、データアイテムの初期バイトの256個の可能な値のうち、どの値が使用されるかを示す簡単な表が作成されます（Table 7）。

In major types 6 and 7, many of the possible values are reserved for future specification. See Section 9 for more information on these values.

メジャータイプ6および7では、多くの可能な値が将来の仕様のために予約されています。これらの値に関する詳細については、Section 9を参照してください。

Table 1 summarizes the major types defined by CBOR, ignoring Section 3.2 for now. The number N in this table stands for the argument.

Table 1は、CBORで定義されたメジャータイプを、Section 3.2を無視してまとめたものです。この表のNは引数を表します。

3.2. Indefinite Lengths for Some Major Types

3.2. 一部のメジャータイプにおける不定長の使用

Four CBOR items (arrays, maps, byte strings, and text strings) can be encoded with an indefinite length using additional information value 31. This is useful if the encoding of the item needs to begin before the number of items inside the array or map, or the total length of the string, is known. (The ability to start sending a data item before all of it is known is often referred to as "streaming" within that data item.)

配列、マップ、バイト文字列、およびテキスト文字列の4つのCBORアイテムは、追加情報値31を使用して長さを決定せずにエンコードできます。これは、配列またはマップ内のアイテムの数、または文字列の総長がわからない場合に、アイテムのエンコードを開始する必要がある場合に便利です。 (データアイテムのすべてがわかる前にデータアイテムを送信を開始できる能力は、しばしばそのデータアイテム内で「ストリーミング」と呼ばれます。)

Indefinite-length arrays and maps are dealt with differently than indefinite-length strings (byte strings and text strings).

不定長の配列とマップは、不定長の文字列（バイト文字列とテキスト文字列）とは異なる方法で処理されます。

3.3. Floating-Point Numbers and Values with No Content

3.3. 浮動小数点数とコンテンツのない値

Major type 7 is for two types of data: floating-point numbers and "simple values" that do not need any content. Each value of the 5-bit additional information in the initial byte has its own separate meaning, as defined in Table 3. Like the major types for integers, items of this major type do not carry content data; all the information is in the initial bytes (the head).

メジャータイプ7は、浮動小数点数とコンテンツを必要としない「シンプル値」の2つのデータタイプに使用されます。初期バイトの5ビットの追加情報値の各値には、Table 3で定義された独自の意味があります。整数のメジャータイプと同様に、このメジャータイプのアイテムにはコンテンツデータが含まれていません。すべての情報は初期バイト（ヘッド）に含まれています。

As with all other major types, the 5-bit value 24 signifies a single-byte extension: it is followed by an additional byte to represent the simple value. (To minimize confusion, only the values 32 to 255 are used.) This maintains the structure of the initial bytes: as for the other major types, the length of these always depends on the additional information in the first byte. Table 4 lists the numeric values assigned and available for simple values.

他のすべてのメジャータイプと同様に、5ビット値24は単一バイト拡張を示します。これに続いて、追加のバイトが続き、シンプル値を表します（混乱を最小限に抑えるため、値32から255のみが使用されます）。これにより、初期バイトの構造が維持されます。他のメジャータイプと同様に、これらの長さは常に最初のバイトの追加情報に依存します。Table 4 には、シンプル値に割り当てられた数値値と使用可能な値がリストされています。

An encoder MUST NOT issue two-byte sequences that start with 0xf8 (major type 7, additional information 24) and continue with a byte less than 0x20 (32 decimal). Such sequences are not well-formed. (This implies that an encoder cannot encode false, true, null, or undefined in two-byte sequences and that only the one-byte variants of these are well-formed; more generally speaking, each simple value only has a single representation variant).

エンコーダーは、0xf8（メジャータイプ7、追加情報値24）で始まり、0x20（10進数32）未満のバイトで続く2バイトシーケンスを発行してはなりません（MUST NOT）。このようなシーケンスはウェルフォームではありません。（これは、エンコーダーが2バイトシーケンスでfalse、true、null、またはundefinedをエンコードできないことを意味し、これらの1バイトバリアントのみがウェルフォームであることを意味します。より一般的には、各シンプル値には単一の表現バリアントしかありません。）

The 5-bit values of 25, 26, and 27 are for 16-bit, 32-bit, and 64-bit IEEE 754 binary floating-point values [IEEE754]. These floating-point values are encoded in the additional bytes of the appropriate size. (See Appendix D for some information about 16-bit floating-point numbers.)

メジャータイプ25、26、27の5ビット値は、16ビット、32ビット、64ビットのIEEE 754バイナリ浮動小数点値[IEEE754]に使用されます。これらの浮動小数点値は、適切なサイズの追加バイトでエンコードされます。 （16ビット浮動小数点数に関する情報については、Appendix Dを参照してください。）

3.4. Tagging of Items

3.4. アイテムのタグ付け

In CBOR, a data item can be enclosed by a tag to give it some additional semantics, as uniquely identified by a tag number. The tag is major type 6, its argument (Section 3) indicates the tag number, and it contains a single enclosed data item, the tag content. (If a tag requires further structure to its content, this structure is provided by the enclosed data item.) We use the term tag for the entire data item consisting of both a tag number and the tag content: the tag content is the data item that is being tagged.

CBORでは、データアイテムにタグを付けることで、タグ番号によって一意に識別されるいくつかの追加セマンティクスを付与できます。タグはメジャータイプ6であり、その引数（Section 3で定義されている）はタグ番号を示し、単一の囲まれたデータアイテムであるタグコンテンツを含みます。 （タグにコンテンツのさらなる構造が必要な場合は、この構造は囲まれたデータアイテムによって提供されます。）私たちは、タグ番号とタグコンテンツの両方から構成されるデータアイテム全体をタグと呼びます：タグコンテンツは、タグが付けられているデータアイテムです。

For example, assume that a byte string of length 12 is marked with a tag of number 2 to indicate it is an unsigned bignum (Section 3.4.3). The encoded data item would start with a byte 0b110_00010 (major type 6, additional information 2 for the tag number) followed by the encoded tag content: 0b010_01100 (major type 2, additional information 12 for the length) followed by the 12 bytes of the bignum.

たとえば、長さ12のバイト文字列が、符号なしのbignum（Section 3.4.3）であることを示すために、タグ番号2でマークされているとします。エンコードされたデータアイテムは、バイト0b110_00010（メジャータイプ6、タグ番号の追加情報2）で始まり、エンコードされたタグコンテンツが続きます：0b010_01100（長さの追加情報12のメジャータイプ2）に続いて、bignumの12バイトが続きます。

In the extended generic data model, a tag number's definition describes the additional semantics conveyed with the tag number. These semantics may include equivalence of some tagged data items with other data items, including some that can be represented in the basic generic data model. For instance, 0xc24101, a bignum the tag content of which is the byte string with the single byte 0x01, is equivalent to an integer 1, which could also be encoded as 0x01, 0x1801, or 0x190001. The tag definition may specify a preferred serialization (Section 4.1) that is recommended for generic encoders; this may prefer basic generic data model representations over ones that employ a tag.

拡張ジェネリックデータモデルでは、タグ番号の定義によって、タグ番号で伝達される追加のセマンティクスが説明されます。これらのセマンティクスには、基本的なジェネリックデータモデルで表現できるものを含め、タグ付きデータアイテムの一部を他のデータアイテムと同等にすることができます。たとえば、タグコンテンツが単一バイト0x01のバイト文字列である0xc24101のbignumは、整数1と等価であり、0x01、0x1801、または0x190001でエンコードすることもできます。タグの定義では、ジェネリックエンコーダーに推奨される優先シリアル化（Section 4.1）を指定できます。これにより、タグを使用するものよりも基本的なジェネリックデータモデルの表現が優先される場合があります。

The tag definition usually defines which nested data items are valid for such tags. Tag definitions may restrict their content to a very specific syntactic structure, as the tags defined in this document do, or they may define their content more semantically. An example for the latter is how tags 40 and 1040 accept multiple ways to represent arrays [RFC8746].

タグの定義では、通常、そのようなタグに対して有効なネストされたデータアイテムを定義します。タグの定義は、このドキュメントで定義されているタグのように、非常に特定の構文構造にその内容を制限することができます。また、より意味的な方法でその内容を定義することもできます。後者の例として、タグ40および1040が配列を表す複数の方法を受け入れる方法があります。[RFC8746]。

As a matter of convention, many tags do not accept null or undefined values as tag content; instead, the expectation is that a null or undefined value can be used in place of the entire tag; Section 3.4.2 provides some further considerations for one specific tag about the handling of this convention in application protocols and in mapping to platform types.

多くのタグでは、nullまたはundefinedの値をタグコンテンツとして受け入れないことが慣例となっています。代わりに、nullまたはundefinedの値は、タグ全体の代わりに使用できることが期待されています。Section 3.4.2は、アプリケーションプロトコルおよびプラットフォームタイプへのマッピングにおけるこの慣例の扱いについて、1つの特定のタグに関するさらなる考慮事項を提供しています。

Decoders do not need to understand tags of every tag number, and tags may be of little value in applications where the implementation creating a particular CBOR data item and the implementation decoding that stream know the semantic meaning of each item in the data flow. The primary purpose of tags in this specification is to define common data types such as dates. A secondary purpose is to provide conversion hints when it is foreseen that the CBOR data item needs to be translated into a different format, requiring hints about the content of items. Understanding the semantics of tags is optional for a decoder; it can simply present both the tag number and the tag content to the application, without interpreting the additional semantics of the tag.

デコーダーは、すべてのタグ番号のタグを理解する必要はなく、特定のCBORデータアイテムを作成する実装と、そのストリームをデコードする実装がデータフロー内の各アイテムの意味を知っているアプリケーションでは、タグがあまり役に立たない場合があります。この仕様におけるタグの主な目的は、日付などの共通のデータ型を定義することです。2次的な目的は、アイテムの内容に関するヒントが必要な別の形式にCBORデータアイテムを変換する必要がある場合に、変換ヒントを提供することです。タグの意味を理解することは、デコーダーにとってオプションです。デコーダーは、単にタグ番号とタグコンテンツの両方をアプリケーションに提示し、タグの追加セマンティクスを解釈せずに済ませることができます。

A tag applies semantics to the data item it encloses. Tags can nest: if tag A encloses tag B, which encloses data item C, tag A applies to the result of applying tag B on data item C.

タグは、それが囲んでいるデータアイテムにセマンティクスを適用します。 タグはネストできます。つまり、タグAがタグBを囲み、タグBがデータアイテムCを囲む場合、タグAはデータアイテムCにタグBを適用した結果にタグを適用します。

IANA maintains a registry of tag numbers as described in Section 9.2. Table 5 provides a list of tag numbers that were defined in [RFC7049] with definitions in the rest of this section. (Tag number 35 was also defined in [RFC7049]; a discussion of this tag number follows in Section 3.4.5.3.) Note that many other tag numbers have been defined since the publication of [RFC7049]; see the registry described at Section 9.2 for the complete list.

IANAは、Section 9.2で説明されているように、タグ番号のレジストリを維持しています。 Table 5は、このセクションの残りの部分で定義されたタグ番号のリストを提供します。 （タグ番号35も RFC7049 で定義されています。このタグ番号に関する議論は、Section 3.4.5.3で続きます。） RFC7049 の発行以降、多くの他のタグ番号が定義されています。完全なリストについては、Section 9.2で説明されているレジストリを参照してください。

Conceptually, tags are interpreted in the generic data model, not at (de-)serialization time. A small number of tags (at this time, tag number 25 and tag number 29 [IANA.cbor-tags]) have been registered with semantics that may require processing at (de-)serialization time: the decoder needs to be aware of, and the encoder needs to be in control of, the exact sequence in which data items are encoded into the CBOR data item. This means these tags cannot be implemented on top of an arbitrary generic CBOR encoder/decoder (which might not reflect the serialization order for entries in a map at the data model level and vice versa); their implementation therefore typically needs to be integrated into the generic encoder/decoder. The definition of new tags with this property is NOT RECOMMENDED.

概念的には、タグは一般的なデータモデルで解釈され、(de-)シリアル化時に解釈されます。少数のタグ（現時点では、タグ番号25とタグ番号29[IANA.cbor-tags]）は、(de-)シリアル化時に処理が必要なセマンティクスで登録されています。デコーダーは、CBORデータアイテムにデータアイテムがエンコードされる正確なシーケンスを把握する必要があり、エンコーダーはその制御下にある必要があります。これは、これらのタグが任意の一般的なCBORエンコーダー/デコーダーの上に実装できないことを意味します（データモデルレベルのマップのエントリのシリアル化順序とその逆を反映しない可能性があるため）。そのため、これらのタグの実装は通常、一般的なエンコーダー/デコーダーに統合する必要があります。このようなプロパティを持つ新しいタグの定義は、推奨されません（NOT RECOMMENDED）。

IANA allocated tag numbers 65535, 4294967295, and 18446744073709551615 (binary all-ones in 16-bit, 32-bit, and 64-bit). These can be used as a convenience for implementers who want a single-integer data structure to indicate either the presence of a specific tag or absence of a tag. That allocation is described in Section 10 of [CBOR-TAGS]. These tags are not intended to occur in actual CBOR data items; implementations MAY flag such an occurrence as an error.

IANAは、タグ番号65535、4294967295、および18446744073709551615（16ビット、32ビット、および64ビットのすべてが1であるバイナリ）を割り当てました。 これらは、特定のタグの存在またはタグの不在を示す単一の整数データ構造を実装者が必要とする場合の便宜のために使用できます。 この割り当てについては、[CBOR-TAGS]のSection 10で説明されています。 これらのタグは、実際のCBORデータアイテムには出現しないことが意図されています。 実装は、そのような出現をエラーとしてフラグ付けしてもよいです（MAY）。

Protocols can extend the generic data model (Section 2) with data items representing points in time by using tag numbers 0 and 1, with arbitrarily sized integers by using tag numbers 2 and 3, and with floating-point values of arbitrary size and precision by using tag numbers 4 and 5.

プロトコルは、タグ番号0および1を使用して時間の点を表すデータアイテム、タグ番号2および3を使用して任意のサイズの整数、およびタグ番号4および5を使用して任意のサイズと精度の浮動小数点値を使用して、一般的なデータモデル(Section 2)を拡張することができます。

4.1. Preferred Serialization

4.1. 優先シリアル化

For some values at the data model level, CBOR provides multiple serializations. For many applications, it is desirable that an encoder always chooses a preferred serialization (preferred encoding); however, the present specification does not put the burden of enforcing this preference on either the encoder or decoder.

データモデルレベルの一部の値について、CBORは複数のシリアル化を提供しています。 多くのアプリケーションでは、エンコーダーが常に優先されるシリアル化（優先エンコーディング）を選択することが望ましいですが、この仕様書では、この優先順位をエンコーダーまたはデコーダーのどちらにも課すことはありません。

Some constrained decoders may be limited in their ability to decode non-preferred serializations: for example, if only integers below 1_000_000_000 (one billion) are expected in an application, the decoder may leave out the code that would be needed to decode 64-bit arguments in integers. An encoder that always uses preferred serialization ("preferred encoder") interoperates with this decoder for the numbers that can occur in this application. Generally speaking, a preferred encoder is more universally interoperable (and also less wasteful) than one that, say, always uses 64-bit integers.

いくつかの制約のあるデコーダーは、非優先シリアル化をデコードする能力に制限がある場合があります。たとえば、アプリケーションで1_000_000_000（10億）未満の整数のみが想定されている場合、デコーダーは整数の64ビット引数をデコードするために必要なコードを省略する場合があります。常に優先シリアル化（「優先エンコーダー」）を使用するエンコーダーは、このアプリケーションで発生する可能性のある数値に対してこのデコーダーと相互運用します。一般的に、優先エンコーダーは、64ビット整数を常に使用するエンコーダーよりも普遍的に相互運用可能であり（また、無駄が少ない）、より望ましいです。

Similarly, a constrained encoder may be limited in the variety of representation variants it supports such that it does not emit preferred serializations ("variant encoder"). For instance, a constrained encoder could be designed to always use the 32-bit variant for an integer that it encodes even if a short representation is available (assuming that there is no application need for integers that can only be represented with the 64-bit variant). A decoder that does not rely on receiving only preferred serializations ("variation-tolerant decoder") can therefore be said to be more universally interoperable (it might very well optimize for the case of receiving preferred serializations, though). Full implementations of CBOR decoders are by definition variation tolerant; the distinction is only relevant if a constrained implementation of a CBOR decoder meets a variant encoder.

同様に、制約のあるエンコーダーは、優先シリアル化を出力しないように設計されることがあります（「バリアントエンコーダー」）。たとえば、制約のあるエンコーダーは、64ビットバリアントが必要ない場合でも、常に32ビットバリアントを使用するように設計されることがあります（64ビットバリアントでしか表現できない整数がアプリケーションで必要ない場合）。優先シリアル化のみを受信することを前提としないデコーダー（「バリエーショントレラントデコーダー」）は、より普遍的に相互運用可能であると言えます（ただし、優先シリアル化を受信することを最適化することもできます）。CBORデコーダーの完全な実装は、定義上、バリエーショントレラントであり、制約のあるCBORデコーダーがバリアントエンコーダーに対応する場合にのみ、この区別が重要です。

The preferred serialization always uses the shortest form of representing the argument (Section 3); it also uses the shortest floating-point encoding that preserves the value being encoded.

優先シリアル化は、常に引数を表現する最短の形式を使用します（Section 3）。また、エンコードされる値を保持する最短の浮動小数点エンコーディングも使用します。

The preferred serialization for a floating-point value is the shortest floating-point encoding that preserves its value, e.g., 0xf94580 for the number 5.5, and 0xfa45ad9c00 for the number 5555.5. For NaN values, a shorter encoding is preferred if zero-padding the shorter significand towards the right reconstitutes the original NaN value (for many applications, the single NaN encoding 0xf97e00 will suffice).

浮動小数点値の優先シリアル化は、その値を保持する最短の浮動小数点エンコーディングを使用します。たとえば、数値5.5の場合は0xf94580、数値5555.5の場合は0xfa45ad9c00が使用されます。NaN値の場合、元のNaN値を再構成するために右側に向かって短い有効桁数をゼロでパディングできる場合、より短いエンコーディングが優先されます（多くのアプリケーションでは、単一のNaNエンコーディング0xf97e00が十分です）。

Definite-length encoding is preferred whenever the length is known at the time the serialization of the item starts.

長さがアイテムのシリアル化が開始される時点で既知である場合、明示的長さエンコーディングが優先されます。

4.2. Deterministically Encoded CBOR

4.2. 決定論的にエンコードされたCBOR

Some protocols may want encoders to only emit CBOR in a particular deterministic format; those protocols might also have the decoders check that their input is in that deterministic format. Those protocols are free to define what they mean by a "deterministic format" and what encoders and decoders are expected to do. This section defines a set of restrictions that can serve as the base of such a deterministic format.

一部のプロトコルでは、エンコーダーがCBORを特定の決定論的形式でのみ出力するように要求し、デコーダーが入力がその決定論的形式であることを確認することを望む場合があります。これらのプロトコルは、「決定論的形式」とは何を意味するか、エンコーダーとデコーダーが何をすることが期待されるかを定義できます。このセクションでは、そのような決定論的形式の基礎となる一連の制限を定義しています。

5.1. CBOR in Streaming Applications

5.1. ストリーミングアプリケーションにおけるCBOR

In a streaming application, a data stream may be composed of a sequence of CBOR data items concatenated back-to-back. In such an environment, the decoder immediately begins decoding a new data item if data is found after the end of a previous data item.

ストリーミングアプリケーションでは、データストリームは連結されたCBORデータアイテムのシーケンスで構成される場合があります。このような環境では、デコーダーは前のデータアイテムの終わりの後にデータが見つかった場合、すぐに新しいデータアイテムのデコードを開始します。

Not all of the bytes making up a data item may be immediately available to the decoder; some decoders will buffer additional data until a complete data item can be presented to the application. Other decoders can present partial information about a top-level data item to an application, such as the nested data items that could already be decoded, or even parts of a byte string that hasn't completely arrived yet. Such an application also MUST have a matching streaming security mechanism, where the desired protection is available for incremental data presented to the application.

データアイテムを構成するバイトのすべてがデコーダーにすぐに利用可能であるとは限りません。一部のデコーダーは、完全なデータアイテムがアプリケーションに提供されるまで、追加のデータをバッファリングします。他のデコーダーは、すでにデコードされたネストされたデータアイテムや、まだ完全に到着していないバイト文字列の一部など、トップレベルのデータアイテムに関する部分的な情報をアプリケーションに提供できます。 このようなアプリケーションは、ストリーミングセキュリティーメカニズムを持つ必要があります。この場合、アプリケーションに提供されるインクリメンタルデータに対して、必要な保護が利用可能である必要があります（MUST）

Note that some applications and protocols will not want to use indefinite-length encoding. Using indefinite-length encoding allows an encoder to not need to marshal all the data for counting, but it requires a decoder to allocate increasing amounts of memory while waiting for the end of the item. This might be fine for some applications but not others.

一部のアプリケーションやプロトコルでは、不定長エンコーディングを使用したくない場合があります。不定長エンコーディングを使用すると、エンコーダーはすべてのデータをカウントするためにマーシャリングする必要がなくなりますが、デコーダーはアイテムの終わりを待ちながら増加する量のメモリを割り当てる必要があります。これは、一部のアプリケーションにとっては問題ないかもしれませんが、他のアプリケーションには適していない場合があります。

5.2. Generic Encoders and Decoders

5.2. 汎用エンコーダーとデコーダー

A generic CBOR decoder can decode all well-formed encoded CBOR data items and present the data items to an application. See Appendix C. (The diagnostic notation, Section 8, may be used to present well-formed CBOR values to humans.)

一般的なCBORデコーダーは、すべての形式が正しいエンコードされたCBORデータアイテムをデコードし、アプリケーションにデータアイテムを提供できます。詳細は、Appendix Cを参照してください。 （診断表記法であるSection 8は、形式が正しいCBOR値を人間に提示するために使用できます。）

Generic CBOR encoders provide an application interface that allows the application to specify any well-formed value to be encoded as a CBOR data item, including simple values and tags unknown to the encoder.

一般的なCBORエンコーダーは、アプリケーションがエンコーダーに未知の単純な値やタグを含む、任意の形式が正しい値をCBORデータアイテムとしてエンコードするよう指定できるアプリケーションインタフェースを提供します。

Even though CBOR attempts to minimize these cases, not all well-formed CBOR data is valid: for example, the encoded text string 0x62c0ae does not contain valid UTF-8 (because [RFC3629] requires always using the shortest form) and so is not a valid CBOR item. Also, specific tags may make semantic constraints that may be violated, for instance, by a bignum tag enclosing another tag or by an instance of tag number 0 containing a byte string or containing a text string with contents that do not match the date-time production of [RFC3339]. There is no requirement that generic encoders and decoders make unnatural choices for their application interface to enable the processing of invalid data. Generic encoders and decoders are expected to forward simple values and tags even if their specific codepoints are not registered at the time the encoder/decoder is written (Section 5.4).

CBORはこれらのケースを最小限に抑えようとしますが、すべての形式が正しいCBORデータが有効であるわけではありません。たとえば、エンコードされたテキスト文字列0x62c0aeは有効なUTF-8を含んでいないため（[RFC3629]は常に最短の形式を使用することを要求するため）、有効なCBORアイテムではありません。 また、特定のタグは、別のタグを囲む大きな数値タグや、バイト文字列を含むタグ番号0のインスタンス、または内容が[RFC3339]のdate-timeプロダクションに一致しないテキスト文字列を含むテキスト文字列など、違反する可能性がある意味の制約を設ける場合があります。一般的なエンコーダーとデコーダーが、無効なデータの処理を可能にするために、アプリケーションインタフェースで不自然な選択をする必要はありません。一般的なエンコーダーとデコーダーは、特定のコードポイントがエンコーダー/デコーダーが書かれた時点で登録されていなくても、単純な値とタグを転送することが期待されます（Section 5.4）。

5.3. Validity of Items

5.3. アイテムの妥当性

A well-formed but invalid CBOR data item (Section 1.2) presents a problem with interpreting the data encoded in it in the CBOR data model. A CBOR-based protocol could be specified in several layers, in which the lower layers don't process the semantics of some of the CBOR data they forward. These layers can't notice any validity errors in data they don't process and MUST forward that data as-is. The first layer that does process the semantics of an invalid CBOR item MUST pick one of two choices:

形式が正しいが無効なCBORデータアイテム（Section 1.2）は、CBORデータモデルでエンコードされたデータを解釈する際に問題が発生します。CBORベースのプロトコルは、下位レイヤーが転送するCBORデータの意味を処理しない場合があります。これらのレイヤーは、処理しないデータの妥当性エラーに気付くことができず、そのデータをそのまま転送しなければなりません（MUST）。無効なCBORアイテムの意味を処理する最初のレイヤーは、次の2つの選択肢のいずれかを選択しなければなりません（MUST）。

1. Replace the problematic item with an error marker and continue with the next item, or
2. Issue an error and stop processing altogether.

1. 問題のあるアイテムをエラーマーカーで置き換え、次のアイテムを続けるか、
2. エラーを発行して処理を完全に停止するかのいずれかを行います。

A CBOR-based protocol MUST specify which of these options its decoders take for each kind of invalid item they might encounter.

CBORベースのプロトコルは、デコーダーが遭遇する可能性のある無効なアイテムの種類ごとに、どちらのオプションを取るかを指定しなければなりません（MUST）。

Such problems might occur at the basic validity level of CBOR or in the context of tags (tag validity).

このような問題は、CBORの基本的な妥当性レベルやタグの文脈（タグの妥当性）で発生する可能性があります。

5.4. Validity and Evolution

5.4. 妥当性と進化

A decoder with validity checking will expend the effort to reliably detect data items with validity errors. For example, such a decoder needs to have an API that reports an error (and does not return data) for a CBOR data item that contains any of the validity errors listed in the previous subsection.

妥当性チェックを行うデコーダーは、妥当性エラーを含むデータアイテムを信頼性高く検出するための努力を払います。たとえば、このようなデコーダーは、前のサブセクションにリストされている妥当性エラーのいずれかを含むCBORデータアイテムに対してエラーを報告するAPIを持つ必要があります（データを返さない）。

The set of tags defined in the "Concise Binary Object Representation (CBOR) Tags" registry (Section 9.2), as well as the set of simple values defined in the "Concise Binary Object Representation (CBOR) Simple Values" registry (Section 9.1), can grow at any time beyond the set understood by a generic decoder. A validity-checking decoder can do one of two things when it encounters such a case that it does not recognize:

「簡潔なバイナリオブジェクト表現（CBOR）タグ」レジストリ（Section 9.2）で定義されたタグのセット、および「簡潔なバイナリオブジェクト表現（CBOR）シンプルバリュー」レジストリ（Section 9.1）で定義されたシンプルバリューのセットは、汎用デコーダーが理解するセットを超えていつでも成長する可能性があります。妥当性チェックを行うデコーダーは、認識できない場合に2つのことを行うことができます。

• It can report an error (and not return data). Note that treating this case as an error can cause ossification and is thus not encouraged. This error is not a validity error, per se. This kind of error is more likely to be raised by a decoder that would be performing validity checking if this were a known case.
• It can emit the unknown item (type, value, and, for tags, the decoded tagged data item) to the application calling the decoder, and then give the application an indication that the decoder did not recognize that tag number or simple value.

• デコーダーはエラーを報告することができます（データを返さない）。 この場合をエラーとして扱うことは、硬直化を引き起こす可能性があるため、推奨されません。このエラーは、本質的に妥当性エラーではありません。このようなエラーは、既知の場合に妥当性チェックを実行しているデコーダーによってより頻繁に発生する可能性があります。
• デコーダーが認識できないタグ番号またはシンプルバリューがある場合、デコーダーは、未知のアイテム（タイプ、値、およびタグの場合はデコードされたタグ付きデータアイテム）を呼び出し元のアプリケーションに出力し、デコーダーがそのタグ番号またはシンプルバリューを認識できなかったことを示す指示をアプリケーションに与えることができます。

The latter approach, which is also appropriate for decoders that do not support validity checking, provides forward compatibility with newly registered tags and simple values without the requirement to update the encoder at the same time as the calling application. (For this, the decoder's API needs the ability to mark unknown items so that the calling application can handle them in a manner appropriate for the program.)

後者のアプローチは、妥当性チェックをサポートしていないデコーダーにも適しており、エンコーダーを呼び出すアプリケーションと同時に更新する必要がないまま、新しく登録されたタグやシンプルバリューとの前方互換性を提供します。 （これには、デコーダーのAPIが未知のアイテムをマークする機能が必要であり、呼び出し元のアプリケーションが適切な方法でそれらを処理できるようにする必要があります。）

Since some of the processing needed for validity checking may have an appreciable cost (in particular with duplicate detection for maps), support of validity checking is not a requirement placed on all CBOR decoders.

妥当性チェックに必要な処理の一部は、マップの重複検出に特にコストがかかる場合があるため、妥当性チェックのサポートはすべてのCBORデコーダーに要求される必要はありません。

Some encoders will rely on their applications to provide input data in such a way that valid CBOR results from the encoder. A generic encoder may also want to provide a validity-checking mode where it reliably limits its output to valid CBOR, independent of whether or not its application is indeed providing API-conformant data.

一部のエンコーダーは、アプリケーションがエンコーダーから有効なCBORを生成するように入力データを提供することを期待しています。汎用エンコーダーは、API準拠のデータを提供しているかどうかに関係なく、その出力を有効なCBORに限定する妥当性チェックモードを提供することも望むかもしれません。

5.5. Numbers

5.5. 数値

CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the basic JavaScript number system treats all numbers as floating-point values, which may result in the silent loss of precision in decoding integers with more than 53 significant bits. Another example is that, since CBOR keeps the sign bit for its integer representation in the major type, it has one bit more for signed numbers of a certain length (e.g., -2⁶⁴..2⁶⁴-1 for 1+8-byte integers) than the typical platform signed integer representation of the same length (-2⁶³..2⁶³-1 for 8-byte int64_t). A protocol that uses numbers should define its expectations on the handling of nontrivial numbers in decoders and receiving applications.

CBORベースのプロトコルは、異なる言語環境が表現可能な数値の範囲と精度に異なる制限を課すことを考慮する必要があります。たとえば、基本的なJavaScript数値システムは、すべての数値を浮動小数点値として扱うため、53ビット以上の有意なビットを持つ整数をデコードする際に精度の損失が発生する可能性があります。 また、CBORは、整数表現の符号ビットをメジャータイプに保持するため、同じ長さの典型的なプラットフォーム符号付き整数表現（8バイトint64_tの場合は-2⁶³..2⁶³-1）よりも、特定の長さの符号付き数値（たとえば、1 + 8バイト整数の場合は-2⁶⁴..2⁶⁴-1）に1ビット多くのビットがあります。 数値を使用するプロトコルは、デコーダーと受信アプリケーションで非自明な数値の処理に関する期待を定義する必要があります。

A CBOR-based protocol that includes floating-point numbers can restrict which of the three formats (half-precision, single-precision, and double-precision) are to be supported. For an integer-only application, a protocol may want to completely exclude the use of floating-point values.

浮動小数点数を含むCBORベースのプロトコルは、サポートするフォーマット（ハーフプレシジョン、シングルプレシジョン、ダブルプレシジョン）のうちどれを制限するかを制限することができます。整数のみのアプリケーションの場合、プロトコルは浮動小数点値の使用を完全に除外することができます。

A CBOR-based protocol designed for compactness may want to exclude specific integer encodings that are longer than necessary for the application, such as to save the need to implement 64-bit integers. There is an expectation that encoders will use the most compact integer representation that can represent a given value. However, a compact application that does not require deterministic encoding should accept values that use a longer-than-needed encoding (such as encoding "0" as 0b000_11001 followed by two bytes of 0x00) as long as the application can decode an integer of the given size. Similar considerations apply to floating-point values; decoding both preferred serializations and longer-than-needed ones is recommended.

コンパクト性を重視したCBORベースのプロトコルは、64ビット整数を実装する必要を省くために、アプリケーションに必要以上に長い特定の整数エンコーディングを除外することができます。エンコーダーは、特定の値を表現できるもっともコンパクトな整数表現を使用することが期待されています。ただし、決定論的エンコーディングを必要としないコンパクトなアプリケーションは、アプリケーションが指定されたサイズの整数をデコードできる限り、必要以上に長いエンコーディング（たとえば、「0」を0b000_11001にエンコードして、2バイトの0x00が続くようにエンコードする）を使用する値を受け入れる必要があります。 浮動小数点値にも同様の考慮事項が適用されます。推奨されるのは、最適なシリアル化と必要以上に長いシリアル化の両方をデコードすることです。

CBOR-based protocols for constrained applications that provide a choice between representing a specific number as an integer and as a decimal fraction or bigfloat (such as when the exponent is small and nonnegative) might express a quality-of-implementation expectation that the integer representation is used directly.

指数が小さく非負である場合など、特定の数を整数として表現するか、小数点以下の数値またはbigfloatとして表現することを選択できる制約されたアプリケーションのCBORベースのプロトコルは、整数表現が直接使用されることを期待する実装品質の期待値を表現する場合があります。

5.6. Specifying Keys for Maps

5.6. マップのキーの指定

The encoding and decoding applications need to agree on what types of keys are going to be used in maps. In applications that need to interwork with JSON-based applications, conversion is simplified by limiting keys to text strings only; otherwise, there has to be a specified mapping from the other CBOR types to text strings, and this often leads to implementation errors. In applications where keys are numeric in nature, and numeric ordering of keys is important to the application, directly using the numbers for the keys is useful.

エンコードおよびデコードアプリケーションは、マップで使用されるキーのタイプについて合意する必要があります。JSONベースのアプリケーションと相互運用する必要があるアプリケーションでは、キーをテキスト文字列に限定することで変換が簡素化されます。それ以外の場合、他のCBORタイプからテキスト文字列への指定されたマッピングが必要であり、これにより実装エラーが発生することがよくあります。キーが数値的な性質を持ち、キーの数値的な順序がアプリケーションにとって重要な場合、キーとして直接数値を使用することが有用です。

If multiple types of keys are to be used, consideration should be given to how these types would be represented in the specific programming environments that are to be used. For example, in JavaScript Maps [ECMA262], a key of integer 1 cannot be distinguished from a key of floating-point 1.0. This means that, if integer keys are used, the protocol needs to avoid the use of floating-point keys the values of which happen to be integer numbers in the same map.

複数の種類のキーを使用する場合、これらの種類が使用される特定のプログラミング環境でどのように表現されるかを考慮する必要があります。たとえば、JavaScript Maps [ECMA262]では、整数1のキーは浮動小数点1.0のキーと区別できません。これは、整数キーが使用される場合、プロトコルが同じマップ内の整数値である浮動小数点キーの使用を避ける必要があることを意味します。

Decoders that deliver data items nested within a CBOR data item immediately on decoding them ("streaming decoders") often do not keep the state that is necessary to ascertain uniqueness of a key in a map. Similarly, an encoder that can start encoding data items before the enclosing data item is completely available ("streaming encoder") may want to reduce its overhead significantly by relying on its data source to maintain uniqueness.

CBORデータアイテム内にネストされたデータアイテムをデコードするとすぐに（「ストリーミングデコーダー」）、マップ内のキーの一意性を確認するために必要な状態を保持しないことがよくあります。同様に、データアイテムを完全に利用可能にする前にデータアイテムのエンコードを開始できるエンコーダー（「ストリーミングエンコーダー」）は、データソースが一意性を維持することに依存して、オーバーヘッドを大幅に削減できます。

A CBOR-based protocol MUST define what to do when a receiving application sees multiple identical keys in a map. The resulting rule in the protocol MUST respect the CBOR data model: it cannot prescribe a specific handling of the entries with the identical keys, except that it might have a rule that having identical keys in a map indicates a malformed map and that the decoder has to stop with an error. When processing maps that exhibit entries with duplicate keys, a generic decoder might do one of the following:

CBORベースのプロトコルは、マップ内で複数の同じキーを持つエントリが見つかった場合に受信アプリケーションが何をするかを定義しなければなりません（MUST）。プロトコルによる結果のルールは、CBORデータモデルに準拠する必要があります。つまり、同じキーを持つエントリの処理方法を指定することはできず、ただし、マップ内に同じキーがある場合は、マップが不正なものであることを示すルールがある可能性があり、デコーダーがエラーで停止する必要があります。 重複するキーを持つエントリを含むマップを処理する場合、汎用デコーダーは次のいずれかを行うことがあります。

• Not accept maps with duplicate keys (that is, enforce validity for maps, see also Section 5.4). These generic decoders are universally useful. An application may still need to perform its own duplicate checking based on application rules (for instance, if the application equates integers and floating-point values in map key positions for specific maps).
• Pass all map entries to the application, including ones with duplicate keys. This requires that the application handle (check against) duplicate keys, even if the application rules are identical to the generic data model rules.
• Lose some entries with duplicate keys, e.g., deliver only the final (or first) entry out of the entries with the same key. With such a generic decoder, applications may get different results for a specific key on different runs, and with different generic decoders, which value is returned is based on generic decoder implementation and the actual order of keys in the map. In particular, applications cannot validate key uniqueness on their own as they do not necessarily see all entries; they may not be able to use such a generic decoder if they need to validate key uniqueness. These generic decoders can only be used in situations where the data source and transfer always provide valid maps; this is not possible if the data source and transfer can be attacked.

• マップ内に重複するキーがある場合は受け入れない（つまり、マップの妥当性を強制する。詳細はSection 5.4を参照）。これらの汎用デコーダーは普遍的に有用です。アプリケーションは、特定のマップにおいて整数と浮動小数点値をマップキーの位置で同等と見なす場合など、アプリケーションルールに基づいた重複チェックを自己実行する必要がある場合があります。
• 重複するキーを含むすべてのマップエントリをアプリケーションに渡す。これには、アプリケーションが重複するキーを処理する（チェックする）必要があるため、アプリケーションルールが汎用データモデルルールと同一である場合でも、重複するキーを処理する必要があります。
• 重複するキーを持つエントリのうち、最後のエントリ（または最初のエントリ）のみを配信するなど、一部のエントリを失う。このような汎用デコーダーを使用する場合、アプリケーションは、異なる実行や異なる汎用デコーダーを使用する場合に、特定のキーに対して異なる結果を得る可能性があります。どの値が返されるかは、汎用デコーダーの実装とマップ内のキーの実際の順序に基づいています。特に、アプリケーションは、すべてのエントリを見るわけではないため、自分自身でキーの一意性を検証することができないため、重複チェックを自己実行する必要がある場合があります。これらの汎用デコーダーは、データソースと転送が常に有効なマップを提供する場合にのみ使用できます。データソースと転送が攻撃される可能性がある場合、これは不可能です。

Generic decoders need to document which of these three approaches they implement.

汎用デコーダーは、これら3つのアプローチのうちどれを実装するかを文書化する必要があります。

The CBOR data model for maps does not allow ascribing semantics to the order of the key/value pairs in the map representation. Thus, a CBOR-based protocol MUST NOT specify that changing the key/value pair order in a map changes the semantics, except to specify that some orders are disallowed, for example, where they would not meet the requirements of a deterministic encoding (Section 4.2). (Any secondary effects of map ordering such as on timing, cache usage, and other potential side channels are not considered part of the semantics but may be enough reason on their own for a protocol to require a deterministic encoding format.)

マップのCBORデータモデルでは、マップ表現内のキー/値ペアの順序に意味を付与することはできません。したがって、CBORベースのプロトコルは、マップ内のキー/値ペアの順序を変更することが意味を変えることを指定してはなりません（MUST NOT）（ただし、決定論的エンコーディングの要件を満たさない場合など、一部の順序が許可されないことを指定することはできます。詳細はSection 4.2を参照）。（タイミング、キャッシュ使用、その他の潜在的なサイドチャネルなど、マップの順序による二次的な影響は意味の一部ではありませんが、プロトコルが決定論的エンコーディング形式を要求する理由となる可能性があります。）

Applications for constrained devices should consider using small integers as keys if they have maps with a small number of frequently used keys; for instance, a set of 24 or fewer keys can be encoded in a single byte as unsigned integers, up to 48 if negative integers are also used. Less frequently occurring keys can then use integers with longer encodings.

制約されたデバイス向けのアプリケーションでは、頻繁に使用されるキーの数が少ないマップがある場合は、小さな整数をキーとして使用することを検討する必要があります。たとえば、24個以下のキーのセットは、符号なし整数として1バイトでエンコードでき、負の整数も使用する場合は48個までエンコードできます。出現頻度の低いキーは、より長いエンコーディングを持つ整数を使用できます。

5.7. Undefined Values

5.7. Undefined値

In some CBOR-based protocols, the simple value (Section 3.3) of undefined might be used by an encoder as a substitute for a data item with an encoding problem, in order to allow the rest of the enclosing data items to be encoded without harm.

いくつかのCBORベースのプロトコルでは、エンコーダーがエンコーディングの問題を代替するためにundefinedのシンプル値（Section 3.3）を使用する場合があります。これにより、他の囲むデータアイテムを危険にさらすことなく、残りのデータアイテムをエンコードできるようになります。

6.1. Converting from CBOR to JSON

6.1. CBORからJSONへの変換

Most of the types in CBOR have direct analogs in JSON. However, some do not, and someone implementing a CBOR-to-JSON converter has to consider what to do in those cases. The following non-normative advice deals with these by converting them to a single substitute value, such as a JSON null.

CBORのほとんどのタイプには、JSONに直接対応するものがあります。ただし、一部には対応するものがないものもあり、CBORからJSONへの変換プログラムを実装する場合は、これらの場合にどのように対処するかを考慮する必要があります。次の非規範的なアドバイスは、これらを単一の代替値（JSON nullなど）に変換することで対処します。

• An integer (major type 0 or 1) becomes a JSON number.
• A byte string (major type 2) that is not embedded in a tag that specifies a proposed encoding is encoded in base64url without padding and becomes a JSON string.
• A UTF-8 string (major type 3) becomes a JSON string. Note that JSON requires escaping certain characters ([RFC8259], Section 7): quotation mark (U+0022), reverse solidus (U+005C), and the "C0 control characters" (U+0000 through U+001F). All other characters are copied unchanged into the JSON UTF-8 string.
• An array (major type 4) becomes a JSON array.
• A map (major type 5) becomes a JSON object. This is possible directly only if all keys are UTF-8 strings. A converter might also convert other keys into UTF-8 strings (such as by converting integers into strings containing their decimal representation); however, doing so introduces a danger of key collision. Note also that, if tags on UTF-8 strings are ignored as proposed below, this will cause a key collision if the tags are different but the strings are the same.
• False (major type 7, additional information 20) becomes a JSON false.
• True (major type 7, additional information 21) becomes a JSON true.
• Null (major type 7, additional information 22) becomes a JSON null.
• A floating-point value (major type 7, additional information 25 through 27) becomes a JSON number if it is finite (that is, it can be represented in a JSON number); if the value is non-finite (NaN, or positive or negative Infinity), it is represented by the substitute value.
• Any other simple value (major type 7, any additional information value not yet discussed) is represented by the substitute value.
• A bignum (major type 6, tag number 2 or 3) is represented by encoding its byte string in base64url without padding and becomes a JSON string. For tag number 3 (negative bignum), a "~" (ASCII tilde) is inserted before the base-encoded value. (The conversion to a binary blob instead of a number is to prevent a likely numeric overflow for the JSON decoder.)
• A byte string with an encoding hint (major type 6, tag number 21 through 23) is encoded as described by the hint and becomes a JSON string.
• For all other tags (major type 6, any other tag number), the tag content is represented as a JSON value; the tag number is ignored.
• Indefinite-length items are made definite before conversion.

• 整数（メジャータイプ0または1）はJSON数値になります。
• 提案されたエンコーディングを指定するタグに埋め込まれていないバイト文字列（メジャータイプ2）は、パディングのないbase64urlでエンコードされ、JSON文字列になります。
• UTF-8文字列（メジャータイプ3）はJSON文字列になります。ただし、JSONでは特定の文字（[RFC8259], Section 7）をエスケープする必要があります。これらの文字は、引用符（U+0022）、逆ソリッドスラッシュ（U+005C）、および「C0制御文字」（U+0000からU+001F）です。その他の文字は、JSON UTF-8文字列にそのままコピーされます。
• 配列（メジャータイプ4）はJSON配列になります。
• マップ（メジャータイプ5）はJSONオブジェクトになります。これは、すべてのキーがUTF-8文字列である場合にのみ直接可能です。コンバータは、他のキーをUTF-8文字列に変換することもできます（たとえば、整数を10進表記を含む文字列に変換することによって）。ただし、これを行うと、キーの衝突の危険性が生じます。また、UTF-8文字列のタグを以下で提案されるように無視する場合、タグが異なるが文字列が同じ場合にキーの衝突が発生することに注意してください。
• False（メジャータイプ7、追加情報20）はJSON falseになります。
• True（メジャータイプ7、追加情報21）はJSON trueになります。
• Null（メジャータイプ7、追加情報22）はJSON nullになります。
• 浮動小数点値（メジャータイプ7、追加情報25から27）は、有限である場合（つまり、JSON数値で表現できる場合）、JSON数値になります。値が有限でない場合（NaN、正のまたは負のInfinity）、代替値で表されます。
• その他のシンプル値（メジャータイプ7、まだ議論されていない任意の追加情報値）は、代替値で表されます。
• バイト文字列をbase64urlでパディングなしでエンコードすることにより、ビッグナンバー（メジャータイプ6、タグ番号2または3）はエンコードされ、JSON文字列になります。タグ番号3（負のビッグナンバー）の場合、ベースエンコードされた値の前に"~"（ASCIIチルダ）が挿入されます（JSONデコーダーの数値オーバーフローを防ぐために、数値ではなくバイナリブロブに変換されます）。
• エンコーディングヒントを持つバイト文字列（メジャータイプ6、タグ番号21から23）は、ヒントに記載されているようにエンコードされ、JSON文字列になります。
• その他のタグ（メジャータイプ6、その他のタグ番号）の場合、タグの内容はJSON値として表されます。タグ番号は無視されます。
• 変換前に、不定長アイテムは定長に変換されます。

A CBOR-to-JSON converter may want to keep to the JSON profile I-JSON [RFC7493], to maximize interoperability and increase confidence that the JSON output can be processed with predictable results. For example, this has implications on the range of integers that can be represented reliably, as well as on the top-level items that may be supported by older JSON implementations.

CBORからJSONへの変換プログラムは、相互運用性を最大化し、JSON出力が予測可能な結果で処理できることを保証するために、JSONプロファイルI-JSON[RFC7493]に従うことが望ましい場合があります。たとえば、これには、信頼性の高い整数の範囲に関する影響があります。また、古いJSON実装でサポートされる可能性のあるトップレベルアイテムにも影響があります。

6.2. Converting from JSON to CBOR

6.2. JSONからCBORへの変換

All JSON values, once decoded, directly map into one or more CBOR values. As with any kind of CBOR generation, decisions have to be made with respect to number representation. In a suggested conversion:

JSON値はすべて、デコードされた後、1つ以上のCBOR値に直接マップされます。CBORの生成に関しては、数値表現に関する決定を行う必要があります。提案される変換では、次のようになります。

• JSON numbers without fractional parts (integer numbers) are represented as integers (major types 0 and 1, possibly major type 6, tag number 2 and 3), choosing the shortest form; integers longer than an implementation-defined threshold may instead be represented as floating-point values. The default range that is represented as integer is -2⁵³+1..2⁵³-1 (fully exploiting the range for exact integers in the binary64 representation often used for decoding JSON [RFC7493]). A CBOR-based protocol, or a generic converter implementation, may choose -2³²..2³²-1 or -2⁶⁴..2⁶⁴-1 (fully using the integer ranges available in CBOR with uint32_t or uint64_t, respectively) or even -2³¹..2³¹-1 or -2⁶³..2⁶³-1 (using popular ranges for two's complement signed integers). (If the JSON was generated from a JavaScript implementation, its precision is already limited to 53 bits maximum.)
• Numbers with fractional parts are represented as floating-point values, performing the decimal-to-binary conversion based on the precision provided by IEEE 754 binary64. The mathematical value of the JSON number is converted to binary64 using the roundTiesToEven procedure in Section 4.3.1 of [IEEE754]. Then, when encoding in CBOR, the preferred serialization uses the shortest floating-point representation exactly representing this conversion result; for instance, 1.5 is represented in a 16-bit floating-point value (not all implementations will be capable of efficiently finding the minimum form, though). Instead of using the default binary64 precision, there may be an implementation-defined limit to the precision of the conversion that will affect the precision of the represented values. Decimal representation should only be used on the CBOR side if that is specified in a protocol.

• 小数部を持たないJSON数値（整数）は、整数（メジャータイプ0および1、おそらくメジャータイプ6、タグ番号2および3）として表され、最短の形式が選択されます。実装定義の閾値よりも長い整数は、代わりに浮動小数点値として表される場合があります。整数として表されるデフォルトの範囲は、-2⁵³+1..2⁵³-1であり、（JSONデコードによく使用されるbinary64表現で正確な整数の範囲を完全に活用する）。 CBORベースのプロトコルまたは汎用コンバータ実装では、uint32_tまたはuint64_tで利用可能な整数範囲を完全に使用するために、-2³²..2³²-1または-2⁶⁴..2⁶⁴-1を選択することができます。また、2の補数符号付き整数の人気のある範囲である-2³¹..2³¹-1または-2⁶³..2⁶³-1を使用することもできます。 （JSONがJavaScript実装から生成された場合、その精度はすでに最大53ビットに制限されています。）
• 小数部を持つ数値は、IEEE 754 binary64によって提供される精度に基づいて、浮動小数点値として表されます。JSON数値の数学的な値は、[IEEE754]のセクション4.3.1のroundTiesToEven手順を使用して、binary64に変換されます。その後、CBORでエンコードする際に、最短の浮動小数点表現が使用され、この変換結果を正確に表します。たとえば、1.5は16ビットの浮動小数点値で表されます（すべての実装が最小形式を効率的に見つけることができるわけではありません）。デフォルトのbinary64精度を使用する代わりに、変換の精度に影響を与える実装定義の精度制限がある場合があります。10進表記は、プロトコルで指定されている場合を除き、CBOR側でのみ使用する必要があります。

CBOR has been designed to generally provide a more compact encoding than JSON. One implementation strategy that might come to mind is to perform a JSON-to-CBOR encoding in place in a single buffer. This strategy would need to carefully consider a number of pathological cases, such as that some strings represented with no or very few escapes and longer (or much longer) than 255 bytes may expand when encoded as UTF-8 strings in CBOR. Similarly, a few of the binary floating-point representations might cause expansion from some short decimal representations (1.1, 1e9) in JSON. This may be hard to get right, and any ensuing vulnerabilities may be exploited by an attacker.

CBORは、一般的にJSONよりもコンパクトなエンコーディングを提供するように設計されています。1つの実装戦略は、JSON-to-CBORエンコーディングを単一のバッファ内で実行することです。この戦略では、いくつかの病的なケースを注意深く考慮する必要があります。たとえば、255バイトよりも長く（またははるかに長く）エスケープがない文字列がいくつかあり、CBORでUTF-8文字列としてエンコードされると拡張される可能性があります。同様に、一部のバイナリ浮動小数点表現は、JSONの短い10進表記（1.1、1e9）から拡張される可能性があります。これを正しく行うことは難しい場合があり、その後の脆弱性は攻撃者によって悪用される可能性があります。

7.1. Extension Points

7.1. 拡張ポイント

In a protocol design, opportunities for evolution are often included in the form of extension points. For example, there may be a codepoint space that is not fully allocated from the outset, and the protocol is designed to tolerate and embrace implementations that start using more codepoints than initially allocated.

プロトコル設計において、進化の機会はしばしば拡張ポイントの形で含まれます。たとえば、最初から完全に割り当てられていないコードポイントスペースがある場合があり、プロトコルは、最初に割り当てられたコードポイントよりも多くのコードポイントを使用し始める実装を許容し、受け入れるように設計されています。

Sizing the codepoint space may be difficult because the range required may be hard to predict. Protocol designs should attempt to make the codepoint space large enough so that it can slowly be filled over the intended lifetime of the protocol.

コードポイントスペースのサイズを決定することは困難な場合があります。必要な範囲を予測することが難しいためです。プロトコル設計では、コードポイントスペースが十分に大きくなるように設計する必要があります。これにより、プロトコルの寿命中にゆっくりと埋められるようになります。

CBOR has three major extension points:

CBOR has three major extension points:

the "simple" space (values in major type 7):

Of the 24 efficient (and 224 slightly less efficient) values, only a small number have been allocated. Implementations receiving an unknown simple data item may easily be able to process it as such, given that the structure of the value is indeed simple. The IANA registry in Section 9.1 is the appropriate way to address the extensibility of this codepoint space.

the "tag" space (values in major type 6):

The total codepoint space is abundant; only a tiny part of it has been allocated. However, not all of these codepoints are equally efficient: the first 24 only consume a single ("1+0") byte, and half of them have already been allocated. The next 232 values only consume two ("1+1") bytes, with nearly a quarter already allocated. These subspaces need some curation to last for a few more decades. Implementations receiving an unknown tag number can choose to process just the enclosed tag content or, preferably, to process the tag as an unknown tag number wrapping the tag content. The IANA registry in Section 9.2 is the appropriate way to address the extensibility of this codepoint space.

the "additional information" space:

An implementation receiving an unknown additional information value has no way to continue decoding, so allocating codepoints in this space is a major step beyond just exercising an extension point. There are also very few codepoints left. See also Section 7.2.

「simple」スペース（メジャータイプ7の値）：

24の効率的な値（および224のやや効率的である値）のうち、ごくわずかしか割り当てられていません。不明なシンプルデータアイテムを受信した実装は、値の構造が実際にシンプルである場合、それを処理することができる場合があります。IANAレジストリは、このコードポイントスペースの拡張性をアドレスするための適切な方法です。Section 9.1。

「tag」スペース（メジャータイプ6の値）：

総コードポイントスペースは豊富ですが、そのうちごく一部しか割り当てられていません。ただし、これらのコードポイントがすべて同じ効率であるわけではありません。最初の24個は1つの（「1 + 0」）バイトしか消費せず、そのうちの半分がすでに割り当てられています。次の232個の値は2つの（「1 + 1」）バイトしか消費せず、そのうちの約4分の1がすでに割り当てられています。これらのサブスペースは、数十年間持続するためにいくつかの手入れが必要です。不明なタグ番号を受信した実装は、包含されたタグコンテンツだけを処理するか、好ましくは、タグコンテンツを包む不明なタグ番号としてタグを処理することができます。IANAレジストリは、このコードポイントスペースの拡張性をアドレスするための適切な方法です。Section 9.2。

「additional information」スペース：

不明な追加情報値を受信した実装は、デコードを続行する方法がありません。したがって、このスペースにコードポイントを割り当てることは、拡張ポイントを実行する以上の大きなステップです。残りのコードポイントも非常に少ないです。詳細については、Section 7.2も参照してください。

7.2. Curating the Additional Information Space

7.2. 追加情報スペースのキュレーション

The human mind is sometimes drawn to filling in little perceived gaps to make something neat. We expect the remaining gaps in the codepoint space for the additional information values to be an attractor for new ideas, just because they are there.

人間の心は、何かを整然とさせるために、時には小さな認識された隙間を埋めることに引き寄せられることがあります。追加情報値のコードポイントスペースの残りの隙間が、新しいアイデアの引き寄せ子になることを期待しています。それらがあるからです。

The present specification does not manage the additional information codepoint space by an IANA registry. Instead, allocations out of this space can only be done by updating this specification.

現在の仕様では、追加情報のコードポイントスペースはIANAレジストリによって管理されていません。このスペースからの割り当ては、この仕様を更新することによってのみ行うことができます。

For an additional information value of n >= 24, the size of the additional data typically is 2^n-24 bytes. Therefore, additional information values 28 and 29 should be viewed as candidates for 128-bit and 256-bit quantities, in case a need arises to add them to the protocol. Additional information value 30 is then the only additional information value available for general allocation, and there should be a very good reason for allocating it before assigning it through an update of the present specification.

追加情報値n（n≥24）の場合、追加データのサイズは通常2^n-24バイトです。したがって、追加情報値28および29は、プロトコルに追加する必要がある場合に128ビットおよび256ビットの数量の候補として見なす必要があります。追加情報値30は、一般的な割り当て用に利用可能な唯一の追加情報値であり、現在の仕様の更新を介して割り当てる前に非常に良い理由がある必要があります。

8.1. Encoding Indicators

8.1. エンコーディング指示子

Sometimes it is useful to indicate in the diagnostic notation which of several alternative representations were actually used; for example, a data item written >1.5< by a diagnostic decoder might have been encoded as a half-, single-, or double-precision float.

診断表記法では、実際に使用された複数の代替表現のうち、どれが使用されたかを示すことがあると便利な場合があります。たとえば、診断デコーダーによって>1.5<と書かれたデータアイテムは、ハーフ、シングル、またはダブル精度の浮動小数点数としてエンコードされている可能性があります。

The convention for encoding indicators is that anything starting with an underscore and all following characters that are alphanumeric or underscore is an encoding indicator, and can be ignored by anyone not interested in this information. For example, _ or _3. Encoding indicators are always optional.

エンコーディングインジケータの規約は、アンダースコアで始まり、その後のすべての英数字またはアンダースコアがエンコーディングインジケータであることであり、この情報に関心のない人は無視できます。たとえば、_または_3。エンコーディングインジケータは常にオプションです。

A single underscore can be written after the opening brace of a map or the opening bracket of an array to indicate that the data item was represented in indefinite-length format. For example, [_ 1, 2] contains an indicator that an indefinite-length representation was used to represent the data item [1, 2].

マップの開始括弧の後または配列の開始括弧の後に単一のアンダースコアを書くことで、データアイテムが不定長形式で表現されたことを示すことができます。たとえば、[_ 1, 2]には、データアイテム[1, 2]が不定長形式で表現されたことを示すインジケータが含まれています。

An underscore followed by a decimal digit n indicates that the preceding item (or, for arrays and maps, the item starting with the preceding bracket or brace) was encoded with an additional information value of 24+n. For example, 1.5_1 is a half-precision floating-point number, while 1.5_3 is encoded as double precision. This encoding indicator is not shown in Appendix A. (Note that the encoding indicator "_" is thus an abbreviation of the full form "_7", which is not used.)

アンダースコアの後に10進数の数字nが続く場合、前のアイテム（または配列やマップの場合は、前の括弧またはブレースで始まるアイテム）が、追加情報値24+nでエンコードされたことを示します。たとえば、1.5_1は半精度浮動小数点数であり、1.5_3は倍精度でエンコードされます。このエンコーディングインジケータはAppendix Aには表示されません。（エンコーディングインジケータ"_"は、使用されない完全な形式"_7"の略語であることに注意してください。）

The detailed chunk structure of byte and text strings of indefinite length can be notated in the form (_ h'0123', h'4567') and (_ "foo", "bar"). However, for an indefinite-length string with no chunks inside, (_ ) would be ambiguous as to whether a byte string (0x5fff) or a text string (0x7fff) is meant and is therefore not used. The basic forms ''_ and ""_ can be used instead and are reserved for the case of no chunks only -- not as short forms for the (permitted, but not really useful) encodings with only empty chunks, which need to be notated as (_ ''), (_ ""), etc., to preserve the chunk structure.

不定長のバイト文字列とテキスト文字列の詳細なチャンク構造は、(_ h'0123', h'4567')および(_ "foo", "bar")の形式で表記できます。ただし、内部にチャンクがない不定長文字列の場合、(_ )はバイト文字列（0x5fff）またはテキスト文字列（0x7fff）のどちらを意味するか不明確であり、使用されません。 基本形式''_および""_は、チャンクがない場合にのみ使用でき、空のチャンクのみを持つ（許可されていますが、実際にはあまり有用ではない）エンコーディングは(_ '')、(_ "")などと表記する必要があります。チャンク構造を保持するために。

9.1. CBOR Simple Values Registry

9.1. CBOR Simple Values Registry

IANA has created the "Concise Binary Object Representation (CBOR) Simple Values" registry at [IANA.cbor-simple-values]. The initial values are shown in Table 4.

IANAは、[Concise Binary Object Representation (CBOR) Simple Values]レジストリを作成しました。初期値はTable 4に示されています。

New entries in the range 0 to 19 are assigned by Standards Action [RFC8126]. It is suggested that IANA allocate values starting with the number 16 in order to reserve the lower numbers for contiguous blocks (if any).

0から19の範囲の新しいエントリは、標準アクションによって割り当てられます。割り当ては、[RFC8126]によって行われます。連続するブロック（ある場合）の下位番号を予約するために、IANAが16から始まる値を割り当てることが提案されています。

New entries in the range 32 to 255 are assigned by Specification Required.

32から255の範囲の新しいエントリは、Specification Requiredによって割り当てられます。

9.2. CBOR Tags Registry

9.2. CBOR Tags Registry

IANA has created the "Concise Binary Object Representation (CBOR) Tags" registry at [IANA.cbor-tags]. The tags that were defined in [RFC7049] are described in detail in Section 3.4, and other tags have already been defined since then.

IANAは、[IANA.cbor-tags]において、「Concise Binary Object Representation (CBOR) Tags」レジストリを作成しました。[RFC7049]で定義されたタグについては、Section 3.4で詳しく説明されており、その後も他のタグが定義されています。

New entries in the range 0 to 23 ("1+0") are assigned by Standards Action. New entries in the ranges 24 to 255 ("1+1") and 256 to 32767 (lower half of "1+2") are assigned by Specification Required. New entries in the range 32768 to 18446744073709551615 (upper half of "1+2", "1+4", and "1+8") are assigned by First Come First Served. The template for registration requests is:

0から23の範囲の新しいエントリは、標準アクションによって割り当てられます。 24から255（"1+1"）および256から32767（"1+2"の下位半分）の範囲の新しいエントリは、Specification Requiredによって割り当てられます。32768から18446744073709551615（"1+2"の上位半分、"1+4"、および"1+8"）の範囲の新しいエントリは、First Come First Servedによって割り当てられます。登録リクエストのテンプレートは以下のとおりです。

• Data item
• Semantics (short form)

• データアイテム
• 意味（短い形式）

In addition, First Come First Served requests should include:

さらに、First Come First Servedリクエストには、以下が含まれる必要があります。

• Point of contact
• Description of semantics (URL) -- This description is optional; the URL can point to something like an Internet-Draft or a web page.

• 連絡先
• 意味の説明（URL）-- この説明はオプションです。URLは、インターネットドラフトやWebページのようなものを指すことができます。

Applicants exercising the First Come First Served range and making a suggestion for a tag number that is not representable in 32 bits (i.e., larger than 4294967295) should be aware that this could reduce interoperability with implementations that do not support 64-bit numbers.

First Come First Served範囲を使用し、32ビットで表現できない（つまり、4294967295より大きい）タグ番号の提案を行う申請者は、64ビットの数値をサポートしていない実装との相互運用性が低下する可能性があることに注意する必要があります。

9.3. Media Types Registry

9.3. Media Types Registry

The Internet media type [RFC6838] ("MIME type") for a single encoded CBOR data item is "application/cbor" as defined in the "Media Types" registry [IANA.media-types]:

単一のエンコードされたCBORデータアイテムのインターネットメディアタイプ[RFC6838]（「MIMEタイプ」）は、「Media Types」レジストリ[IANA.media-types]で定義されている「application/cbor」です。

Type name:

application

Subtype name:

cbor

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

Binary

Security considerations:

See Section 10 of RFC 8949.

Interoperability considerations:

n/a

Published specification:

RFC 8949

Applications that use this media type:

Many

Additional information:

Magic number(s):

n/a

File extension(s):

.cbor

Macintosh file type code(s):

n/a

Person & email address to contact for further information:

IETF CBOR Working Group (cbor@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author:

IETF CBOR Working Group (cbor@ietf.org)

Change controller:

The IESG (iesg@ietf.org)

タイプ名:

application

サブタイプ名:

cbor

必須パラメータ:

なし

オプションパラメータ:

なし

エンコードに関する考慮事項:

バイナリ

セキュリティーに関する考慮事項:

RFC 8949のSection 10を参照してください。

相互運用性に関する考慮事項:

なし

公開された仕様:

RFC 8949

このメディアタイプを使用するアプリケーション:

多数

追加情報:

マジックナンバー:

なし

ファイル拡張子:

.cbor

Macintoshファイルタイプコード:

なし

詳細情報の連絡先とメールアドレス:

IETF CBOR Working Group (cbor@ietf.org) または IETF Applications and Real-Time Area (art@ietf.org)

使用目的:

共通

使用上の制限:

なし

著者:

IETF CBOR Working Group (cbor@ietf.org)

変更管理者:

The IESG (iesg@ietf.org)

9.4. CoAP Content-Format Registry

9.4. CoAP Content-Format Registry

The CoAP Content-Format for CBOR has been registered in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry [IANA.core-parameters]:

CBORのCoAPコンテンツフォーマットは、「Constrained RESTful Environments (CoRE) Parameters」レジストリ[IANA.core-parameters]内の「CoAP Content-Formats」サブレジストリに登録されています。

Media Type:

application/cbor

Encoding:

-

ID:

60

Reference:

RFC 8949

メディアタイプ:

application/cbor

エンコーディング:

-

ID:

60

参照:

RFC 8949

9.5. Structured Syntax Suffix Registry

9.5. Structured Syntax Suffix Registry

The structured syntax suffix [RFC6838] for media types based on a single encoded CBOR data item is +cbor, which IANA has registered in the "Structured Syntax Suffixes" registry [IANA.structured-suffix]:

単一のエンコードされたCBORデータアイテムに基づくメディアタイプの構造化構文サフィックスは、+cborであり、IANAは「Structured Syntax Suffixes」レジストリ[IANA.structured-suffix]に登録しています。[RFC6838]。

Name:

Concise Binary Object Representation (CBOR)

+suffix:

+cbor

References:

RFC 8949

Encoding Considerations:

CBOR is a binary format.

Interoperability Considerations:

n/a

Fragment Identifier Considerations:

The syntax and semantics of fragment identifiers specified for +cbor SHOULD be as specified for "application/cbor". (At publication of RFC 8949, there is no fragment identification syntax defined for "application/cbor".)

The syntax and semantics for fragment identifiers for a specific "xxx/yyy+cbor" SHOULD be processed as follows:

• For cases defined in +cbor, where the fragment identifier resolves per the +cbor rules, then process as specified in +cbor.
• For cases defined in +cbor, where the fragment identifier does not resolve per the +cbor rules, then process as specified in "xxx/yyy+cbor".
• For cases not defined in +cbor, then process as specified in "xxx/yyy+cbor".

Security Considerations:

See Section 10 of RFC 8949.

Contact:

IETF CBOR Working Group (cbor@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)

Author/Change Controller:

IETF

名前:

Concise Binary Object Representation (CBOR)

+suffix:

+cbor

参照:

RFC 8949

エンコードに関する考慮事項:

CBORはバイナリ形式です。

相互運用性に関する考慮事項:

なし

フラグメント識別子に関する考慮事項:

+cborのために指定されたフラグメント識別子の構文と意味は、「application/cbor」のために指定されたものと同じであるべきです。（RFC 8949の発行時点では、「application/cbor」のためにフラグメント識別子の構文が定義されていません。）

特定の「xxx/yyy+cbor」のフラグメント識別子の構文と意味は、以下のように処理する必要があります。

• +cborで定義された場合、フラグメント識別子が+cborのルールに従って解決される場合は、+cborで指定されたように処理します。
• +cborで定義された場合、フラグメント識別子が+cborのルールに従って解決されない場合は、「xxx/yyy+cbor」で指定されたように処理します。
• +cborで定義されていない場合は、「xxx/yyy+cbor」で指定されたように処理します。

セキュリティーに関する考慮事項:

RFC 8949のSection 10を参照してください。

連絡先:

IETF CBOR Working Group (cbor@ietf.org) または IETF Applications and Real-Time Area (art@ietf.org)

著者/変更管理者:

IETF

E.1. ASN.1 DER, BER, and PER

E.1. ASN.1 DER, BER, and PER

[ASN.1] has many serializations. In the IETF, DER and BER are the most common. The serialized output is not particularly compact for many items, and the code needed to decode numeric items can be complex on a constrained device.

[ASN.1]には多くのシリアル化形式があります。IETFでは、DERとBERがもっとも一般的です。多くのアイテムに対してシリアル化された出力はとくにコンパクトではなく、数値アイテムをデコードするために必要なコードは、制約されたデバイス上で複雑になる可能性があります。

Few (if any) IETF protocols have adopted one of the several variants of Packed Encoding Rules (PER). There could be many reasons for this, but one that is commonly stated is that PER makes use of the schema even for parsing the surface structure of the data item, requiring significant tool support. There are different versions of the ASN.1 schema language in use, which has also hampered adoption.

IETFプロトコルのほとんどは、Packed Encoding Rules（PER）のいくつかのバリアントのいずれかを採用していません。これには多くの理由が考えられますが、一般的には、PERはデータアイテムの表面構造を解析するためにスキーマを使用するため、重要なツールサポートが必要となることが挙げられます。使用されているASN.1スキーマ言語には、さまざまなバージョンがあり、これも採用を妨げています。

E.2. MessagePack

E.2. MessagePack

[MessagePack] is a concise, widely implemented counted binary serialization format, similar in many properties to CBOR, although somewhat less regular. While the data model can be used to represent JSON data, MessagePack has also been used in many remote procedure call (RPC) applications and for long-term storage of data.

[MessagePack]は、簡潔で広く実装されたバイナリシリアル化形式であり、CBORに多くの特性が似ていますが、やや規則性が低いです。データモデルはJSONデータを表すために使用できますが、MessagePackは多くのリモートプロシージャコール（RPC）アプリケーションやデータの長期保存にも使用されています。

MessagePack has been essentially stable since it was first published around 2011; it has not yet had a transition. The evolution of MessagePack is impeded by an imperative to maintain complete backwards compatibility with existing stored data, while only few bytecodes are still available for extension. Repeated requests over the years from the MessagePack user community to separate out binary and text strings in the encoding recently have led to an extension proposal that would leave MessagePack's "raw" data ambiguous between its usages for binary and text data. The extension mechanism for MessagePack remains unclear.

MessagePackは、2011年頃に最初に公開されて以来、基本的に安定しています。まだ移行していません。MessagePackの進化は、既存の格納されたデータとの完全な後方互換性を維持する必要があるという命令によって妨げられています。拡張のために使用可能なバイトコードがわずかしかないためです。エンコーディングでバイナリとテキスト文字列を分離するようにMessagePackユーザーコミュニティから何年にもわたって繰り返し要求があり、最近、バイナリとテキストデータの使用法の間でMessagePackの「生」データが曖昧になる拡張提案が行われました。MessagePackの拡張メカニズムは未解決のままです。

E.3. BSON

E.3. BSON

[BSON] is a data format that was developed for the storage of JSON-like maps (JSON objects) in the MongoDB database. Its major distinguishing feature is the capability for in-place update, which prevents a compact representation. BSON uses a counted representation except for map keys, which are null-byte terminated. While BSON can be used for the representation of JSON-like objects on the wire, its specification is dominated by the requirements of the database application and has become somewhat baroque. The status of how BSON extensions will be implemented remains unclear.

[BSON]は、MongoDBデータベース内でJSONのようなマップ（JSONオブジェクト）を格納するために開発されたデータ形式です。その主な特徴は、インプレース更新の機能であり、コンパクトな表現を妨げます。BSONは、マップキーを除いて、カウントされた表現を使用します。マップキーはヌルバイトで終了します。BSONは、ワイヤ上のJSONのようなオブジェクトの表現に使用できますが、その仕様はデータベースアプリケーションの要件に支配され、やや複雑になっています。BSON拡張の実装方法の状況は未解決のままです。

E.4. MSDTP: RFC 713

E.4. MSDTP: RFC 713

Message Services Data Transmission (MSDTP) is a very early example of a compact message format; it is described in [RFC0713], written in 1976. It is included here for its historical value, not because it was ever widely used.

メッセージサービスデータ転送（MSDTP）は、コンパクトなメッセージ形式の非常に初期の例です。1976年に書かれた[RFC0713]で説明されています。広く使用されたわけではないため、歴史的価値のためにここに含められています。

E.5. Conciseness on the Wire

E.5. Conciseness on the Wire

While CBOR's design objective of code compactness for encoders and decoders is a higher priority than its objective of conciseness on the wire, many people focus on the wire size. Table 8 shows some encoding examples for the simple nested array [1, [2, 3]]; where some form of indefinite-length encoding is supported by the encoding, [_ 1, [2, 3]] (indefinite length on the outer array) is also shown.

CBORのエンコーダーとデコーダーのコードのコンパクトさに関する設計目標は、ワイヤ上の簡潔さよりも優先されますが、多くの人々はワイヤサイズに焦点を当てています。 Table 8は、エンコーディングでいくつかの形式の無限長エンコーディングがサポートされている場合に、単純なネストされた配列[1、[2、3]]のエンコーディング例を示しています。[_ 1、[2、3]]（外部配列の長さが不定の場合）も示されています。

F.1. Examples of CBOR Data Items That Are Not Well-Formed

F.1. ウェルフォームでないCBORデータアイテムの例

This subsection shows a few examples for CBOR data items that are not well-formed. Each example is a sequence of bytes, each shown in hexadecimal; multiple examples in a list are separated by commas.

このサブセクションでは、ウェルフォームでないCBORデータアイテムのいくつかの例を示します。各例はバイトのシーケンスであり、それぞれ16進数で表示されます。リスト内の複数の例は、カンマで区切られます。

Examples for well-formedness error kind 1 (too much data) can easily be formed by adding data to a well-formed encoded CBOR data item.

ウェルフォームエラーの種類1（データが多すぎる）の例は、ウェルフォームエンコードされたCBORデータアイテムにデータを追加することで簡単に形成できます。

Similarly, examples for well-formedness error kind 2 (too little data) can be formed by truncating a well-formed encoded CBOR data item. In test suites, it may be beneficial to specifically test with incomplete data items that would require large amounts of addition to be completed (for instance by starting the encoding of a string of a very large size).

同様に、ウェルフォームエラーの種類2（データが少なすぎる）の例は、ウェルフォームエンコードされたCBORデータアイテムを切り捨てることで簡単に形成できます。テストスイートでは、非常に大きなサイズの文字列のエンコードを開始することによって、大量の追加が必要な不完全なデータ項目でとくにテストすることが有益である場合があります。

A premature end of the input can occur in a head or within the enclosed data, which may be bare strings or enclosed data items that are either counted or should have been ended by a "break" stop code.

入力の早期終了は、ヘッド内または囲まれたデータ内で発生する可能性があります。囲まれたデータは、カウントされたものまたは「break」ストップコードで終了する必要があるものである場合があります。

End of input in a head:

18, 19, 1a, 1b, 19 01, 1a 01 02, 1b 01 02 03 04 05 06 07, 38, 58, 78, 98, 9a 01 ff 00, b8, d8, f8, f9 00, fa 00 00, fb 00 00 00

Definite-length strings with short data:

41, 61, 5a ff ff ff ff 00, 5b ff ff ff ff ff ff ff ff 01 02 03, 7a ff ff ff ff 00, 7b 7f ff ff ff ff ff ff ff 01 02 03

Definite-length maps and arrays not closed with enough items:

81, 81 81 81 81 81 81 81 81 81, 82 00, a1, a2 01 02, a1 00, a2 00 00 00

Tag number not followed by tag content:

c0

Indefinite-length strings not closed by a "break" stop code:

5f 41 00, 7f 61 00

Indefinite-length maps and arrays not closed by a "break" stop code:

9f, 9f 01 02, bf, bf 01 02 01 02, 81 9f, 9f 80 00, 9f 9f 9f 9f 9f ff ff ff ff, 9f 81 9f 81 9f 9f ff ff ff

ヘッド内で入力が終了:

18, 19, 1a, 1b, 19 01, 1a 01 02, 1b 01 02 03 04 05 06 07, 38, 58, 78, 98, 9a 01 ff 00, b8, d8, f8, f9 00, fa 00 00, fb 00 00 00

短いデータを持つ定義済み長さの文字列:

41, 61, 5a ff ff ff ff 00, 5b ff ff ff ff ff ff ff ff 01 02 03, 7a ff ff ff ff 00, 7b 7f ff ff ff ff ff ff ff 01 02 03

十分なアイテムで閉じられていない定義済み長さのマップと配列:

81, 81 81 81 81 81 81 81 81 81, 82 00, a1, a2 01 02, a1 00, a2 00 00 00

タグ番号に続くタグコンテンツがない場合:

c0

「break」ストップコードで閉じられていない不定長文字列:

5f 41 00, 7f 61 00

「break」ストップコードで閉じられていない不定長マップと配列:

9f, 9f 01 02, bf, bf 01 02 01 02, 81 9f, 9f 80 00, 9f 9f 9f 9f 9f ff ff ff ff, 9f 81 9f 81 9f 9f ff ff ff

A few examples for the five subkinds of well-formedness error kind 3 (syntax error) are shown below.

ウェルフォームエラーの種類3（構文エラー）のいくつかの例を以下に示します。

Subkind 1:

Reserved additional information values:

1c, 1d, 1e, 3c, 3d, 3e, 5c, 5d, 5e, 7c, 7d, 7e, 9c, 9d, 9e, bc, bd, be, dc, dd, de, fc, fd, fe,

Subkind 2:

Reserved two-byte encodings of simple values:

f8 00, f8 01, f8 18, f8 1f

Subkind 3:

Indefinite-length string chunks not of the correct type:

5f 00 ff, 5f 21 ff, 5f 61 00 ff, 5f 80 ff, 5f a0 ff, 5f c0 00 ff, 5f e0 ff, 7f 41 00 ff

Indefinite-length string chunks not definite length:

5f 5f 41 00 ff ff, 7f 7f 61 00 ff ff

Subkind 4:

Break occurring on its own outside of an indefinite-length item:

ff

Break occurring in a definite-length array or map or a tag:

81 ff, 82 00 ff, a1 ff, a1 ff 00, a1 00 ff, a2 00 00 ff, 9f 81 ff, 9f 82 9f 81 9f 9f ff ff ff ff

Break in an indefinite-length map that would lead to an odd number of items (break in a value position):

bf 00 ff, bf 00 00 00 ff

Subkind 5:

Major type 0, 1, 6 with additional information 31:

1f, 3f, df

Subkind 1:

予約された追加情報値:

1c, 1d, 1e, 3c, 3d, 3e, 5c, 5d, 5e, 7c, 7d, 7e, 9c, 9d, 9e, bc, bd, be, dc, dd, de, fc, fd, fe,

Subkind 2:

単純な値の予約された2バイトエンコーディング:

f8 00, f8 01, f8 18, f8 1f

Subkind 3:

正しいタイプでない不定長文字列のチャンク:

5f 00 ff, 5f 21 ff, 5f 61 00 ff, 5f 80 ff, 5f a0 ff, 5f c0 00 ff, 5f e0 ff, 7f 41 00 ff

不定長文字列のチャンクが定義済み長さでない場合:

5f 5f 41 00 ff ff, 7f 7f 61 00 ff ff

Subkind 4:

不定長項目の外部で単独で発生する「break」:

ff

定義済み長さの配列またはマップまたはタグで発生する「break」:

81 ff, 82 00 ff, a1 ff, a1 ff 00, a1 00 ff, a2 00 00 ff, 9f 81 ff, 9f 82 9f 81 9f 9f ff ff ff ff

不定長マップ内で、アイテム数が奇数になるような「break」（値の位置での「break」）:

bf 00 ff, bf 00 00 00 ff

Subkind 5:

追加情報31を持つメジャータイプ0、1、6:

1f, 3f, df

G.1. Errata Processing and Clerical Changes

G.1. エラッタ処理と事務的変更のための勘定処理

The two verified errata on RFC 7049, [Err3764] and [Err3770], concerned two encoding examples in the text that have been corrected (Section 3.4.3: "29" -> "49", Section 5.5: "0b000_11101" -> "0b000_11001"). Also, RFC 7049 contained an example using the numeric value 24 for a simple value [Err5917], which is not well-formed; this example has been removed. Errata report 5763 [Err5763] pointed to an error in the wording of the definition of tags; this was resolved during a rewrite of Section 3.4. Errata report 5434 [Err5434] pointed out that the Universal Binary JSON (UBJSON) example in Appendix E no longer complied with the version of UBJSON current at the time of the errata report submission. It turned out that the UBJSON specification had completely changed since 2013; this example therefore was removed. Other errata reports [Err4409] [Err4963] [Err4964] complained that the map key sorting rules for canonical encoding were onerous; these led to a reconsideration of the canonical encoding suggestions and replacement by the deterministic encoding suggestions (described below). An editorial suggestion in errata report 4294 [Err4294] was also implemented (improved symmetry by adding "Second value" to a comment to the last example in Section 3.2.2).

RFC 7049の2つの確認済みの勘違い、[Err3764]および[Err3770]は、テキスト内の2つのエンコード例に関連しており、修正されました（Section 3.4.3："29" -> "49"、Section 5.5："0b000_11101" -> "0b000_11001"）。また、RFC 7049には、単純な値に数値24を使用する例が含まれていましたが、これはウェルフォームではないため、この例は削除されました。[Err5917]。勘違いレポート5763 [Err5763]は、タグの定義の文言に誤りがあることを指摘していましたが、これはSection 3.4の書き直し中に解決されました。勘違いレポート5434 [Err5434]は、Universal Binary JSON（UBJSON）の例が、勘違いレポートの提出時点でのUBJSONのバージョンに準拠していないことを指摘していました。しかし、2013年以降、UBJSONの仕様は完全に変更されていたため、この例は削除されました。他の勘違いレポート[Err4409]、[Err4963]、[Err4964]は、正準エンコードのマップキーのソートルールが厳しいことを訴えていましたが、これにより正準エンコードの提案が再考され、決定論的エンコードの提案に置き換えられました（以下で説明）。勘違いレポート4294 [Err4294]の編集提案も実装されました（Section 3.2.2の最後の例に「Second value」をコメントに追加して対称性を改善）。

Other clerical changes include:

その他の事務的な変更には、次のものが含まれます。

• the use of new xml2rfc functionality [RFC7991];
• more explanation of the notation used;
• the update of references, e.g., from RFC 4627 to [RFC8259], from CNN-TERMS to [RFC7228], and from the 5.1 edition to the 11th edition of [ECMA262]; the addition of a reference to [IEEE754] and importation of required definitions; the addition of references to [C] and [Cplusplus20]; and the addition of a reference to [RFC8618] that further illustrates the discussion in Appendix E;
• in the discussion of diagnostic notation (Section 8), the "Extended Diagnostic Notation" (EDN) defined in [RFC8610] is now mentioned, the gap in representing NaN payloads is now highlighted, and an explanation of representing indefinite-length strings with no chunks has been added (Section 8.1);
• the addition of this appendix.

• 新しいxml2rfc機能の使用[RFC7991];
• 使用される表記法の説明の追加;
• 参照の更新。例えば、RFC 4627から[RFC8259]に、CNN-TERMSから[RFC7228]に、ECMA262の第5.1版から第11版に更新。必要な定義のインポートとして、[IEEE754]への参照の追加、[C]と[Cplusplus20]への参照の追加。また、Appendix Eでの議論をさらに説明する[RFC8618]への参照の追加;
• 診断表記の議論(Section 8)で、[RFC8610]で定義された「拡張診断表記」(EDN)が言及され、NaNペイロードの表現のギャップが強調され、長さが不定の文字列を表す方法についての説明が追加された(Section 8.1);
• この付録の追加。

G.2. Changes in IANA Considerations

G.2. IANAに関する考慮事項の変更点

The IANA considerations were generally updated (clerical changes, e.g., now pointing to the CBOR Working Group as the author of the specification). References to the respective IANA registries were added to the informative references.

IANAに関する考慮事項が一般的に更新されました(事務的な変更、例えば、仕様の筆者としてCBOR Working Groupを指定するようになりました)。情報参照に対して、それぞれのIANAレジストリへの参照が追加されました。

In the "Concise Binary Object Representation (CBOR) Tags" registry [IANA.cbor-tags], tags in the space from 256 to 32767 (lower half of "1+2") are no longer assigned by First Come First Served; this range is now Specification Required.

「Concise Binary Object Representation (CBOR) Tags」レジストリ[IANA.cbor-tags]では、256から32767のタグ(「1+2」の下位半分)は、もはやFirst Come First Servedによって割り当てられません。この範囲は、現在「Specification Required」となっています。

G.3. Changes in Suggestions and Other Informational Components

G.3. 提案やその他情報コンポーネントの変更点

While revising the document, beyond the addressing of the errata reports, the working group drew upon nearly seven years of experience with CBOR in a diverse set of applications. This led to a number of editorial changes, including adding tables for illustration, but also emphasizing some aspects and de-emphasizing others.

文書を改訂する際、勘定書の報告に対処することを超えて、作業グループは、多様なアプリケーションでの約7年間のCBORの経験を活用しました。これにより、図を示すための表の追加を含む編集上の変更がいくつか行われましたが、いくつかの側面を強調し、他の側面を弱めることも行われました。

A significant addition is Section 2, which discusses the CBOR data model and its small variations involved in the processing of CBOR. The introduction of terms for those variations (basic generic, extended generic, specific) enables more concise language in other places of the document and also helps to clarify expectations of implementations and of the extensibility features of the format.

重要な追加事項は、CBORデータモデルと、CBORの処理に関連するその小さな変化について説明するSection 2です。これらの変化に対する用語の導入(基本汎用、拡張汎用、特定)は、ドキュメントの他の場所でより簡潔な言語を可能にし、また、フォーマットの拡張性機能の実装と期待についても明確にするのに役立ちます。

As a format derived from the JSON ecosystem, RFC 7049 was influenced by the JSON number system that was in turn inherited from JavaScript at the time. JSON does not provide distinct integers and floating-point values (and the latter are decimal in the format). CBOR provides binary representations of numbers, which do differ between integers and floating-point values. Experience from implementation and use suggested that the separation between these two number domains should be more clearly drawn in the document; language that suggested an integer could seamlessly stand in for a floating-point value was removed. Also, a suggestion (based on I-JSON [RFC7493]) was added for handling these types when converting JSON to CBOR, and the use of a specific rounding mechanism has been recommended.

JSONエコシステムから派生したフォーマットであるRFC 7049は、当時JavaScriptから継承されたJSON数値システムに影響を受けました。JSONは、整数と浮動小数点値(後者は10進数形式)を区別しません。CBORは、整数と浮動小数点値の間で異なるバイナリ表現を提供します。実装と使用から得られた経験から、これら2つの数値領域の区別を文書でより明確にする必要があることが示唆されました。整数が浮動小数点値の代わりにシームレスに使用できることを示唆する言語は削除されました。また、JSONからCBORに変換する際のこれらの型の処理についての提案(I-JSON [RFC7493]に基づく)が追加され、特定の丸め機構の使用が推奨されました。

For a single value in the data model, CBOR often provides multiple encoding options. A new section (Section 4) introduces the term "preferred serialization" (Section 4.1) and defines it for various kinds of data items. On the basis of this terminology, the section then discusses how a CBOR-based protocol can define "deterministic encoding" (Section 4.2), which avoids terms "canonical" and "canonicalization" from RFC 7049. The suggestion of "Core Deterministic Encoding Requirements" (Section 4.2.1) enables generic support for such protocol-defined encoding requirements. This document further eases the implementation of deterministic encoding by simplifying the map ordering suggested in RFC 7049 to a simple lexicographic ordering of encoded keys. A description of the older suggestion is kept as an alternative, now termed "length-first map key ordering" (Section 4.2.3).

データモデルの単一の値に対して、CBORはしばしば複数のエンコーディングオプションを提供します。新しいセクション(Section 4)では、「優先シリアル化」(Section 4.1)という用語を導入し、さまざまな種類のデータ項目について定義します。この用語に基づいて、セクションでは、CBORベースのプロトコルが「決定論的エンコーディング」(Section 4.2)を定義する方法について説明します。これにより、RFC 7049の「正準」および「正準化」という用語を回避します。「コア決定論的エンコーディング要件」(Section 4.2.1)の提案により、このようなプロトコル定義のエンコーディング要件を汎用的にサポートできるようになります。このドキュメントは、エンコードされたキーの単純な辞書順序へのマップ順序の提案を、RFC 7049で提案されたマップ順序の簡素化により、決定論的エンコーディングの実装をさらに容易にします。以前の提案の説明は、現在は「長さ優先マップキー順序」(Section 4.2.3)と呼ばれ、代替案として保持されています。

The terminology for well-formed and valid data was sharpened and more stringently used, avoiding less well-defined alternative terms such as "syntax error", "decoding error", and "strict mode" outside of examples. Also, a third level of requirements that an application has on its input data beyond CBOR-level validity is now explicitly called out. Well-formed (processable at all), valid (checked by a validity-checking generic decoder), and expected input (as checked by the application) are treated as a hierarchy of layers of acceptability.

ウェルフォームなデータと有効なデータの用語が明確化され、より厳密に使用されるようになりました。"構文エラー"、"デコードエラー"、"ストリクトモード"などのより定義の曖昧な代替用語は、例外を除いて使用されなくなりました。また、CBORレベルの有効性以外に、アプリケーションが入力データに対して持つ要件の第3レベルが明示的に示されるようになりました。ウェルフォームな(全体的に処理可能な)、有効な(有効性チェックを行う汎用デコーダーによってチェックされる)、および期待される入力(アプリケーションによってチェックされる)は、受け入れ可能性のレイヤーの階層として扱われます。

The handling of non-well-formed simple values was clarified in text and pseudocode. Appendix F was added to discuss well-formedness errors and provide examples for them. The pseudocode was updated to be more portable, and some portability considerations were added.

非正常な単純な値の処理について、テキストと疑似コードで明確化されました。 Appendix F は、整形エラーについて説明し、それらの例を提供するために追加されました。疑似コードはよりポータブルに更新され、いくつかのポータビリティに関する考慮事項が追加されました。

The discussion of validity has been sharpened in two areas. Map validity (handling of duplicate keys) was clarified, and the domain of applicability of certain implementation choices explained. Also, while streamlining the terminology for tags, tag numbers, and tag content, discussion was added on tag validity, and the restrictions were clarified on tag content, in general and specifically for tag 1.

有効性に関する議論は、2つの領域でより明確になりました。マップの有効性(重複するキーの処理)が明確化され、特定の実装選択の適用範囲が説明されました。また、タグ、タグ番号、およびタグコンテンツの用語を簡素化する一方で、タグの有効性についての議論が追加され、一般的におよびとくにタグ1について、タグコンテンツの制限が明確化されました。

An implementation note (and note for future tag definitions) was added to Section 3.4 about defining tags with semantics that depend on serialization order.

実装上の注意事項(および将来のタグ定義の注意事項)が、シリアル化順序に依存する意味を持つタグの定義について、Section 3.4に追加されました。

Tag 35 is not defined by this document; the registration based on the definition in RFC 7049 remains in place.

タグ35は、このドキュメントによって定義されていません。RFC 7049の定義に基づく登録は引き続き有効です。

Terminology was introduced in Section 3 for "argument" and "head", simplifying further discussion.

「引数」と「ヘッド」に関する用語が、Section 3で導入され、さらなる議論を簡素化しました。

The security considerations (Section 10) were mostly rewritten and significantly expanded; in multiple other places, the document is now more explicit that a decoder cannot simply condone well-formedness errors.

セキュリティーに関する考慮事項(Section 10)は、大部分が書き直され、大幅に拡張されました。他の多くの場所でも、ドキュメントは、デコーダーが形式上正しいエラーを単に許容できないことをより明示的にしています。