/
143.txt
137 lines (107 loc) · 6.96 KB
/
143.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
[4] [DFN[[[I-JSON]]]] は、[[IETF]] が [DFN[[[RFC 7493]]]] で規定する [[JSON]]
の[[プロファイル]]です。
;; [5] 名称は [[Internet JSON]] の略 [SRC[>>3]] とされています。
[13] さして有用な規定も含まれておらず、いくつかの仕様書が参照している他は、世間からはほぼ完全に無視されています。
* 仕様書
[REFS[
- [3] [CITE@en[RFC 7493 - The I-JSON Message Format]]
([TIME[2015-03-24 03:09:18 +09:00]] 版)
<https://tools.ietf.org/html/rfc7493>
]REFS]
* 言語
[6] [DFN[[RUBYB[[[I-JSONメッセージ]]]@en[I-JSON message]]]] [SRC[>>3]] は、 [[RFC 7159]]
([[IETF]] 独自の [[JSON]] 仕様) に従う [[JSON text]] のうち、 [[RFC 7493]]
の制限に従うものをいいます。具体的には次のような制限があります [SRC[>>3]]。
[FIG(list)[
- [15] [[RFC 3629]] [[UTF-8]] で[[符号化]]しなければ[['''なりません''']]。
- [16] [[サロゲート]]や[[非文字]]を (直接であれ[[エスケープ]]としてであれ)
含んでは[['''なりません''']]。
- [17] [[IEEE 754倍精度浮動小数点数]]で表せない[[数]]を含める[['''べきではありません''']]。
- [18] [[IEEE 754倍精度浮動小数点数]]で表せない[[数]]は、[[文字列]]とする[['''べきです''']]。
- [19] [[オブジェクト]]の[[メンバー]]の[[名前]]に重複があっては[['''なりません''']]。
]FIG]
;; [27] つまり[[I-JSONメッセージ]]は[[バイト列]]です。 [[I-JSONメッセージ]]を
[[HTML]] などに直接埋め込むことはできません。
[20] [[オブジェクト]]の[[メンバー]]の順序に意味はないとも規定されています [SRC[>>3]]。
[7] [[RFC 7493]] はその他にプロトコル設計者に対する[['''推奨''']]も幾つか規定しています
[SRC[>>3]]。
[FIG(list)[
- [21] [[I-JSONメッセージ]]の制約に従わないものを受信したら、
その旨を送信者に通知できるようにする[['''べきです''']]。
- [22] 最上位に[[オブジェクト]]や[[配列]]''以外''を使う[['''べきではありません''']]。
- [23] 原則として、未知のものを誤りとする [DFN[[[Must-Understand]]]] 方針より、
無視する [DFN[[[Must-Ignore]]]] 方針の方が良いと考えられます。
Must-Ignore 法を使うなら、最上位を[[オブジェクト]]とし、
未知のメンバーは無視しなければ[['''ならない''']]と規定するのが良いです。
- [24] [[日時形式]]は [[RFC 3339の日時形式]]で[[大文字]]を使い、
[[時間帯]]も[[秒]]も明示する形式とする[['''べきです''']]。
- [25] [[時間形式]]は [[RFC 3339の時間形式]]で[[日時形式]]は >>24 とする[['''べきです''']]。
- [26] [[バイナリーデータ]]は、 [[RFC 4646]] [[base64url]] で符号化する[['''べきです''']]。
]FIG]
* 相互運用性
[14] [[I-JSON]] データは、すべて [[JSON]] データです。逆に任意の [[JSON]]
データは、 [[I-JSON]] データとは限りません。
[9] [[I-JSON]] により [[JSON]] の実装が簡単になるという人もいますが、
[[I-JSON]] 以外の [[JSON]] を完全に禁止できる特殊な環境で使う場合を除き、
[[I-JSON]] のみしか受け入れない実装は有用ではありません。
;; [10] 既存の [[JSON]] の実装が入力が [[I-JSON]] に従うかどうかも検査する動作モードも実装する場合、
実装の手間はかえって増えてしまいます。 [[I-JSON]] のみ受け入れる実装と、
一般の [[JSON]] として [[I-JSON]] を受け入れる実装が混在すると、
[[I-JSON]] ではないものが [[I-JSON]] として送信された時に、
実装によって受け入れられたり受け入れられなかったりしますから、
[[相互運用性]]の問題につながります。
従って、 [[I-JSON]] でない [[JSON]] を拒絶する[[構文解析器]]を作ってはいけません。
* 歴史
[1] [CITE@en[The I-JSON Message Format]]
( ([TIME[2013-07-03 21:37:36 +09:00]] 版))
<https://www.tbray.org/tmp/i-json.html>
[2] [CITE@en[draft-ietf-json-i-json-00 - The I-JSON Message Format]]
( ([TIME[2014-05-01 03:54:47 +09:00]] 版))
<http://tools.ietf.org/html/draft-ietf-json-i-json-00>
[8] [CITE@en[ongoing by Tim Bray · RFC 7493: The I-JSON Message Format]]
([TIME[2015-04-01 01:55:02 +09:00]] 版)
<https://www.tbray.org/ongoing/When/201x/2015/03/23/i-json>
[FIG(quote)[
[FIGCAPTION[
[11] [CITE[OData JSON Format Version 4.0 Plus Errata 02]]
([TIME[2014-10-31 01:00:00 +09:00]] 版)
<http://docs.oasis-open.org/odata/odata-json-format/v4.0/odata-json-format-v4.0.html>
]FIGCAPTION]
> The IEEE754Compatible=true format parameter indicates that the service MUST serialize Edm.Int64 and Edm.Decimal numbers (including the odata.count, if requested) as strings. This is in conformance with '''['''I-JSON''']'''.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[12] [CITE@en-US[JSR-000367 Java API for JSON Binding Early Draft Review]] ([TIME[2015-08-19 22:44:28 +09:00]] 版) <http://download.oracle.com/otndocs/jcp/json_b-1-edr-spec/index.html>
]FIGCAPTION]
>JSON Binding provides full support for I-JSON standard. Without any configuration, JSON Binding produces
JSON documents which are compliant with I-JSON with three exceptions.
- JSON Binding does not restrict the serialization of top-level JSON texts that are neither objects nor
arrays. The restriction should happen at application level.
- JSON Binding does not serialize binary data with base64url encoding.
- JSON Binding does not enforce additional restrictions on dates/times/duration.
>
These exceptions refer only to recommended areas of I-JSON.
>
To enforce strict compliance of serialized JSON documents, JSON Binding implementations MUST implement
configuration option ”jsonb.i-json.strict-ser-compliance”. [JSB-4.4-1]
>
The way to enable strict compliance of serialized JSON documents, is to call method
JsonbConfig::withStrictIJSONSerializationCompliance with parameter true.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[28] [CITE[JSON Mail Access Protocol Specification (JMAP)]]
([TIME[2016-03-11 14:55:42 +09:00]] 版)
<http://jmap.io/spec.html>
]FIGCAPTION]
> JSON is a text-based data interchange format as specified in RFC7159. The I-JSON format defined in RFC7493 is a strict subset of this, adding restrictions to avoid potentially confusing scenarios (for example, it mandates that an object MUST NOT have two properties with the same key). All data sent from the client to the server or from the server to the client MUST be valid I-JSON according to the RFC, is case-sensitive, and encoded in UTF-8.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[29] [CITE@en[RFC 7946 - The GeoJSON Format]]
([TIME[2016-08-19 22:23:34 +09:00]])
<https://tools.ietf.org/html/rfc7946>
]FIGCAPTION]
> GeoJSON texts should follow the constraints of Internet JSON (I-JSON)
> '''['''RFC7493''']''' for maximum interoperability.
]FIG]