Subject: [Json] Proposed change to the title of the spec

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Jun 2013 08:41:09 -0700

<no hat>

Current title:
   The application/json Media Type for JavaScript Object Notation (JSON)
Proposed title:
   JavaScript Object Notation (JSON)

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Jun 2013 10:50:42 -0500

>    JavaScript Object Notation (JSON)

+1

---

From: Tim Bray <[email-masked]>
Date: Wed, 5 Jun 2013 09:53:09 -0700

I’m +0 on this but think it would be just wonderful to take JavaScript out
of the name.  New title: “The JSON Format for Encoding Data”. Who said JSON
had to stand for anything?  -T

On Wed, Jun 5, 2013 at 8:50 AM, Nico Williams <[email-masked]> wrote:

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

---

From: Vinny A <[email-masked]>
Date: Wed, 5 Jun 2013 11:58:49 -0500

When I think of "encoding", I think of UTF-8 or similar. How about "transferring" or "containing" data?

On Jun 5, 2013, at 11:53 AM, Tim Bray <[email-masked]> wrote:

> I’m +0 on this but think it would be just wonderful to take JavaScript out of the name.  New title: “The JSON Format for Encoding Data”. Who said JSON had to stand for anything?  -T
> 
>

---

From: Stefan Drees <[email-masked]>
Date: Wed, 05 Jun 2013 19:04:29 +0200

On 05.06.13 18:53, Tim Bray wrote:
> On Wed, Jun 5, 2013 at 8:50 AM, Nico Williams ... wrote:
>> On Wed, Jun 5, 2013 at 10:41 AM, Paul Hoffman ... wrote:
>>> <no hat>
>>>
>>> Current title:
>>>   The application/json Media Type for JavaScript Object Notation(JSON)
>>> Proposed title:
> I’m +0 on this but think it would be just wonderful to take JavaScript
> out of the name.  New title: “The JSON Format for Encoding Data”. Who
> said JSON had to stand for anything?  -T

Yes, please set the title to

	"The JSON Format for Encoding Data"

if changing it, so that the focus shift of the last ten years of usage 
in the wild is better represented.

I hope the term "Encoding" used within is common language enough to not 
trigger extended bikeshedding ;-)

Stefan.

---

From: Peter Brooks <[email-masked]>
Date: Wed, 5 Jun 2013 18:55:04 +0200

+1

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Jun 2013 10:24:38 -0700

> I’m +0 on this but think it would be just wonderful to take JavaScript out of the name.  New title: “The JSON Format for Encoding Data”. Who said JSON had to stand for anything?  -T

This works for me, better than my original proposal.

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 5 Jun 2013 19:42:59 +0200

On Jun 5, 2013, at 18:53, Tim Bray <[email-masked]> wrote:

> I’m +0 on this but think it would be just wonderful to take JavaScript out of the name.  

+1

> New title: “The JSON Format for Encoding Data”. Who said JSON had to stand for anything?  -T

Let's not forget to write the RFC editor note explaining why they shouldn't put back an expansion of the abbreviation...

Grüße, Carsten

PS.; s/"Encoding"/"Representing"/, but that is too far in bikeshed territory.

---

From: Douglas Crockford <[email-masked]>
Date: Wed, 05 Jun 2013 10:54:03 -0700

> said JSON had to stand for anything? -T
I like this. There is no need to put JavaScript in the title. I think 
the title should be
The JSON Data Interchange Format.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 5 Jun 2013 17:59:20 +0000

On Jun 5, 2013, at 11:54 AM, Douglas Crockford <[email-masked]> wrote:

> I like this. There is no need to put JavaScript in the title. I think the title should be

/me doffs hat

Either works for me, and seems much better than the current title.

- m&m

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

---

From: Tim Bray <[email-masked]>
Date: Wed, 5 Jun 2013 11:11:57 -0700

+1

On Wed, Jun 5, 2013 at 10:54 AM, Douglas Crockford <[email-masked]>wrote:

>> out of the name. New title: “The JSON Format for Encoding Data”. Who said
>> JSON had to stand for anything? -T
>>

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 5 Jun 2013 20:42:08 +0200

