Internet Engineering Task Force (IETF) T. Bray, Ed.
Request for Comments: 7493 Textuality Services
Category: Standards Track March 2015
ISSN: 2070-1721
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（InternetJSON的缩写）是JSON的一个受限配置文件，旨在最大限度地提高互操作性，并增加软件能够以可预测的结果成功处理它的信心。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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数据交换格式，该格式在Internet协议中广泛使用。出于历史原因，该规范允许使用可能导致互操作性问题和软件破坏的语言习惯用法和文本编码模式，特别是当接收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.
本文档指定I-JSON，即“Internet 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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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].
必须使用UTF-8[RFC3629]对I-JSON消息进行编码。
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二进制64（双精度）数字[IEEE754]的软件普遍可用并广泛使用。生成I-JSON消息的实现不能假设接收实现可以处理比这些数字更大幅度或精度的数值。I-JSON消息不应包含表示比IEEE 754双精度数字更大幅度或精度的数字，例如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字符串值对其进行编码。这要求接收程序理解该值的预期语义。一个例子是64位整数，尽管现代硬件可以处理它们，因为JavaScript数字的范围有限。
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消息的含义。如果两个I-JSON消息仅在对象成员的顺序上不同，则接收实现可能会将它们视为等效消息。
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消息的协议的设计者应该为错误数据的接收者提供一种向发送者发出问题信号的方式。
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.
虽然这在某些协议设计中被证明是必要的，但一般来说，它被认为是过度限制和脆弱的。
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习惯用法，这些习惯用法可能会导致接收软件时出现不可预测的行为，因此它可能是Internet协议更安全的基础，对于具有特殊安全需求的协议设计人员来说，它可能是一个不错的选择。
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2008, 2008, <http://grouper.ieee.org/groups/754/>.
[IEEE754]IEEE，“IEEE浮点运算标准”，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]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC33392002年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对象表示法（json）的应用程序/json媒体类型”，RFC4627，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.，“Base16、Base32和Base64数据编码”，RFC4648，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.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，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联盟，“UNICODE标准”<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完全依赖于JSON的设计，这主要归功于Douglas Crockford。这些细节受到IETF JSON工作组中RFC 7159设计贡献者的强烈影响。
Author's Address
作者地址
Tim Bray (editor) Textuality Services
蒂姆·布雷（编辑）文本服务
EMail: tbray@textuality.com
URI: https://www.tbray.org/
EMail: tbray@textuality.com
URI: https://www.tbray.org/