Subject: [Json] I-JSON, sec. 4.4

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Aug 2014 10:05:00 +0200

Hi,

referring back to the thread

http://www.ietf.org/mail-archive/web/json/current/msg03129.html

I’d like to propose the following change to sec. 4.4 in draft-ietf-json-i-json:

OLD

   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].

NEW

   When it is required that an I-JSON protocol element contain arbitrary
   binary data, it is RECOMMENDED that this data be encoded using a base
   encoding with an alphabet restricted to a subset of printable US-ASCII
   characters [RFC4648], such as base64url.

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

---

From: Tim Bray <[email-masked]>
Date: Thu, 14 Aug 2014 01:08:22 -0700

Could you explain your thinking a bit more, especially what problems the
current wording would cause?  Thanks in advance.

On Thu, Aug 14, 2014 at 1:05 AM, Ladislav Lhotka <[email-masked]> wrote:

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Aug 2014 10:09:47 +0200

>   characters [RFC4648], such as base64url.

I believe that this would be a regression.

base64url SHOULD be used.
The exception to this SHOULD is where a specific usage of JSON has to take a legacy format into account.
That is the case for YANG-JSON, so it is perfectly OK to use base64 here.

(Note that YANG-JSON has much more severe problems with section 2.2.
I’m not aware of any reasonable way to fix this, so I wouldn’t even try to make YANG-JSON into a form of I-JSON.)

Grüße, Carsten

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Aug 2014 03:33:37 -0500

>    characters [RFC4648], such as base64url.

-1.

It'd be good to get everyone using the same binary encoding.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Aug 2014 10:39:46 +0200

On 14 Aug 2014, at 10:08, Tim Bray <[email-masked]> wrote:

> Could you explain your thinking a bit more, especially what problems the current wording would cause?  Thanks in advance.

I like the idea of I-JSON but I don’t know if a protocol can be labelled as I-JSON compliant if it doesn’t have a RECOMMENDED property.

As I understand it, the message of I-JSON to protocol implementors is: “Protocol XY uses I-JSON, so it is safe to assume that no JSON parser that deserves this name will break interoperability”. From this point of view, base64 seems to be as good as base64url.

Lada

> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Aug 2014 10:51:04 +0200

> That is the case for YANG-JSON, so it is perfectly OK to use base64 here.

In terms of RFC 2119, I doubt that “legacy” is acceptable as a good reason for ignoring a RECOMMENDED item.

> I’m not aware of any reasonable way to fix this, so I wouldn’t even try to make YANG-JSON into a form of I-JSON.)

This is true and we will try to address these problems on our side. For instance we reached an agreement to encode int64/uint64 values as strings.

Lada

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Aug 2014 10:57:06 +0200

> In terms of RFC 2119, I doubt that “legacy” is acceptable as a good reason for ignoring a RECOMMENDED item.

Well, the text as is does not give the set of reasons to not follow the recommendation.
Maybe it SHOULD...

> This is true and we will try to address these problems on our side. For instance we reached an agreement to encode int64/uint64 values as strings.

Ouch.  As I said, there is no reasonable way to handle this within I-JSON.
(Turning numbers that really represent counters into strings is not a particularly reasonable use of JSON.)

Grüße, Carsten

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Aug 2014 10:58:11 +0200

> It'd be good to get everyone using the same binary encoding.

I guess this has to do with the issue raised in another thread, namely the dilemma between I-JSON as a profile and I-JSON as best practices.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Aug 2014 11:06:58 +0200

> (Turning numbers that really represent counters into strings is not a particularly reasonable use of JSON.)

This is not a big problem because both the sender and receiver know the actual integer type (and possibly also the counter semantics) from the data model. I believe this is exactly what I-JSON draft says in the last paragraph of sec. 2.2.

Lada

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Aug 2014 13:46:25 +0200

On 14 Aug 2014, at 11:06, Ladislav Lhotka <[email-masked]> wrote:

> This is not a big problem

Yes, I wasn’t saying that this doesn’t work.
RFC 1925 item 3 sentence 1 applies*).

On the base64 point, one way of saying this without using the loaded term “legacy” is that the data item already is a string (which just happens to be base64 encoded) in YANG-XML, so this is just about carrying around that same string in JSON.
Clearly, based on its knowledge of the data model, it would be possible for a YANG-JSON implementation to convert this string to base64url, but there is limited point in doing so, because the other side will again be a YANG-JSON implementation anyway.

Grüße, Carsten

*) General rant: JSON was not meant to be limited to the capabilities of JavaScript.  I don’t know how those are relevant to the domain of network management and configuration.  But I’ll not argue this point.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Aug 2014 14:29:08 +0200

> RFC 1925 item 3 sentence 1 applies*).

;-)

> Clearly, based on its knowledge of the data model, it would be possible for a YANG-JSON implementation to convert this string to base64url, but there is limited point in doing so, because the other…

Yes, this is possible but it is an extra complication with no apparent benefit.

> *) General rant: JSON was not meant to be limited to the capabilities of JavaScript.  I don’t know how those are relevant to the domain of network management and configuration.  But I’ll not argue…

I don’t see any specific difficulties. We do need namespaces but luckily the YANG module name fits the role of the namespace identifier quite nicely.

Lada