Re: [Json] [Technical Errata Reported] RFC8259 (6208)

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