[要約] RFC 7464は、JSONテキストシーケンスの形式と使用方法を定義しています。このRFCの目的は、複数のJSONオブジェクトを効率的に転送するための標準化を提供することです。
Internet Engineering Task Force (IETF) N. Williams
Request for Comments: 7464 Cryptonector
Category: Standards Track February 2015
ISSN: 2070-1721
JavaScript Object Notation (JSON) Text Sequences
JavaScript Object Notation（JSON）テキストシーケンス
Abstract
概要
This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).
このドキュメントでは、JavaScript Object Notation（JSON）テキストシーケンス形式および関連するメディアタイプ「application / json-seq」について説明します。 JSONテキストシーケンスは、すべてUTF-8でエンコードされた任意の数のJSONテキストで構成され、それぞれにASCIIレコードセパレーター（0x1E）が前に付けられ、それぞれがASCIIラインフィード文字（0x0A）で終わります。
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/rfc7464.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7464で入手できます。
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 and Motivation .....................................2
1.1. Conventions Used in This Document ..........................2
2. JSON Text Sequence Format .......................................3
2.1. JSON Text Sequence Parsing .................................3
2.2. JSON Text Sequence Encoding ................................4
2.3. Incomplete/Invalid JSON Texts Need Not Be Fatal ............4
2.4. Top-Level Values: numbers, true, false, and null ...........5
3. Security Considerations .........................................6
4. IANA Considerations .............................................6
5. Normative References ............................................7
Acknowledgements ...................................................8
Author's Address ...................................................8
The JavaScript Object Notation (JSON) [RFC7159] is a very handy serialization format. However, when serializing a large sequence of values as an array, or a possibly indeterminate-length or never-ending sequence of values, JSON becomes difficult to work with.
JavaScript Object Notation（JSON）[RFC7159]は非常に便利なシリアル化フォーマットです。ただし、大きな値のシーケンスを配列としてシリアル化する場合、または長さが不定または無限の値のシーケンスをシリアル化すると、JSONの操作が困難になります。
Consider a sequence of one million values, each possibly one kilobyte when encoded -- roughly one gigabyte. It is often desirable to process such a dataset in an incremental manner without having to first read all of it before beginning to produce results. Traditionally, the way to do this with JSON is to use a "streaming" parser, but these are not widely available, widely used, or easy to use.
100万個の値のシーケンスを考えます。エンコードされた場合、それぞれ1キロバイトになる可能性があります。多くの場合、結果の生成を開始する前にすべてのデータセットを読み取る必要なく、そのようなデータセットを段階的に処理することが望まれます。従来、JSONを使用してこれを行う方法は、「ストリーミング」パーサーを使用することですが、これらは広く利用できず、広く使用されておらず、使いやすいものでもありません。
This document describes the concept and format of "JSON text sequences", which are specifically not JSON texts themselves but are composed of (possible) JSON texts. JSON text sequences can be parsed (and produced) incrementally without having to have a streaming parser (nor streaming encoder).
このドキュメントでは、「JSONテキストシーケンス」の概念と形式について説明します。これは、具体的にはJSONテキスト自体ではなく、（可能性のある）JSONテキストで構成されています。 JSONテキストシーケンスは、ストリーミングパーサー（またはストリーミングエンコーダー）がなくても、段階的に解析（および生成）できます。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Two different sets of ABNF rules are provided for the definition of JSON text sequences: one for parsers and one for encoders. Having two different sets of rules permits recovery by parsers from sequences where some of the elements are truncated for whatever reason. The syntax for parsers is specified in terms of octet strings that are then interpreted as JSON texts, if possible. The syntax for encoders, on the other hand, assumes that sequence elements are not truncated.
JSONテキストシーケンスの定義には、2つの異なるABNFルールセットが用意されています。1つはパーサー用、もう1つはエンコーダ用です。 2つの異なるルールセットがあると、何らかの理由で要素の一部が切り捨てられているシーケンスからのパーサーによる回復が可能になります。パーサーの構文はオクテット文字列で指定され、可能であればJSONテキストとして解釈されます。一方、エンコーダの構文では、シーケンス要素が切り捨てられていないことを前提としています。
JSON text sequences MUST use UTF-8 encoding; other encodings of JSON (i.e., UTF-16 and UTF-32) MUST NOT be used.
JSONテキストシーケンスはUTF-8エンコーディングを使用する必要があります。 JSONの他のエンコーディング（つまり、UTF-16およびUTF-32）は使用してはなりません（MUST NOT）。
The ABNF [RFC5234] for the JSON text sequence parser is as given in Figure 1.
JSONテキストシーケンスパーサーのABNF [RFC5234]は、図1に示すとおりです。
input-JSON-sequence = *(1*RS possible-JSON)
RS = %x1E; "record separator" (RS), see RFC 20
; Also known as: Unicode Character INFORMATION SEPARATOR
; TWO (U+001E)
possible-JSON = 1*(not-RS); attempt to parse as UTF-8-encoded
; JSON text (see RFC 7159)
not-RS = %x00-1d / %x1f-ff; any octets other than RS
Figure 1: JSON Text Sequence ABNF
図1：JSONテキストシーケンスABNF
In prose: a series of octet strings, each containing any octet other than a record separator (RS) (0x1E) [RFC20]. All octet strings are preceded by an RS byte. Each octet string in the sequence is to be parsed as a JSON text in the UTF-8 encoding [RFC3629].
散文：一連のオクテット文字列で、それぞれにレコード区切り（RS）（0x1E）[RFC20]以外のオクテットが含まれています。すべてのオクテット文字列の前にはRSバイトが付きます。シーケンスの各オクテット文字列は、UTF-8エンコーディング[RFC3629]でJSONテキストとして解析されます。
If parsing of such an octet string as a UTF-8-encoded JSON text fails, the parser SHOULD nonetheless continue parsing the remainder of the sequence. The parser can report such failures to applications, which might then choose to terminate parsing of a sequence. Multiple consecutive RS octets do not denote empty sequence elements between them and can be ignored.
そのようなオクテット文字列をUTF-8でエンコードされたJSONテキストとして解析できない場合でも、パーサーはシーケンスの残りの部分の解析を続行する必要があります（SHOULD）。パーサーはこのような障害をアプリケーションに報告でき、アプリケーションはシーケンスの解析を終了することを選択できます。複数の連続したRSオクテットは、それらの間の空のシーケンス要素を示すものではなく、無視できます。
This document does not define a mechanism for reliably identifying text sequence by position (for example, when sending individual elements of an array as unique text sequences). For applications where truncation is a possibility, this means that intended sequence elements can be truncated and can even be missing entirely; therefore, a reference to an nth element would be unreliable.
このドキュメントでは、位置によってテキストシーケンスを確実に識別するメカニズムを定義していません（たとえば、配列の個々の要素を一意のテキストシーケンスとして送信する場合）。切り捨てが可能であるアプリケーションの場合、これは、意図されたシーケンス要素が切り捨てられたり、完全に欠落したりする可能性があることを意味します。したがって、n番目の要素への参照は信頼できません。
There is no end of sequence indicator.
シーケンス終了インジケータはありません。
The ABNF for the JSON text sequence encoder is given in Figure 2.
JSONテキストシーケンスエンコーダーのABNFを図2に示します。
JSON-sequence = *(RS JSON-text LF)
RS = %x1E; see RFC 20
; Also known as: Unicode Character INFORMATION SEPARATOR
; TWO (U+001E)
LF = %x0A; "line feed" (LF), see RFC 20
JSON-text = <given by RFC 7159, using UTF-8 encoding>
Figure 2: JSON Text Sequence ABNF
図2：JSONテキストシーケンスABNF
In prose: any number of JSON texts, each encoded in UTF-8 [RFC3629], each preceded by one ASCII RS character, and each followed by a line feed (LF). Since RS is an ASCII control character, it may only appear in JSON strings in escaped form (see [RFC7159]), and since RS may not appear in JSON texts in any other form, RS unambiguously delimits the start of any element in the sequence. RS is sufficient to unambiguously delimit all top-level JSON value types other than numbers. Following each JSON text in the sequence with an LF allows detection of truncated JSON texts consisting of a number at the top-level; see Section 2.4.
散文では、任意の数のJSONテキストがあり、それぞれがUTF-8 [RFC3629]でエンコードされ、それぞれが1つのASCII RS文字で始まり、その後に改行（LF）が続きます。 RSはASCII制御文字であるため、エスケープされた形式（[RFC7159]を参照）のJSON文字列でのみ表示され、RSは他の形式のJSONテキストでは表示されないため、シーケンス内の要素の開始を明確に区切ります。 。 RSは、数値以外のすべてのトップレベルのJSON値タイプを明確に区切るのに十分です。シーケンスの各JSONテキストの後にLFを付けると、トップレベルの数値で構成される切り捨てられたJSONテキストを検出できます。セクション2.4を参照してください。
JSON text sequence encoders are expected to ensure that the sequence elements are properly formed. When the JSON text sequence encoder does the JSON text encoding, the sequence elements will naturally be properly formed. When the JSON text sequence encoder accepts already-encoded JSON texts, the JSON text sequence encoder ought to parse them before adding them to a sequence.
JSONテキストシーケンスエンコーダーは、シーケンス要素が適切に形成されることを保証することが期待されています。 JSONテキストシーケンスエンコーダーがJSONテキストエンコードを行うと、シーケンス要素は自然に適切に形成されます。 JSONテキストシーケンスエンコーダーが既にエンコードされたJSONテキストを受け入れる場合、JSONテキストシーケンスエンコーダーは、それらをシーケンスに追加する前に解析する必要があります。
Note that on some systems it"s possible to input RS by typing "ctrl-^"; on some system or applications, the correct sequence may be "ctrl-v ctrl-^". This is helpful when constructing a sequence manually with a text editor.
一部のシステムでは、「ctrl- ^」と入力してRSを入力できる場合があることに注意してください。一部のシステムまたはアプリケーションでは、正しいシーケンスは「ctrl-v ctrl- ^」の場合があります。これは、テキストエディタ。
Per Section 2.1, JSON text sequence parsers should not abort when an octet string contains a malformed JSON text. Instead, the JSON text sequence parser should skip to the next RS. Such a situation may arise in contexts where, for example, data that is appended to log files to log files is truncated by the filesystem (e.g., due to a crash or administrative process termination).
セクション2.1に従って、オクテット文字列に不正な形式のJSONテキストが含まれている場合、JSONテキストシーケンスパーサーは中止されません。代わりに、JSONテキストシーケンスパーサーは次のRSにスキップする必要があります。このような状況は、たとえば、ログファイルにログファイルに追加されたデータがファイルシステムによって切り捨てられる（たとえば、クラッシュまたは管理プロセスの終了が原因で）状況で発生する可能性があります。
Incremental JSON text parsers may be used, though of course failure to parse a given text may result after first producing some incremental parse results.
インクリメンタルJSONテキストパーサーを使用することもできますが、最初にいくつかのインクリメンタル解析結果を生成した後で、特定のテキストの解析に失敗することがあります。
Sequence parsers should have an option to warn about truncated JSON texts.
シーケンスパーサーには、切り捨てられたJSONテキストについて警告するオプションが必要です。
While objects, arrays, and strings are self-delimited in JSON texts, numbers and the values 'true', 'false', and 'null' are not. Only whitespace can delimit the latter four kinds of values.
オブジェクト、配列、文字列はJSONテキストでは自己区切りですが、数値と値「true」、「false」、および「null」はそうではありません。空白のみが、後者の4種類の値を区切ることができます。
JSON text sequences use 0x0A as a "canary" octet to detect truncation.
JSONテキストシーケンスは、切り捨てを検出するための「カナリア」オクテットとして0x0Aを使用します。
Parsers MUST check that any JSON texts that are a top-level number, or that might be 'true', 'false', or 'null', include JSON whitespace (at least one byte matching the "ws" ABNF rule from [RFC7159]) after that value; otherwise, the JSON-text may have been truncated. Note that the LF following each JSON text matches the "ws" ABNF rule.
パーサーは、最上位の数値、または「true」、「false」、または「null」である可能性のあるJSONテキストにJSONの空白が含まれていることを確認する必要があります（少なくとも1バイトが[RFC7159の「ws」ABNFルールに一致する]）その値の後;そうでない場合、JSONテキストは切り捨てられている可能性があります。各JSONテキストに続くLFは「ws」ABNFルールに一致することに注意してください。
Parsers MUST drop JSON-text sequence elements consisting of non-self-delimited top-level values that may have been truncated (that are not delimited by whitespace). Parsers can report such texts as warnings (including, optionally, the parsed text and/or the original octet string).
パーサーは、（空白で区切られていない）切り捨てられている可能性がある非自己区切りのトップレベル値で構成されるJSONテキストシーケンス要素をドロップする必要があります。パーサーはそのようなテキストを警告として報告できます（オプションで、解析されたテキストや元のオクテット文字列を含みます）。
For example, '<RS>123<RS>' might have been intended to carry the top-level number 1234, but it got truncated. Similarly, '<RS>true<RS>' might have been intended to carry the invalid text 'trueish'. '<RS>truefalse<RS>' is not two top-level values, 'true', and 'false'; it is simply not a valid JSON text.
たとえば、「<RS> 123 <RS>」はトップレベルの数値1234を伝えることを意図していた可能性がありますが、切り捨てられました。同様に、「<RS> true <RS>」は、無効なテキスト「trueish」を運ぶことを意図していた可能性があります。 '<RS> truefalse <RS>'は、 'true'と 'false'の2つの最上位値ではありません。単に有効なJSONテキストではありません。
Implementations may produce a value when parsing '<RS>"foo"<RS>' because their JSON text parser might be able to consume bytes incrementally; since the JSON text in this case is a self-delimiting top-level value, the parser can produce the result without consuming an additional byte. Such implementations ought to skip to the next RS byte, possibly reporting any intervening non-whitespace bytes.
実装は、 '<RS> "foo" <RS>'を解析するときに値を生成する場合があります。これは、JSONテキストパーサーがバイトを徐々に消費する可能性があるためです。この場合のJSONテキストは自己区切りのトップレベル値であるため、パーサーは追加のバイトを消費することなく結果を生成できます。このような実装では、次のRSバイトにスキップし、間にある非空白バイトを報告する必要があります。
Detection of truncation of non-self-delimited sequence elements (numbers, true, false, and null) is only possible when the sequence encoder produces or receives complete JSON texts. Implementations where the sequence encoder is not also in charge of encoding the individual JSON texts should ensure that those JSON texts are complete.
非自己区切りシーケンス要素（数値、true、false、null）の切り捨ての検出は、シーケンスエンコーダーが完全なJSONテキストを生成または受信した場合にのみ可能です。シーケンスエンコーダーが個々のJSONテキストのエンコードも担当しない実装では、それらのJSONテキストが完全であることを確認する必要があります。
All the security considerations of JSON [RFC7159] apply. This format provides no cryptographic integrity protection of any kind.
JSON [RFC7159]のセキュリティに関する考慮事項がすべて適用されます。この形式では、いかなる種類の暗号化整合性保護も提供されません。
As usual, parsers must operate on input that is assumed to be untrusted. This means that parsers must fail gracefully in the face of malicious inputs.
いつものように、パーサーは信頼できないと想定される入力に対して動作する必要があります。これは、パーサーは悪意のある入力に直面しても適切に失敗する必要があることを意味します。
Note that incremental JSON text parsers can produce partial results and later indicate failure to parse the remainder of a text. A sequence parser that uses an incremental JSON text parser might treat a sequence like '<RS>"foo"<LF>456<LF><RS>' as a sequence of one element ("foo"), while a sequence parser that uses a non-incremental JSON text parser might treat the same sequence as being empty. This effect, and texts that fail to parse and are ignored, can be used to smuggle data past sequence parsers that don't warn about JSON text failures.
増分JSONテキストパーサーは部分的な結果を生成し、後でテキストの残りを解析できないことを示す可能性があることに注意してください。インクリメンタルJSONテキストパーサーを使用するシーケンスパーサーは、 '<RS> "foo" <LF> 456 <LF> <RS>'のようなシーケンスを1つの要素のシーケンス（ "foo"）として扱います。非インクリメンタルJSONテキストパーサーを使用すると、同じシーケンスが空であると見なされる場合があります。この効果と、解析に失敗して無視されるテキストは、JSONテキストの失敗について警告しないシーケンスパーサーを通過してデータを密輸するために使用できます。
Repeated parsing and re-encoding of a JSON text sequence can result in the addition (or stripping) of trailing LF bytes from (to) individual sequence element JSON texts. This can break signature validation. JSON has no canonical form for JSON texts, therefore neither does the JSON text sequence format.
JSONテキストシーケンスの解析と再エンコードを繰り返すと、個々のシーケンス要素JSONテキストから（へ）末尾のLFバイトが追加（または削除）される可能性があります。これにより、署名の検証が壊れる可能性があります。 JSONには、JSONテキストの標準形式がないため、JSONテキストシーケンス形式もありません。
The MIME media type for JSON text sequences is application/json-seq.
JSONテキストシーケンスのMIMEメディアタイプはapplication / json-seqです。
Type name: application
タイプ名：アプリケーション
Subtype name: json-seq
サブタイプ名：json-seq
Required parameters: N/A
必須パラメーター：なし
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: binary
エンコーディングに関する考慮事項：バイナリ
Security considerations: See RFC 7464, Section 3.
セキュリティに関する考慮事項：RFC 7464のセクション3をご覧ください。
Interoperability considerations: Described herein.
相互運用性に関する考慮事項：ここで説明します。
Published specification: RFC 7464.
公開された仕様：RFC 7464。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
<https://stedolan.github.io/jq>
<https://github.com/mapbox/cligj>
<https://github.com/hildjj/json-text-sequence>
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：なし
Additional information:
追加情報：
o Deprecated alias names for this type: N/A
o このタイプの非推奨のエイリアス名：N / A
o Magic number(s): N/A
o マジックナンバー：N / A
o File extension(s): N/A
o ファイル拡張子：N / A
o Macintosh file type code(s): N/A
o Macintoshファイルタイプコード：N / A
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
json@ietf.org
ｊそん＠いえｔｆ。おｒｇ
Intended usage: COMMON
使用目的：COMMON
Author: Nicolas Williams (nico@cryptonector.com)
作成者：Nicolas Williams（nico@cryptonector.com）
Change controller: IETF
コントローラの変更：IETF
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[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>。
[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>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、2014年3月、<http://www.rfc-editor.org/info/rfc7159>。
Acknowledgements
謝辞
Phillip Hallam-Baker proposed the use of JSON text sequences for logfiles and pointed out the need for resynchronization. Stephen Dolan created <https://github.com/stedolan/jq>, which uses something like JSON text sequences (with LF as the separator between texts on output, and requiring only such whitespace as needed to disambiguate on input). Carsten Bormann suggested the use of ASCII RS, and Joe Hildebrand suggested the use of LF in addition to RS for disambiguating top-level number values. Paul Hoffman shepherded the document. Many others contributed reviews and comments on the JSON Working Group mailing list.
Phillip Hallam-Bakerは、ログファイルにJSONテキストシーケンスを使用することを提案し、再同期の必要性を指摘しました。 Stephen Dolanが作成した<https://github.com/stedolan/jq>は、JSONテキストシーケンスのようなものを使用します（出力上のテキスト間の区切り文字としてLFを使用し、入力を明確にするために必要な空白のみを必要とします）。 Carsten BormannはASCII RSの使用を提案し、Joe HildebrandはRSに加えて最上位の数値を明確にするためにLFを使用することを提案しました。ポール・ホフマンは文書をシェパードしました。他の多くの人がJSONワーキンググループメーリングリストのレビューとコメントを投稿しました。
Author's Address
著者のアドレス
Nicolas Williams Cryptonector, LLC
ニコラスウィリアムズクリプトネクター、LLC
EMail: nico@cryptonector.com