Subject: [apps-discuss] JSON mailing list and BoF

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 18 Feb 2013 20:01:07 +0000

We're planning on doing a BoF in Orlando to discuss starting up a JSON
working group.  The BoF is currently planned for Monday afternoon at 1300
in Carribean 6.  A very preliminary version of a charter can be found here:

http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON

But obviously we'll need to build consensus on what it should actually
contain.  Please discuss on the [email-masked] mailing list:

https://www.ietf.org/mailman/listinfo/json

As a start, we know there are a couple of things we'd like to fix about
RFC 4627:

- move to standards track
- an ABNF indentation typo in section 2.2
- change SHOULD to MUST for the uniqueness of names in an object

A *very* important goal would be to minimize change, and to ensure strict
backward-compatibility.

There are likely adjunct JSON topics that would make sense to tackle once
we've got the experts together, but the goal would be to keep that list
short, focused, and general-purpose.

-- 
Joe Hildebrand

---

From: Francis Galiegue <[email-masked]>
Date: Mon, 18 Feb 2013 22:02:21 +0100

Hello,

> http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON

JSON Schema is missing from this page (it has been updated recently
and is now three specifications).

-- 
Francis Galiegue, [email-masked]
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 18 Feb 2013 22:35:08 +0100

On Feb 18, 2013, at 21:01, "Joe Hildebrand (jhildebr)" <[email-masked]> wrote:

> adjunct JSON topics

One such topic might be roundtripping to/from some simple binary format for JSON-structured values.

draft-bormann-apparea-bpack-00.txt

Grüße, Carsten

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 18 Feb 2013 23:47:13 +0000

>draft-bormann-apparea-bpack-00.txt

As an individual, I'm +1 on that.  I love msgpack, and don't mind the
addition of UTF8 as a separate type.  Was frsyuki involved in the draft,
or at least know that it happened?

-- 
Joe Hildebrand

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 18 Feb 2013 23:52:24 +0000

>and is now three specifications).

As an individual.

I'd say that a way to unambiguously specify further standards that use
JSON seems reasonable.  Whether it's json-schema or json-content-rules, or
something else seems like a fertile ground for discussion.

I like Cyrus's argument that all we need is the ABNF of the JSON world,
and that any attempt to get more complicated than that will likely lead us
down the XSD rathole.

-- 
Joe Hildebrand

---

From: Francis Galiegue <[email-masked]>
Date: Tue, 19 Feb 2013 01:13:31 +0100

> and that any attempt to get more complicated than that will likely lead us

Well, I'd like to hear the reasoning behind this argument ;)

I have really struggled to make this specification useful, and
witnessing the users of my library alone, it looks like the pure
validation part of JSON Schema already has quite a few users...

I also make the best efforts not to repeat XSD's mistakes, and right
now JSON Schema is young enough that it cannot have made such mistakes
(I _think_). But in order not to repeat such mistakes, advice from
external people is of course needed.

Which is why reviews are always welcome!

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 19 Feb 2013 01:07:36 +0000

>external people is of course needed.

Oh! Sorry, I didn't mean to imply that I didn't like json-schema, just
that there are several different approaches that have been proposed, and
it makes sense to have a conversation about what our requirements are and
if we think we're meeting them with one of those proposals.

Charter-wise, setting the requirement to be "as simple as possible, but no
simpler" is probably something we can all agree on; agreeing on what
constitutes "simple" is likely to be more complex. :)

> Which is why reviews are always welcome!

I certainly need to review the latest versions before having an opinion.

-- 
Joe Hildebrand

---

From: Francis Galiegue <[email-masked]>
Date: Tue, 19 Feb 2013 02:15:14 +0100

On Tue, Feb 19, 2013 at 2:07 AM, Joe Hildebrand (jhildebr)
<[email-masked]> wrote:
[...]
> if we think we're meeting them with one of those proposals.

I'd certainly like to have a digest of this discussion! I have my own
needs, and even my own implementation, so I cannot be partial here --
just be a witness on my use case.

> I certainly need to review the latest versions before having an opinion.

Looking forward to this!

Have fun,

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 Feb 2013 17:39:11 +0100

> or at least know that it happened?

