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

The erratum would have been more convincing had it described any plausible
course of action other than rejecting or silently accepting the BOM.  I
can't think of anything useful that software could do. That doesn't mean
there isn't anything, but a suggestion would be helpful.

On Wed, Jun 10, 2020 at 7:50 AM David Golden <xdg@xdg.me> wrote:

> I understand.  Would it be more appropriate then to limit the "may ignore
> a BOM" to "may ignore a UTF-8 BOM" so that the interop suggestion does not
> inadvertently encourage incorrect decoding?  That would be consistent with
> the UTF-8 only restriction and leave legacy encoding/BOM considerations out
> of scope.
>
> I realize this may seem picky, but this stems from discussions at work
> about whether/how to support legacy BOMs and people have interpreted the
> RFC differently.  I was hoping to create clarity consistent with the intent
> of the working group, whatever that turns out to be.
>
> David
>
> On Wed, Jun 10, 2020 at 10:42 AM Barry Leiba <barryleiba@computer.org>
> wrote:
>
>> David, I understand that it might be worth having further discussion
>> about the issue.  The problem *here* is that there is not an error in
>> the RFC: the RFC accurately reflects the consensus of the working
>> group and the text that was reviewed and agreed on at the time.  So
>> it's not in scope for an errata report.  Discussion about whether or
>> not to revisit this and to publish an RFC that says something
>> different is... a separate discussion.
>>
>> Barry, ART AD
>>
>> On Wed, Jun 10, 2020 at 10:38 AM 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
>>
>
>
> --
> David Golden <xdg@xdg.me> • https://xdg.me/ • Twitter/GitHub: @xdg
>