Subject: [netmod] I-JSON

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Aug 2014 15:30:19 +0200

Hi,

I-JSON spec (draft-ietf-json-i-json-03) defines a restricted profile of
JSON that guarantees maximum interoperability for protocols that use
JSON in their messages, no matter what JSON encoders/decoders are used
in protocol implementations. This is exactly what e.g. RESTCONF needs,
so it would be useful to make JSON defined in the yang-json document
I-JSON compliant.

A far as I can tell, these are the problematic parts:

Encoding and Characters
=======================

- I-JSON requires UTF-8 encoding. Yang-json should do the same, which
  may need recoding on the sender side.

- I-JSON forbids Unicode surrogates or noncharacters. YANG "string" and
  other types inherit XML character set which excludes surrogates but
  not all noncharacters (for example, #xFDDO is allowed). The only
  robust solution I can see is to ban noncharacters in YANG 1.1 -
  yang-json cannot do it unilaterally.

Numbers
=======

- I-JSON messages SHOULD NOT include numbers which express greater
  magnitude or precision than an IEEE 754 double precision number. This
  affects YANG int64, uint64 and decimal64 types. Proposal: encode
  values of these types as strings.

Binary Data
===========

- In I-JSON, it is RECOMMENDED that this data be encoded in a string
  value in base64url. YANG's binary type requires base64. I raised this
  issue twice in the JSON WG mailing list
  (http://www.ietf.org/mail-archive/web/json/current/msg03129.html,
  http://www.ietf.org/mail-archive/web/json/current/msg03192.html). Nobody
  offered any arguments why base64url should be better than base64 for
  encoding field values, but I also found no support for changing the
  current text. So the only option seems to be not to follow this I-JSON
  recommendation (and provide reasoning). 

Please comment.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2014 13:31:16 +0200 (CEST)

> A far as I can tell, these are the problematic parts:

Ok.

>   yang-json cannot do it unilaterally.

Hmm.  Tricky.

>   values of these types as strings.

Ok.  This is also RECOMMENDED in the i-json draft.

> Binary Data

Ok; this is fine, since it is only RECOMMENDED in the i-json draft.

/martin