I tried to involve him.
Frsyuki doesn't like what I did with the binary strings vs. UTF-8, though.

I didn't quite catch whether he is just focusing on maintaining compatibility with what's out there (today's msgpack) or whether he really doesn't see why that is a good idea.
(For me, maintaining 100 % compatibility won't work anyway, because in the end that won't be the only change we'll want to make.  
If we look a bit outside the space that msgpack is being applied to today, we might want to support, say, 16-bit floating point.)

Grüße, Carsten

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 19 Feb 2013 17:31:42 +0000

On 2/19/13 9:39 AM, "Carsten Bormann" <[email-masked]> wrote:

>If we look a bit outside the space that msgpack is being applied to
>today, we might want to support, say, 16-bit floating point.)

and potentially Date.

If we were going to standardize this, the IETF would need full change
control.

-- 
Joe Hildebrand

---

From: Francis Galiegue <[email-masked]>
Date: Tue, 19 Feb 2013 18:37:22 +0100

On Tue, Feb 19, 2013 at 6:31 PM, Joe Hildebrand (jhildebr)
<[email-masked]> wrote:
[...]
> If we were going to standardize this, the IETF would need full change

Another unrelated point: I see no reason why a transmitted JSON
document (called a "JSON text") has to be a "container" and not any
JSON value.

What was the motivation behind this in the RFC in the first place?

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Feb 2013 20:33:09 +0000

Another topic that might worth discussing is canonicalization.  It's come up in JOSE a couple of times[1], and it would be helpful to standardize an approach.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

[1] The most recent discussing starts at < http://www.ietf.org/mail-archive/web/jose/current/msg01575.html >, instigated by < http://www.ietf.org/mail-archive/web/jose/current/msg01553.html >

On Feb 18, 2013, at 1:01 PM, Joe Hildebrand (jhildebr) <[email-masked]> wrote:

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

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 19 Feb 2013 20:47:09 +0000

On 2/19/13 1:33 PM, "Matt Miller (mamille2)" <[email-masked]> wrote:

>Another topic that might worth discussing is canonicalization.  It's come
>up in JOSE a couple of times[1], and it would be helpful to standardize
>an approach.

(individual)

Do you think draft-staykov-hu-json-canonical-form is a valid starting
point?  My biggest beef with it is that the number syntax uses capital E
and JavaScript's toExponential() generates a lowercase e.

-- 
Joe Hildebrand

---

From: Mike Jones <[email-masked]>
Date: Tue, 19 Feb 2013 20:47:02 +0000

I'm strongly against canonicalization.  The XML canonicalization experience was horrible and resulted in more interop bugs than any other aspect of XML DSIG, XML ENC, etc.  Let's not repeat the mistakes of our elders. ;-)

I also haven't seen a clear use case that canonicalization solves that can't be more easily solved another way.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Miller (mamille2)
Sent: Tuesday, February 19, 2013 12:33 PM
To: Joe Hildebrand (jhildebr)
Cc: [email-masked]; [email-masked]
Subject: Re: [apps-discuss] JSON mailing list and BoF

- m&m

On Feb 18, 2013, at 1:01 PM, Joe Hildebrand (jhildebr) <[email-masked]> wrote:

> working group.  The BoF is currently planned for Monday afternoon at 
> 1300 in Carribean 6.  A very preliminary version of a charter can be found here:
> 
> As a start, we know there are a couple of things we'd like to fix 
> about RFC 4627:
> 
> A *very* important goal would be to minimize change, and to ensure 
> strict backward-compatibility.
> 
> There are likely adjunct JSON topics that would make sense to tackle 
> once we've got the experts together, but the goal would be to keep 
> that list short, focused, and general-purpose.
> 
> --
> Joe Hildebrand
> 
> 
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Feb 2013 14:59:14 -0600

> I also haven't seen a clear use case that canonicalization solves that can't be more easily solved another way.

But what were the mistakes?  Is canonicalization in and of itself a
mistake?  Or were the mistakes about how to do it?

I personally think that standards should avoid having to canonicalize
JSON (and XML) wherever possible.  The simplest way to do this is
never re-encode in the process of validating signatures, for example.
However, I'm not sure that we can always avoid canonicalization, or
that even if we can it has no value; I could be convinced.

