Subject: [Json] binary data in I-JSON

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Jul 2014 13:40:34 -0400

Hi,

I’d like to ask about the reasoning behind the choice of base64url as the encoding format for binary data.

I am working on the I-D

http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00

which defines JSON encoding for data modelled with the YANG language [RFC6020]. Such data are primarily intended to be used in remote configuration protocols such as NETCONF or RESTCONF, so it seems to be a good use case for I-JSON and we would certainly like to comply with I-JSON rules.

However, YANG has the data type “binary” which requires base64 encoding. So I wonder - is there any reason for preferring base64url over base64? We most likely don’t need the encoded data to be URL-safe.

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

---

From: Tim Bray <[email-masked]>
Date: Mon, 21 Jul 2014 10:46:25 -0700

Good question. I think I agree with Ladislav​; what’s the benefit to
URL-safety in a JSON field value?

On Mon, Jul 21, 2014 at 10:40 AM, Ladislav Lhotka <[email-masked]> wrote:

> which defines JSON encoding for data modelled with the YANG language
> [RFC6020]. Such data are primarily intended to be used in remote
> configuration protocols such as NETCONF or RESTCONF, so it seems to be a
> good use case for I-JSON and we would certainly like to comply with I-JSON
> rules.
>
> However, YANG has the data type “binary” which requires base64 encoding.
> So I wonder - is there any reason for preferring base64url over base64? We
> most likely don’t need the encoded data to be URL-safe.
>
> Thanks, Lada
>
> --
> _______________________________________________
> 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: Mon, 21 Jul 2014 15:49:36 -0400

For this usage, base64 and base64url are exactly equivalent.
For other usages, base64url has advantages.

If you pick one, it has to be base64url.

Of course, then you get problems with the base64 legacy.
You can’t win this one.  Do it right or do it compatibly.

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Mon, 21 Jul 2014 13:04:14 -0700

I vote for "compatibly".

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Jul 2014 16:08:25 -0400

> For other usages, base64url has advantages.

Sec. 4.4 in I-JSON spec is clearly about JSON field values, and I can’t see any real advantage there.
 
> If you pick one, it has to be base64url.

I guess the problem we have with sec. 4.4 of I-JSON spec is that base64url is RECOMMENDED using an RFC 2119 keyword. IMO, it should just state the properties an encoding should possess for maximum interoperability, and perhaps give base64url as an example.

Lada

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 21 Jul 2014 16:08:29 -0400

> I vote for "compatibly".

OK, so strike section 4.4; that covers all the bases.
But if you want to make a RECOMMENDATION, base64url is still the right one.

Grüße, Carsten

---

From: Jacob Davies <[email-masked]>
Date: Mon, 21 Jul 2014 14:24:01 -0700

I don't know that there's enough evidence to say whether base64,
base64url, hex, or hacky-use-of-illegal-\u-escapes would be most
compatible with existing practice. I mean, there is one data point
here obviously.

Since there is admittedly no difference between base64 and base64url
for the purposes of JSON I can't see that it matters much which one is
recommended; even though I agree that base64url is to be preferred
where possible, base64 doesn't seem "wrong", but maybe I am missing
something.

I still think the binary encoding is a recommendation worth making,
whichever way.