[要約] RFC 7493は、I-JSONメッセージフォーマットに関する仕様であり、JSONデータの効率的な表現と相互運用性を向上させることを目的としています。
Internet Engineering Task Force (IETF) T. Bray, Ed.
Request for Comments: 7493 Textuality Services
Category: Standards Track March 2015
ISSN: 2070-1721
The I-JSON Message Format
I-JSONメッセージ形式
Abstract
概要
I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.
I-JSON（「インターネットJSON」の略）は、相互運用性を最大化し、ソフトウェアが予測可能な結果で正常に処理できるという信頼を高めるように設計されたJSONの制限付きプロファイルです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7493.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7493で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. I-JSON Messages . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Encoding and Characters . . . . . . . . . . . . . . . . . 3
2.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Object Constraints . . . . . . . . . . . . . . . . . . . 3
3. Software Behavior . . . . . . . . . . . . . . . . . . . . . . 4
4. Recommendations for Protocol Design . . . . . . . . . . . . . 4
4.1. Top-Level Constructs . . . . . . . . . . . . . . . . . . 4
4.2. Must-Ignore Policy . . . . . . . . . . . . . . . . . . . 4
4.3. Time and Date Handling . . . . . . . . . . . . . . . . . 5
4.4. Binary Data . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
RFC 7159 describes the JSON data interchange format, which is widely used in Internet protocols. For historical reasons, that specification allows the use of language idioms and text encoding patterns that are likely to lead to interoperability problems and software breakage, particularly when a program receiving JSON data uses automated software to map it into native programming-language structures or database records. RFC 7159 describes practices that may be used to avoid these interoperability problems.
RFC 7159は、インターネットプロトコルで広く使用されているJSONデータ交換フォーマットについて説明しています。歴史的な理由により、特にJSONデータを受信するプログラムが自動化ソフトウェアを使用してネイティブプログラミング言語構造またはデータベースレコードにマッピングする場合、その仕様により、相互運用性の問題やソフトウェアの破損につながる可能性のある言語イディオムやテキストエンコーディングパターンを使用できます。 。 RFC 7159は、これらの相互運用性の問題を回避するために使用できる方法について説明しています。
This document specifies I-JSON, short for "Internet JSON". The unit of definition is the "I-JSON message". I-JSON messages are also "JSON texts" as defined in RFC 7159 but with certain extra constraints that enforce the good interoperability practices described in that specification.
このドキュメントでは、「インターネットJSON」の略であるI-JSONを指定しています。定義の単位は「I-JSONメッセージ」です。 I-JSONメッセージは、RFC 7159で定義されている「JSONテキスト」でもありますが、その仕様で説明されている優れた相互運用性の実践を実施する特定の追加の制約があります。
The terms "object", "member", "array", "number", "name", and "string" in this document are to be interpreted as described in RFC 7159 [RFC7159].
このドキュメントの「オブジェクト」、「メンバー」、「配列」、「番号」、「名前」、および「文字列」という用語は、RFC 7159 [RFC7159]で説明されているように解釈されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
An I-JSON message is a JSON text, as defined by RFC 7159.
I-JSONメッセージは、RFC 7159で定義されているJSONテキストです。
I-JSON messages MUST be encoded using UTF-8 [RFC3629].
I-JSONメッセージは、UTF-8 [RFC3629]を使用してエンコードする必要があります。
Object member names, and string values in arrays and object members, MUST NOT include code points that identify Surrogates or Noncharacters as defined by [UNICODE].
オブジェクトメンバー名、および配列とオブジェクトメンバーの文字列値には、[UNICODE]で定義されているサロゲートまたは非文字を識別するコードポイントを含めることはできません。
This applies both to characters encoded directly in UTF-8 and to those which are escaped; thus, "\uDEAD" is invalid because it is an unpaired surrogate, while "\uD800\uDEAD" would be legal.
これは、UTF-8で直接エンコードされた文字とエスケープされる文字の両方に適用されます。したがって、「\ uDEAD」は対にならないサロゲートであるため無効ですが、「\ uD800 \ uDEAD」は有効です。
Software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used. Implementations that generate I-JSON messages cannot assume that receiving implementations can process numeric values with greater magnitude or precision than provided by those numbers. I-JSON messages SHOULD NOT include numbers that express greater magnitude or precision than an IEEE 754 double precision number provides, for example, 1E400 or 3.141592653589793238462643383279.
IEEE 754-2008のbinary64（倍精度）番号を実装するソフトウェア[IEEE754]が一般に入手可能であり、広く使用されています。 I-JSONメッセージを生成する実装は、受信側の実装が、それらの数値によって提供されるよりも大きい大きさまたは精度で数値を処理できるとは想定できません。 I-JSONメッセージには、IEEE 754倍精度数が提供するよりも大きい大きさまたは精度を表す数を含めることはできません（SHOULD NOT）。たとえば、1E400または3.141592653589793238462643383279。
An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value.
I-JSON送信者は、絶対値が9007199254740991より大きい整数（つまり、[-（2 ** 53）+1、（2 ** 53）-1]の範囲外）を受信者が次のように扱うことを期待できません。正確な値。
For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers.
より大きな絶対値または精度で数値を正確に交換する必要があるアプリケーションの場合、JSON文字列値にエンコードすることをお勧めします。これには、受信プログラムが値の意図された意味を理解することが必要です。 JavaScript番号のスコープが限られているため、最新のハードウェアで処理できる場合でも、64ビット整数がその例です。
Objects in I-JSON messages MUST NOT have members with duplicate names. In this context, "duplicate" means that the names, after processing any escaped characters, are identical sequences of Unicode characters.
I-JSONメッセージ内のオブジェクトには、重複した名前を持つメンバーがあってはなりません。このコンテキストでは、「重複」とは、エスケープ文字を処理した後の名前が、Unicode文字の同一のシーケンスであることを意味します。
The order of object members in an I-JSON message does not change the meaning of an I-JSON message. A receiving implementation MAY treat two I-JSON messages as equivalent if they differ only in the order of the object members.
I-JSONメッセージ内のオブジェクトメンバーの順序は、I-JSONメッセージの意味を変更しません。受信側の実装は、オブジェクトメンバーの順序のみが異なる場合、2つのI-JSONメッセージを同等として扱うことができます（MAY）。
A major advantage of using I-JSON is that receivers can avoid ambiguous semantics in the JSON messages they receive. This allows receivers to reject or otherwise disregard messages that do not conform to the requirements in this document for I-JSON messages. Protocols that use I-JSON messages can be written so that receiving implementations are required to reject (or, as in the case of security protocols, not trust) messages that do not satisfy the constraints of I-JSON.
I-JSONを使用する主な利点は、受信者が受信するJSONメッセージのあいまいなセマンティクスを回避できることです。これにより、受信者は、このドキュメントのI-JSONメッセージの要件に準拠していないメッセージを拒否または無視することができます。 I-JSONメッセージを使用するプロトコルは、受信実装がI-JSONの制約を満たさないメッセージを拒否する（またはセキュリティプロトコルの場合のように信頼しない）必要があるように記述できます。
Designers of protocols that use I-JSON messages SHOULD provide a way, in this case, for the receiver of the erroneous data to signal the problem to the sender.
I-JSONメッセージを使用するプロトコルの設計者は、この場合、誤ったデータの受信者が送信者に問題を通知する方法を提供する必要があります（SHOULD）。
I-JSON is designed for use in Internet protocols. The following recommendations apply to the use of I-JSON in such protocols.
I-JSONは、インターネットプロトコルで使用するために設計されています。以下の推奨事項は、そのようなプロトコルでのI-JSONの使用に適用されます。
An I-JSON message can be any JSON value. However, there are software implementations, coded to the older specification [RFC4627], which only accept JSON objects or JSON arrays at the top level of JSON texts. For maximum interoperability with such implementations, protocol designers SHOULD NOT use top-level JSON texts that are neither objects nor arrays.
I-JSONメッセージは、任意のJSON値にすることができます。ただし、古い仕様[RFC4627]にコード化されたソフトウェア実装があり、JSONテキストの最上位レベルでJSONオブジェクトまたはJSON配列のみを受け入れます。そのような実装との最大の相互運用性のために、プロトコル設計者は、オブジェクトでも配列でもないトップレベルのJSONテキストを使用してはなりません。
It is frequently the case that changes to protocols are required after they have been put in production. Protocols that allow the introduction of new protocol elements in a way that does not disrupt the operation of existing software have proven advantageous in practice.
プロダクションに移行した後、プロトコルの変更が必要になることがよくあります。既存のソフトウェアの動作を妨げない方法で新しいプロトコル要素の導入を可能にするプロトコルは、実際に有利であることが証明されています。
This can be referred to as a "Must-Ignore" policy, meaning that when an implementation encounters a protocol element that it does not recognize, it should treat the rest of the protocol transaction as if the new element simply did not appear, and in particular, the implementation MUST NOT treat this as an error condition. The converse "Must-Understand" policy does not tolerate the introduction of new protocol elements, and while this has proven necessary in certain protocol designs, in general it has been found to be overly restrictive and brittle.
これは「Must-Ignore」ポリシーと呼ぶことができます。つまり、実装が認識しないプロトコル要素に遭遇した場合、残りのプロトコルトランザクションを新しい要素が単に表示されなかったかのように処理する必要があります。特に、実装はこれをエラー状態として扱ってはいけません（MUST NOT）。逆の「理解しなければならない」ポリシーは、新しいプロトコル要素の導入を許容しません。これは、特定のプロトコル設計で必要であることが証明されていますが、一般に、過度に制限され、もろいことがわかっています。
A good way to support the use of Must-Ignore in I-JSON protocol designs is to require that top-level protocol elements must be JSON objects, and to specify that members whose names are unrecognized MUST be ignored.
I-JSONプロトコル設計でMust-Ignoreの使用をサポートする良い方法は、トップレベルのプロトコル要素がJSONオブジェクトでなければならないことを要求し、名前が認識されないメンバーを無視する必要があることを指定することです。
Protocols often contain data items that are designed to contain timestamps or time durations. It is RECOMMENDED that all such data items be expressed as string values in ISO 8601 format, as specified in [RFC3339], with the additional restrictions that uppercase rather than lowercase letters be used, that the timezone be included not defaulted, and that optional trailing seconds be included even when their value is "00". It is also RECOMMENDED that all data items containing time durations conform to the "duration" production in Appendix A of RFC 3339, with the same additional restrictions.
多くの場合、プロトコルには、タイムスタンプまたは期間を含むように設計されたデータ項目が含まれています。 [RFC3339]で指定されているように、このようなデータ項目はすべてISO 8601形式の文字列値として表現することをお勧めします。小文字を使用するのではなく大文字を使用すること、タイムゾーンをデフォルトに含めないこと、オプションの末尾値が「00」の場合でも秒が含まれます。また、期間を含むすべてのデータ項目は、RFC 3339の付録Aの「期間」プロダクションに準拠し、同じ追加の制限があることも推奨されます。
When it is required that an I-JSON protocol element contain arbitrary binary data, it is RECOMMENDED that this data be encoded in a string value in base64url; see Section 5 of [RFC4648].
I-JSONプロトコル要素に任意のバイナリデータを含める必要がある場合は、このデータをbase64urlの文字列値にエンコードすることをお勧めします。 [RFC4648]のセクション5をご覧ください。
All the security considerations that apply to JSON (see RFC 7159) apply to I-JSON. There are no additional security considerations specific to I-JSON.
JSONに適用されるすべてのセキュリティの考慮事項（RFC 7159を参照）はI-JSONに適用されます。 I-JSONに固有のセキュリティに関する追加の考慮事項はありません。
Since I-JSON forbids the use of certain JSON idioms that can lead to unpredictable behavior in receiving software, it may prove a more secure basis for Internet protocols and may be a good choice for protocol designers with special security needs.
I-JSONは、受信ソフトウェアで予期しない動作を引き起こす可能性のある特定のJSONイディオムの使用を禁止しているため、インターネットプロトコルのより安全な基盤を証明し、特別なセキュリティが必要なプロトコル設計者に適した選択肢となる場合があります。
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2008, 2008, <http://grouper.ieee.org/groups/754/>.
[IEEE754] IEEE、「IEEE Standard for Floating-Point Arithmetic」、IEEE 754-2008、2008、<http://grouper.ieee.org/groups/754/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339]クラインG.およびC.ニューマン、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、2002年7月、<http://www.rfc-editor.org/info/rfc3339>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月、<http://www.rfc-editor.org/info/rfc3629>。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006, <http://www.rfc-editor.org/info/rfc4627>.
[RFC4627] Crockford、D。、「JavaScript Object Notation（JSON）のapplication / json Media Type」、RFC 4627、2006年7月、<http://www.rfc-editor.org/info/rfc4627>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159] Bray、T。、編、「JavaScript Object Notation（JSON）Data Interchange Format」、RFC 7159、2014年3月、<http://www.rfc-editor.org/info/rfc7159>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
Acknowledgements
謝辞
I-JSON is entirely dependent on the design of JSON, largely due to Douglas Crockford. The specifics were strongly influenced by the contributors to the design of RFC 7159 in the IETF JSON Working Group.
I-JSONは、主にDouglas Crockfordが原因で、JSONの設計に完全に依存しています。詳細は、IETF JSONワーキンググループのRFC 7159の設計への貢献者から強く影響を受けました。
Author's Address
著者のアドレス
Tim Bray (editor) Textuality Services
Tim Bray（編集者）Textuality Services
EMail: tbray@textuality.com
URI: https://www.tbray.org/