Nico
--

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 19 Feb 2013 21:27:38 +0000

On 2/19/13 1:47 PM, "Mike Jones" <[email-masked]> wrote:

>I'm strongly against canonicalization.  The XML canonicalization
>experience was horrible and resulted in more interop bugs than any other
>aspect of XML DSIG, XML ENC, etc.  Let's not repeat the mistakes of our
>elders. ;-)
>

I somewhat agree, but have you at least read
draft-staykov-hu-json-canonical-form?  It's pretty straightforward, and
nowhere near as scary as xmlenc.

-- 
Joe Hildebrand

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 19 Feb 2013 21:28:59 +0000

>can't be more easily solved another way.

I needed it for a light use case recently; I wanted to use a serialized
object as the key into a hash.

-- 
Joe Hildebrand

---

From: Tim Bray <[email-masked]>
Date: Tue, 19 Feb 2013 13:34:50 -0800

re draft-staykov-hu-json-canonical-form:
Looks sensible. One gripe:  Why can’t you sign NaN and INF?  They do in
fact  occur in the field, and it’s not as though a noncanonical
representation is possible.

-T (who still hasn’t decided if this is actually a good idea)

On Tue, Feb 19, 2013 at 1:27 PM, Joe Hildebrand (jhildebr) <
[email-masked]> wrote:

> json mailing list
> [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Feb 2013 15:41:27 -0600

> nowhere near as scary as xmlenc.

Indeed.

Lexicographic sorting... makes me wonder about Unicode normalization.
Before your heads explode, what is the ECMAScript rule regarding
normalization of object keys?  Are the two normalization forms of
'foó' allowed as distinct keys in an object?

Nico
--

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Feb 2013 21:42:16 +0000

> and JavaScript's toExponential() generates a lowercase e.

Assuming I think canonicalization is something that ought to be done, I think it is a decent start that needs to be expanded.  The first thing that came to my mind is string normalization, and how that relates to escape sequences.

However, while not as violently opposed as some, I am hesitant.  XML canonicalization has bitten me hard in the past, so I am carrying a bias into this conversation.  Maybe a starting point can be "don't rely on canonicalization unless you really really really have to," and we can come up with a set of those "really really really have to" scenarios.

- m&m

---

From: Tim Bray <[email-masked]>
Date: Tue, 19 Feb 2013 13:53:07 -0800

I would argue that normalization should be out of scope.  I.e. the two
forms of “foó” are different strings, that’s all.
“Doctor! It hurts when I do this!”
“So, don’t do that!”

-T

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 19 Feb 2013 21:55:37 +0000

On 2/19/13 2:34 PM, "Tim Bray" <[email-masked]> wrote:

>Looks sensible. One gripe:  Why can¹t you sign NaN and INF?  They do in
>fact  occur in the field, and it¹s not as though a noncanonical

I can figure out how to generate a -INF, but how do I get a -NaN?

-- 
Joe Hildebrand

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Feb 2013 13:59:41 -0800

The JSON list seems active already. Do we need to have this thread on both lists?

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Feb 2013 15:59:56 -0600

On Tue, Feb 19, 2013 at 3:53 PM, Tim Bray <[email-masked]> wrote:
> I would argue that normalization should be out of scope.  I.e. the two forms
> of “foó” are different strings, that’s all.

That's fair.  In that case this I-D looks simple enough that I can't
really oppose it.  I do think we should give advice as to how to avoid
the need for canonicalization (c14n?) in the first place.

---

From: Francis Galiegue <[email-masked]>
Date: Tue, 19 Feb 2013 23:00:59 +0100

> “Doctor! It hurts when I do this!”

(as a not very well educated individual on this matter...)

If _that_ is what normalization is about, then I strongly condemn it
being even a subject at all.

The current RFC does a pretty good job at defining what a JSON String
can be, fabricating some sort of injective function so that one JSON
value is equal to another is sick.

OK, I say that, but on the other hand, JSON Schema mandates that JSON
values "1.0" and "1" be considered equal for numeric validation. This
could also be viewed as a form of normalization...

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Feb 2013 16:01:09 -0600

> I can figure out how to generate a -INF, but how do I get a -NaN?

In JS?  1/0 -> INF, 0/0 -> NaN.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Feb 2013 15:01:55 -0700

> The JSON list seems active already. Do we need to have this thread on both lists?

Please not. Let's just chat on the json@ list. See you there! ;-)

/psa

---

From: Francis Galiegue <[email-masked]>
Date: Tue, 19 Feb 2013 23:05:08 +0100

On Tue, Feb 19, 2013 at 10:55 PM, Joe Hildebrand (jhildebr)
<[email-masked]> wrote:
[...]
> I can figure out how to generate a -INF, but how do I get a -NaN?

The current JSON specification doesn't mandate any limit to the
precision and/or scale of numeric instances, and I was particularly
attentive to this aspect of JSON when writing the JSON Schema specs,
since my first use case for using JSON Schema was the ability to use
keywords such as "minimum", "maximum", "multipleOf" to validate
arbitrary numerical JSON instances. The JSON Schema validation specs
(OK, these are my words) says this:

http://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-3.2

I _do believe that JSON itself should not define NaN. JSON can express
arbitrary data and should not care about the capabilities of language
A or B in a transacation. Only recommendations and/or warnings can be
given at that point.

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Feb 2013 16:07:26 -0600

> value is equal to another is sick.

Oh, well, the RFC (4627) says nothing about normalization.  And if you
think the notion is sick wait till you hear the details!  But as you
read what you find when you search for "Unicode normalization" you
should keep one thing in mind: this sickness isn't Unicode's fault --
it's our (humans', that is) fault.

