[Json] Compliance vs. interop (Re: What does "break compatibility" mean?)

[Nico Williams <[e-mail]>]

On Fri, Mar 1, 2013 at 9:31 AM, Paul Hoffman <[e-mail]> wrote:
> On Mar 1, 2013, at 2:01 AM, Martin J. Dürst <[e-mail]> wrote:
>> Using a standard language lawyer approach, I think we can observe that changing the SHOULD NOT to a MUST NOT should be okay because SHOULD NOT means that you can do it if you have a really good reason for it, but I haven't yet seen anybody come up with a good reason for it, so I'd claim that the cases with duplicate keys that exist out in the wild actually don't comply to the current spec.
>
> That's not true at all. A perfectly valid reason for a JSON producer to put in two or more of the same name is a streaming producer that doesn't know what has been added before. Changing SHOULD NOT to MUST NOT means that a JSON producer MUST know everything else in the object before emitting it. It would be reasonable for this to be the consensus, but we can't say that it does not break compatibility with some producers. (And, of course, the other option is to break compatibility with some JSON processors.)

The new requirement for receivers takes care of not breaking senders
that continue to send duplicate keys.  There's no breakage, except
where previously undefined receiver behavior changes due to the new
requirement on receivers, but that was always a possibility before, so
there's no new breakage.

You seem to define "break" as including "rendering no longer being
compliant, even if still being interoperable".

Perhaps you could offer your proposal.  Or we can speculate about it.
You seem to want to keep the SHOULD NOT send dups but (?) add the new
receiver requirement.  Your rationale for this seems to be that
rendering senders of dups non-compliant is somehow bad, to which I've
two responses:

a) The old senders will remain compliant with the RFC in force when
they were deployed.  Ergo there there's no valid "rendered
uncompliant" concern.

b) Even if (a) is unconvincing, again, we have NO IETF COMPLIANCE
POLICE.  When these sorts of changes come up the first question should
be "what about interop?"; the "what about causing implementations to
remain interoperable but no longer compliant?  who will soothe their
feelings?" should have much lower importance.

Perhaps we need to deal with that meta issue first: do we (the WG, the
area, and/or the IETF) have a goal of not rendering existing
implementations of Internet standards non-compliant with updates to
said standards?  Is this even a valid question (see point (a) above)??

(It's clear we still care first and foremost about
interoperability/compatibility when it comes to updating existing
Standards-Track RFCs.  As we should.  I hope that doesn't come into
question.)

Nico
--