Subject: [Json] RFC 4627bis vs RFC 6902 (JSON Patch)

From: Francis Galiegue <[email-masked]>
Date: Thu, 20 Feb 2014 18:03:09 +0100

Hello,

Something makes me really uneasy when I read these two documents side by side.

RFC 4627bis (even though only a draft at the moment), section 4,
reads: "When the names within an object are not unique, the behavior
of software that receives such an object is unpredictable".

RFC 6902, section 4, reads: "Operation objects MUST have exactly one
"op" member".

The latter makes sense on the _producer_ of a patch operation;
however, on the parser side, should a parser receive a "malformed"
(f.e duplicated "op") operation, it seems to me that RFC 6902 expects
the parser to raise an error -- which RFC 4627bis does not mandate.

What are your thoughts?

-- 
Francis Galiegue, [email-masked]
JSON Schema in Java: http://json-schema-validator.herokuapp.com

---

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Feb 2014 12:31:06 -0500

> the parser to raise an error -- which RFC 4627bis does not mandate.

What do you see as a conflict?

The JSON spec gives general parameters for JSON, and allows duplicates.

The JSON Patch spec gives specific parameters for a specific use of
JSON.  For that use, duplicates are not allowed.

That all looks just fine to me, and absolutely consistent.

Barry

---

From: Francis Galiegue <[email-masked]>
Date: Thu, 20 Feb 2014 18:35:57 +0100

> That all looks just fine to me, and absolutely consistent.

Not to me. As I see it, 75+% of JSON parsers on the "market" just
cannot parse JSON Patch correctly because of the restrictions imposed
by RFC 6902. Note: parse, not emit (or "consume, not produce" -- or
whatever metaphor suits you).

IOW: I don't see "MUST have a unique member named 'foo'" and
"behaviour is unpredictable" as being consistent with one another.

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Feb 2014 11:44:34 -0600

> whatever metaphor suits you).

JSON Patch predates the discussions as to RFC4627bis, so a bit of
mismatch is to be expected.  JSON Patch says "objects MUST have
exactly one ..." but parser behavior is not specified, so it's unclear
if that's a requirement for encoders or parsers.  Even if you
interpret that as a requirement for parsers, the requirement may be
met by the application rather than the parser (e.g., when the
application uses an online JSON parser).

We had very many very lengthy threads on subjects like this in the
JSON WG, and I'm pretty sure that we discussed JSON Patch in
particular as well.  You might want to look at the archives.

> "behaviour is unpredictable" as being consistent with one another.

The former is insufficiently prescriptive, therefore ill-defined,
therefore consistent with the latter.

FWIW, the JSON WG had proposals to improve this and other aspects of
JSON, but it was heavily constrained by _actual_ practice in the wild.

Nico
--

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Feb 2014 18:50:46 +0100

> whatever metaphor suits you).

“cannot parse”?  I don’t think so.
I think what you are trying to achieve is “reliably detect and reject input that causes unpredictable behavior”.
This is a quality-of-implementation expectation for a parser that is often traded for performance, and rightly so.
Instead, the behavior is indeed unpredictable, just as the specification says.

I’m with Barry on this one: This is completely consistent.
(Except that I wouldn’t summarize 4627bis as “allows duplicate keys”.  
Sure, it also “allows" hitting yourself on the head with a hammer.
But here, it explicitly warns that its sole objective, interoperability, is not achievable if you do that.)

Grüße, Carsten

---

From: Francis Galiegue <[email-masked]>
Date: Thu, 20 Feb 2014 19:19:25 +0100

Sorry, user error, didn't find its way to the list

---------- Forwarded message ----------
From: Francis Galiegue <[email-masked]>
Date: Thu, Feb 20, 2014 at 7:17 PM
Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch)
To: Nico Williams <[email-masked]>

On Thu, Feb 20, 2014 at 6:36 PM, Nico Williams <[email-masked]> wrote:
[...]
>>
>> What are your thoughts?
>
> I don't see the conflict.
>
> FYI, text in RFC4627bis was arrived at after very many and lengthy
> (well over 1,000 posts) threads on the JSON WG list.  I'd summarize
> the part about duplicate names as:
>
> The nature of JSON as it is used in the wild is such that RFC4627bis
> couldn't require any specific parser behavior as to duplicate names --
> the canonical example is online parsers, whose very purpose is to keep
> minimal state while parsing, which means that they can't detect
> duplicate names, which means that specific parser behavior regarding
> duplicate names could not be REQUIRED.  (There was also a question of
> whether specific behavior could be required of the parser _and_
> application together, and the conclusion was also "no".)
>

OK, then what about constraints on JSON emission instead? RFC 4627bis
section 10 does mention that any emitted JSON must be conform to the
grammar; can't a condition be added that in the case of JSON objects,
they SHOULD ensure about the uniqueness of member names?

Admittely, I can live with the texts as they currently stands; it is
just that this shadowy area leaves an acrid aftertaste in my mouth,
that's all ;)

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Feb 2014 12:30:37 -0600

> they SHOULD ensure about the uniqueness of member names?

The same issues apply here.  For example, online encoders by
definition don't keep sufficient state.

Also, the

> just that this shadowy area leaves an acrid aftertaste in my mouth,

If you even skim the list archives you'll find you're not alone.
You'll also find why RFC4627bis had to end up the way it did.

Nico
--

---

From: Francis Galiegue <[email-masked]>
Date: Thu, 20 Feb 2014 20:14:09 +0100

> definition don't keep sufficient state.

Sorry, but how is that a reason? If [we|the IETF|John Doe](1) were to
care about online services and all their technical deficiencies to
push changes forward, would the Internet even move forward?

(1) remove unused mention(s)
-- 
Francis Galiegue, [email-masked]
JSON Schema in Java: http://json-schema-validator.herokuapp.com

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Feb 2014 13:18:44 -0600

Why retread when the WG did so *many* times on the list?  You should
read the list archives.

Nico
--