Subject: [Json] What are we trying to do?

From: Tim Bray <[email-masked]>
Date: Tue, 2 Jul 2013 22:01:38 -0700

I’m having trouble dealing with the recent proposals from our co-chairs
because I don’t think I understand what they’re trying to achieve.  Just to
refresh, our charter says

“The work is essentially a reclassification in place, with minimal changes.
The working group will   eview errata and update the document as needed to
incorporate those, and will correct significant  errors and
inconsistencies, but will keep changes to a minimum.

It is acknowledged that there are differences between RFC 4627 and the
ECMAScript specification  in the rules for parsing JSON. Any changes that
break compatibility with existing implementations of  either RFC 4627 or
the ECMAScript specification will need to have very strong justification
and broad support. ”

The changes proposed by the chairs are pretty big. Maybe the problem is
that any change which would actually CORRECT the two biggest
errors/inconsistencies in 4267 would necessarily be pretty significant.
When your charter is self-contradictory, you can either re-charter or
decide to ignore one of the two contradictory directives.

I was getting really comfortable with the minimal proposal, which noted
that while the spec more or less means what it says (strings should be
Unicode, objects should have unique keys), there are other standards with
different interpretations.  Also, there is variation among observed
behavior in software, when the JSON RFC’s high-level directives are
contravened.

What the industry really needs is a document normatively describing
JSON-as-best-practiced, with an RFC number.  It would say that senders MUST
NOT do X and Y, and that receivers, upon encountering X OR Y, MUST DO Z.
Thus  other spec writers can say “Do what RFCXXXX says” and not have to
resort to the sort of drafting pain that the people in Jose are
experiencing right now in order to avoid attacks on cryptographically
signed protocol elements by exploiting variation in dupe-key handling.

Is it the sense of the WG that such a document is within our mandate?  -T

---

From: Peter brooks <[email-masked]>
Date: Wed, 3 Jul 2013 07:32:00 +0200

Excellent points, Tim! I support this.

Sent from my iPad

On 3 Jul 2013, at 07:01, Tim Bray <[email-masked]> wrote:

> I’m having trouble dealing with the recent proposals from our co-chairs because I don’t think I understand what they’re trying to achieve.  Just to refresh, our charter says 
> 
> “The work is essentially a reclassification in place, with minimal changes. The working group will   eview errata and update the document as needed to incorporate those, and will correct significant  errors and inconsistencies, but will keep changes to a minimum.
> 
> It is acknowledged that there are differences between RFC 4627 and the ECMAScript specification  in the rules for parsing JSON. Any changes that break compatibility with existing implementations of  either RFC 4627 or the ECMAScript specification will need to have very strong justification and broad support. ”
> 
> The changes proposed by the chairs are pretty big. Maybe the problem is that any change which would actually CORRECT the two biggest errors/inconsistencies in 4267 would necessarily be pretty significant. When your charter is self-contradictory, you can either re-charter or decide to ignore one of the two contradictory directives.
> 
> I was getting really comfortable with the minimal proposal, which noted that while the spec more or less means what it says (strings should be Unicode, objects should have unique keys), there are other standards with different interpretations.  Also, there is variation among observed behavior in software, when the JSON RFC’s high-level directives are contravened.
> 
> What the industry really needs is a document normatively describing JSON-as-best-practiced, with an RFC number.  It would say that senders MUST NOT do X and Y, and that receivers, upon encountering X OR Y, MUST DO Z.  Thus  other spec writers can say “Do what RFCXXXX says” and not have to resort to the sort of drafting pain that the people in Jose are experiencing right now in order to avoid attacks on cryptographically signed protocol elements by exploiting variation in dupe-key handling.
> 
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Jul 2013 01:36:59 -0500

On Wed, Jul 3, 2013 at 12:01 AM, Tim Bray <[email-masked]> wrote:
> [...]

+1.

> resort to the sort of drafting pain that the people in Jose are experiencing
> right now in order to avoid attacks on cryptographically signed protocol
> elements by exploiting variation in dupe-key handling.

I'd be happy with either of:

 - no update to RFC4627, but a BCP, and possibly an FYI about what
ECMAScript (and others) do,

or

 - an update to RFC4627 noting the divergent interpretations and only
absolute minimal normative language additions for which we have
consensus (possibly none) (and remove the safe-for-eval regexp
nonsense), plus a BCP.

I might be happy with just concluding, but only as a last resort.

> Is it the sense of the WG that such a document is within our mandate?  -T

We should recharter if it isn't, and either way we should then
publish.  If we can't either find it in the charter nor get consensus
to re-charter then we should conclude (and take some more painkillers,
then promptly forget this episode).

So that's a big +1 from me.

Nico
--

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 3 Jul 2013 12:43:53 +0200

On Wednesday, July 03, 2013 7:02 AM, Tim Bray wrote:
> JSON-as-best-practiced, with an RFC number.  It would say that senders
> MUST NOT do X and Y, and that receivers, upon encountering X OR Y,
> MUST DO Z.  Thus  other spec writers can say “Do what RFCXXXX says”
> and not have to resort to the sort of drafting pain that the people in
> Jose are experiencing right now in order to avoid attacks on
> cryptographically signed protocol elements by exploiting variation in
> dupe-key handling.

+1

> Is it the sense of the WG that such a document is within our mandate?

I hope so as it would be my preferred way forward.

--
Markus Lanthaler
@markuslanthaler

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 03 Jul 2013 16:17:35 +0200

