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

Barry Leiba <barryleiba@computer.org> Wed, 10 June 2020 14:42 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF10F3A0982 for <json@ietfa.amsl.com>; Wed, 10 Jun 2020 07:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level:
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFhb1XoS2eE6 for <json@ietfa.amsl.com>; Wed, 10 Jun 2020 07:42:23 -0700 (PDT)
Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60FDC3A0922 for <json@ietf.org>; Wed, 10 Jun 2020 07:42:23 -0700 (PDT)
Received: by mail-io1-f65.google.com with SMTP id i25so2491845iog.0 for <json@ietf.org>; Wed, 10 Jun 2020 07:42:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=z7nDG9I+kJQP8y6mjdUf53l6kSNKC9sov2ObIf+SsrA=; b=EbsleH34qW20A21TcKHHH84A/cQaM7J31SgQeA0zpWzC4qk/RCbTCjBTESAIMnaH0M mBCSIcxo8GH/O/HFLmWpFSbp1a0YMA9a+rMD+zhYrf0V519inaCX7MHA7QlfDRevLbag 4L132FG4+Aj55pABUBl6GCdnS2xMkmelJR4VfklZKHz3LNunDziAmu1lacHjtegzLCCW Xy0TYreG3ssIFPyd8CUW+IgzK25A9R4RkrWkFBeaGtk0eh//zX9CWi90KaiDjvLgDPds 2KMAK56zkNQAinOaxKsH7IWoKUJu2fKkdhZRMaailB0Wlu1r5BFkvVgVQhZ8qluATtMM XPeg==
X-Gm-Message-State: AOAM533UCheSIZcMsLdUyV5dA/9cpOVds/XGKWy6U+Bl6Bw53HXXLhSU WSyCgq9l/qRJYoVHZX+3TNdZRtJfvCK5cy1CkkE=
X-Google-Smtp-Source: ABdhPJyNK3NX9Jv7Q3x22FjV/WFuSLQOytHRhApdoiA1XV2rW6hq1AOHAm/lIMx0lWMdiiASs58wCgAsrrSsttFqALc=
X-Received: by 2002:a05:6602:13c6:: with SMTP id o6mr3539781iov.84.1591800142494; Wed, 10 Jun 2020 07:42:22 -0700 (PDT)
MIME-Version: 1.0
References: <20200610133258.D4B85F4073D@rfc-editor.org> <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> <CAOeq1c_SW1WwHZPMwunWPh3W53vCZThvEUuhb5Y1_NnbT6s=ng@mail.gmail.com>
In-Reply-To: <CAOeq1c_SW1WwHZPMwunWPh3W53vCZThvEUuhb5Y1_NnbT6s=ng@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Wed, 10 Jun 2020 10:42:11 -0400
Message-ID: <CALaySJ+6zVXRW-PoXrXL4NaNyNBkd=gaN6M0Y2x0czFe_EGC4g@mail.gmail.com>
To: David Golden <xdg@xdg.me>
Cc: Carsten Bormann <cabo@tzi.org>, RFC Errata System <rfc-editor@rfc-editor.org>, Tim Bray <tbray@textuality.com>, Murray Kucherawy <superuser@gmail.com>, "Matthew A. Miller" <linuxwolf+ietf@outer-planes.net>, json@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/8qgOjNnoJbVZLqFwYEsCLXGqaxo>
Subject: Re: [Json] [Technical Errata Reported] RFC8259 (6208)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2020 14:42:38 -0000

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