Indeed.

Nico
--

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 19 Feb 2013 22:18:14 +0000

>The JSON list seems active already. Do we need to have this thread on

Nope.  After this message, I'll start pruning and re-directing, since I
think we've got a quorum on the json list.

-- 
Joe Hildebrand

---

From: Francis Galiegue <[email-masked]>
Date: Tue, 19 Feb 2013 23:20:10 +0100

On Tue, Feb 19, 2013 at 11:07 PM, Nico Williams <[email-masked]> wrote:
[...]
>> could also be viewed as a form of normalization...

Note however that JSON Schema is not the only I-D in that case. JSON
Patch says this too
(http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10#section-4.6).

---

From: S Moonesamy <[email-masked]>
Date: Tue, 19 Feb 2013 14:23:34 -0800

Hello,

There is a mailing list at
https://www.ietf.org/mailman/listinfo/json to discuss about the JSON 
BoF.  I suggest moving the discussion about JSON to the JSON mailing 
list.  Please do not copy the messages to [email-masked].

Thanks,
S. Moonesamy

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Feb 2013 14:11:07 +0100

>> or at least know that it happened?

Well, I did engage the msgpack community some more.

You can find a transcript of some 275 messages about separating byte and UTF-8 strings at:

	https://github.com/msgpack/msgpack/issues/121

Summary:
Some members of the msgpack community are very enraged that this change hasn't happened earlier.
Of course, some have gone off and done their own incompatible forks.
Others are very enraged that any change is happening at all, and that new people are intruding on their turf.
(And some probably feel guilty that it took a ****storm from outside to finally make this change.)

frsyuki is now working on a proposal that solves the problem:

	https://gist.github.com/frsyuki/5022569

The proposal is technically complete (and has already been implemented).
It already is pretty good at the details, too, but this whole thing is being done in a process that is closer to Japanese consensus processes than to IETF culture.

My -01 will be fully aligned with whatever the state of frsyuki's proposal will be on Monday's I-D deadline (find today's snapshot at http://www.tzi.de/~cabo/draft-bormann-apparea-bpack-01pre2.txt).
(frsyuki's proposal may change some more, but those will in all likelihood be minor details.)
I think his overall thinking is fine, but it is much more dominated by a requirement for backwards compatibility than an IETF process would be.

So, the larger question on whether the msgpack community is ready to take part (or just endure) in an IETF-style consensus process (including handing over change control) still looms.

That doesn't diminish from the requirement for a msgpack-like format, and I think we should use Hallway Time in Orlando to discuss potential ways forward.

I any case, I definitely don't want to disturb the constructive discussion about chartering a very narrow JSON fixup WG with this work.
(I do want to find a home for it, soon, though: I want to build other specs on top of it.)

Grüße, Carsten