[Json] Sticking to the past -- Re: [Technical Errata Reported] RFC8259 (6208)

Hi David,

In the spirit of Barry’s point that this is no longer about the Errata Report, I’m changing the subject.

The question at hand really is whether we can ever fix mistakes in a protocol specification.

The 2006 RFC (4627) didn’t take benefit of the observation that JSON is used with UTF-8 in the wild.  With 7159 (2014) and 8259 (2017) we progressively did.

The question really is how much of a backward compatibility onus we impose on implementers.
The reality is that JSON works well in the Internet Standard (RFC 8259, 2017) form, and there is no point for implementers to bow to what wasn’t really the reality in 2006 anyway.

So adding any verbiage that could be misused to pressure implementers to implement the deprecated stuff would be counter-productive.  Yes, it might still be a good idea for a JSON implementers to accept BOMs (and "JSON comments", and trailing commas, and all the other cruft that we do to "increase interoperability" and that then hurts interoperability because other people come to rely on that lenience (*)), but the JSON Standard doesn’t have to (even mildly) encourage that.

There are no standard JSON supersets (at least not ones that can be called “JSON” (**)).

Grüße, Carsten

(*) a.k.a. “soup”
(**) (CBOR diagnostic notation clearly is a JSON superset)

> On 2020-06-10, at 16:37, David Golden <xdg@xdg.me> wrote:
> 
> I agree that BOMs don't belong on JSON, but three prior RFC allowed them.  (The first one even specified how to do so.)
> 
> Given a JSON text generated under a previous specification with a UTF-16/32 BOM, ignoring the BOM is incorrect behavior.  As currently written -- copied verbatim from the prior two RFCs when BOMs were legal -- the only interoperability suggestion is to ignore a BOM.
> 
> My proposal does not encourage the use of BOMs or unravel the WG consensus (which I fully support).  It merely prepares implementations for the presence of other implementations that predate the current, more restrictive specification.
> 
> Respectfully yours,
> David
> 
> On Wed, Jun 10, 2020 at 9:43 AM Carsten Bormann <cabo@tzi.org> wrote:
> The WG had pretty strong consensus that BOMs don’t belong on JSON.
> This “MAY” prepares implementations for the presence of other implementations that do not heed that consensus.  No functionality is assigned by this MAY.
> 
> Since Errata are not intended to unravel WG decisions: Reject.
> 
> Apart from that, I seriously don’t understand what the "indicate an alternate encoding” would be — the JSON text already is UTF-8?
> 
> Grüße, Carsten
> 
> 
> > On 2020-06-10, at 15:32, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> > 
> > The following errata report has been submitted for RFC8259,
> > "The JavaScript Object Notation (JSON) Data Interchange Format".
> > 
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6208
> > 
> > --------------------------------------
> > Type: Technical
> > Reported by: David Golden <xdg@xdg.me>
> > 
> > Section: 8.1
> > 
> > Original Text
> > ——————
> > In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.
> > 
> > Corrected Text
> > --------------
> > In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark or MAY interpret a byte order mark to indicate an alternate encoding rather than treating it as an error.
> > 
> > Notes
> > -----
> > The original line is copied from previous RFCs that specifically allowed alternate encodings.  In the context of a new, UTF-8 only restriction, interoperability provisions should also address interpreting legacy formats that predate the restriction.  By omission, readers may conclude that the *only* option for a BOM is to ignore or error.
> > 
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party  
> > can log in to change the status and edit the report, if necessary. 
> > 
> > --------------------------------------
> > RFC8259 (draft-ietf-jsonbis-rfc7159bis-04)
> > --------------------------------------
> > Title               : The JavaScript Object Notation (JSON) Data Interchange Format
> > Publication Date    : December 2017
> > Author(s)           : T. Bray, Ed.
> > Category            : INTERNET STANDARD
> > Source              : Javascript Object Notation Update
> > Area                : Applications and Real-Time
> > Stream              : IETF
> > Verifying Party     : IESG
> > 
> > _______________________________________________
> > json mailing list
> > json@ietf.org
> > https://www.ietf.org/mailman/listinfo/json
> 
> 
> 
> -- 
> David Golden <xdg@xdg.me> • https://xdg.me/ • Twitter/GitHub: @xdg
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json