On Wednesday, June 05, 2013 6:53 PM, Tim Bray wrote:
> I’m +0 on this but think it would be just wonderful to take
> JavaScript out of the name.  New title: “The JSON Format for
> Encoding Data”. Who said JSON had to stand for anything?  -T

+1

--
Markus Lanthaler
@markuslanthaler

---

From: Vinny A <[email-masked]>
Date: Wed, 5 Jun 2013 14:43:07 -0500

+1

-----------------
Vinny
www.jsontest.com

---

From: Matthew Morley <[email-masked]>
Date: Wed, 5 Jun 2013 15:57:21 -0400

+1

-- 
Matthew P. C. Morley

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 10 Jun 2013 20:22:57 +0000

Hello all,

This is your last chance for proposing changes to the document title. If anyone has additional proposals, please send them to the list as soon as possible.  The chairs will be calling for consensus presently.

Here are the proposals we have so far:

#1)  Leave document as-is

#2)  The JSON Data Interchange Format

#3) The JSON Format for Encoding Data

Thanks,

Matt Miller & Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Mon, 10 Jun 2013 13:34:55 -0700

I'm OK on #2 or #3
On Jun 10, 2013 1:23 PM, "Matt Miller (mamille2)" <[email-masked]>
wrote:

> Hello all,
>
> This is your last chance for proposing changes to the document title. If
> anyone has additional proposals, please send them to the list as soon as
> possible.  The chairs will be calling for consensus presently.
>

---

From: Stefan Drees <[email-masked]>
Date: Mon, 10 Jun 2013 22:39:21 +0200

On 2013-06-10 22:22 CEST, Matt Miller wrote:
> Hello all,
>
> This is your last chance for proposing changes to the document
> title.
> If anyone has additional proposals, please send them to the list as soon
> as possible. The chairs will be calling for consensus presently.
>
> ...

I thus hereby propose as new title:

NEW:
"""

         The JSON Text Format

"""

Rationale:
The discussions on this list and daily experience make it clear to me, 
that both "encoding/decoding" and "data interchange" functionality of 
JSON are somehow working (even enabling a microscopic XML dialect ;-) 
but seem to promise more robustness and reproducability than can be 
spelled out with MUSTardy and without at least breaking someones pet 
toy, but one thing stands out and will remain:

	The JSON text

was and ist the subject of this RFC, and the main ingredient should be 
clearly stated on the label, shouldn't it?

All the best,
Stefan Drees.

---

From: R S <[email-masked]>
Date: Mon, 10 Jun 2013 13:40:45 -0700

#2

- Rob

---

From: Rick Waldron <[email-masked]>
Date: Mon, 10 Jun 2013 16:40:29 -0400

> #2)  The JSON Data Interchange Format

#2 is the title used in ECMA-262, v5.1

Rick

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 Jun 2013 13:47:57 -0700

> I'm OK on #2 or #3

Wait, stop. That's *not* what Matt asked. This is not a consensus call, it is a request for proposals.

Please respond if you cannot live with any of the proposal Matt listed *and* you have one you think you could live with.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Jun 2013 16:03:17 -0500

> I thus hereby propose as new title:

I would object.  It is conceivable to have a binary encoding (like the
recently proposed CBOR) that could (or a subset of which could)
represent the same data as JSON.  And it might even be possible to
update the UTF detection logic to support the such an encoding.  The
new thing could be equivalent to JSON and a reasonable transformation
of it, but it wouldn't be text.

I like Matt's #2 and #3.  I have no other proposals to add.  I think
Matt's #1, #2, and #3 about cover all the choices we should consider,
but maybe my imagination fails me.

Nico
--

---

From: Tatu Saloranta <[email-masked]>
Date: Mon, 10 Jun 2013 14:25:09 -0700

> of it, but it wouldn't be text.

Not just could but there already exist multiple, like Smile (
http://wiki.fasterxml.com/SmileFormatSpec) and ubjson (http://ubjson.org/).
Smile supports auto-detection just as you suggested, to allow seamless
detection.
And indeed, the idea of logical JSON model and one or more matching
physical serializations is simple, powerful and useful thing (similar to
binary infosets for xml).

Then again, _this_ specification does define details of textual
serialization of logical model, so existence of binary serialization does
not in itself invalidate use of "text" in title.

-+ Tatu +-