* Tim Bray wrote:
>because I don’t think I understand what they’re trying to achieve.

The chairs would like to identify patches to draft-ietf-json-rfc4627bis
that reflect rough consensus and running code. I think we should accept
that this approach has failed and return to the traditional approach of
identifying substantive issues, discuss and resolve them, and then let
editors or other volunteers figure out how to implement decisions in the
draft.

>NOT do X and Y, and that receivers, upon encountering X OR Y, MUST DO Z.

I am more interested in one describing the application/json format. It
would say this is JSON and that isn't JSON and note that certain kinds
of JSON have interoperability problems and possibly note what's usually
done to mitigate them.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Jul 2013 08:35:09 -0700

<chair hats on>

> Is it the sense of the WG that such a document is within our mandate?  -T

Our mandate is completely specified in our current charter at any given moment. Such a document is not yet there, even though it has been widely discussed on this list for the very reasons you gave.

--Matt Miller and Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Jul 2013 08:37:03 -0700

<no hats>

+1 to everything Tim said, particularly "charter is self-contradictory". We didn't realize this when we put together the charter (a process in which dozens of people participated), but we do now.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Jul 2013 11:29:25 -0500

> +1 to everything Tim said, particularly "charter is self-contradictory". We didn't realize this when we put together the charter (a process in which dozens of people participated), but we do now.

Re-reading the charter I'm not sure that there's a contradiction.  We
can do something:

 - remove the safe-for-eval regexp silliness

 - add a section describing divergent interpretations

 - leave the rest mostly as-is with only those changes for which we
can get consensus

   E.g., we can probably get consensus for "generators SHOULD NOT
output duplicate names" and "parsers SHOULD use the last of any
duplicate names" with appropriate text describing when and why one
might deviate from this guidance.

   E.g., we can probably get consensus for describing a subset of JSON
strings that is guaranteed to interoperate, even though we can't ban
unpaired surrogates.

Then re-charter and publish a BCP.

Alternatively, we could re-charter now.  I can propose text as soon as
we decide to start that discussion.

Nico
--

---

From: Tatu Saloranta <[email-masked]>
Date: Wed, 3 Jul 2013 12:32:59 -0700

On Wed, Jul 3, 2013 at 9:29 AM, Nico Williams <[email-masked]> wrote:

> > +1 to everything Tim said, particularly "charter is self-contradictory".
> We didn't realize this when we put together the charter (a process in which
> dozens of people participated), but we do now.
>

+1 for this.

On unpaired surrogates: since their potential use has been outlined
multiple times, I am wondering if this has been substantiated by links to
systems that make use of this ability? I assume this potential exists only
on some platforms (and specifically not useful for platforms I typically
work on), but it would good to see links, similar to recent listing of
Streaming JSON processors one can find with bit of googling (happy to see
my SO answer being linked :) ).

-+ Tatu +-

---

From: Tim Bray <[email-masked]>
Date: Wed, 3 Jul 2013 12:35:27 -0700

+1 to Nico’s suggestion.  -T

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Jul 2013 21:42:04 +0200

On Jul 3, 2013, at 18:29, Nico Williams <[email-masked]> wrote:

> leave the rest mostly as-is 

That means that every user of JSON has to define their own additional clarifications, as JOSE has started to do.
In effect, each user creates their own little dialect.

A textbook example for how to create soup.

I'd rather have 2 or 3 flavors of JSON than n, where n is the number of users.
(Or, if it has to be, 2 or 3 on/off pizza toppings each of which can be selected or deselected.)

Grüße, Carsten

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Jul 2013 16:31:32 -0500

> In effect, each user creates their own little dialect.

Why couldn't they reference the BCP?

But as I said, I also don't mind us publishing an "Internet JSON".
We'd have to grapple with the meaning of the existing MIME type for
JSON, but JOSE could normatively reference "Internet JSON" and be
done.

I guess that's a lot of choices.

> (Or, if it has to be, 2 or 3 on/off pizza toppings each of which can be selected or deselected.)

Well, yes, but those N happen to mostly interop.  I'm not sure that
we've seen claims of non-interoperability for any applications, just
differences in JSON implementations which most definitely *can* cause
interop problems, but maybe they never happen because users implicitly
end up sticking to interoperable subsets of JSON.  Not robust, but the
world has been working anyways.

Nico
--

---

From: John Cowan <[email-masked]>
Date: Wed, 3 Jul 2013 23:05:32 -0400

> my SO answer being linked :) ).

I would say that the potential is there for any JSON system running on
a JVM, CLR, or JavaScript platform, since in all of these a string is
a sequence of 16-bit code points.

-- 
John Cowan    http://www.ccil.org/~cowan   <[email-masked]>
    "Any legal document draws most of its meaning from context.  A telegram
    that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
    5-bit Baudot code plus appropriate headers) is as good a legal document
    as any, even sans digital signature." --me

---

From: Norbert Lindenberg <[email-masked]>
Date: Wed, 3 Jul 2013 20:47:06 -0700

> a sequence of 16-bit code points.

You mean 16-bit code units, not code points.
http://www.unicode.org/glossary/#code_point
http://www.unicode.org/glossary/#code_unit

Norbert

---

From: Tatu Saloranta <[email-masked]>
Date: Thu, 4 Jul 2013 15:27:10 -0700

> a sequence of 16-bit code points.

Right I am not saying there is not potential -- potential is pretty clear
to me.

But is that potential used by anyone to substantial degree? Is there
existing use that would be hampered? What would break?

-+ Tatu +-