[4] I-JSON は、IETF が RFC 7493 で規定する JSON のプロファイルです。
[13] さして有用な規定も含まれておらず、いくつかの仕様書が参照している他は、世間からはほぼ完全に無視されています。
[6] I-JSONメッセージ >>3 は、 RFC 7159
(IETF 独自の JSON 仕様) に従う JSON text のうち、 RFC 7493
の制限に従うものをいいます。具体的には次のような制限があります >>3。
[20] オブジェクトのメンバーの順序に意味はないとも規定されています >>3。
[7] RFC 7493 はその他にプロトコル設計者に対する推奨も幾つか規定しています >>3。
[14] I-JSON データは、すべて JSON データです。逆に任意の JSON データは、 I-JSON データとは限りません。
[9] I-JSON により JSON の実装が簡単になるという人もいますが、 I-JSON 以外の JSON を完全に禁止できる特殊な環境で使う場合を除き、 I-JSON のみしか受け入れない実装は有用ではありません。
[1] The I-JSON Message Format ( ( 版)) <https://www.tbray.org/tmp/i-json.html>
[2] draft-ietf-json-i-json-00 - The I-JSON Message Format ( ( 版)) <http://tools.ietf.org/html/draft-ietf-json-i-json-00>
[8] ongoing by Tim Bray · RFC 7493: The I-JSON Message Format ( 版) <https://www.tbray.org/ongoing/When/201x/2015/03/23/i-json>
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].
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.
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.
GeoJSON texts should follow the constraints of Internet JSON (I-JSON)
[RFC7493] for maximum interoperability.
[30] [Json] I-JSON () <https://www.ietf.org/mail-archive/web/json/current/msg03982.html>
CDNI Metadata objects MUST be encoded as I-JSON objects [RFC7493]
containing a dictionary of (key,value) pairs where the keys are the
property names and the values are the associated property values.
CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also
follow the recommendations of I-JSON (Internet JSON) [RFC7493].
The body of RI requests and responses is a JSON object [RFC7159] that
contains a dictionary of key:value pairs that MUST conform to
[RFC7493].
[34] jsonb-spec/spec.pdf at master · javaee/jsonb-spec () <https://github.com/javaee/jsonb-spec/blob/master/spec/spec.pdf>
There are though important standards out there (like JOSE) that without mentioning it effectively are based on/compliant with I-JSON beacuse they target browsers and Node.js as well.
[36] うわー最強理論じゃんこれwwww
[38] [Json] Bug in RFC7493 (I-JSON)? () <https://www.ietf.org/mail-archive/web/json/current/msg04303.html>
[39] cyberphone/I-JSON-Number-System: Extended Numeric Data Types compliant with I-JSON () <https://github.com/cyberphone/I-JSON-Number-System>