Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132)

Barry Leiba <barryleiba@computer.org> Thu, 16 October 2014 14:53 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CB01A1BE1 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Oct 2014 07:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 ghFoMSKAZwxu for <apps-discuss@ietfa.amsl.com>; Thu, 16 Oct 2014 07:53:22 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0118E1A1BDD for <apps-discuss@ietf.org>; Thu, 16 Oct 2014 07:53:21 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id pv20so2984919lab.20 for <apps-discuss@ietf.org>; Thu, 16 Oct 2014 07:53:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HFXyYBeisf5ZGxyBtjJXgCFmZBo4k+WbN5nGfr+7dCw=; b=paLMJadQBGjFZdLDlXbTamtzVeywjAZ168maoxvBfoVsGZ4kmVhN9J9OCCDBxQE1hf gjBBnuImfE+uj9+KVqVlFNt72eGS2tGk6N+F384Vocr3Nld1AHiZhOAh6Kb2a6ROVVEU SR8G/XXvXEwaGsFu07iyDsZ1mzPbv3D3cf8wikPNWcIMi9xg1HrvId6mW4fJkzR1ndan EXwDm/XaEBGrO2u5qjygPlbBgR2Ep8Bcbkt1PG5CDLpd+6ReTXzjmhFBCo01RQgqUfO6 VcdGecUkBMoEofwYkLPAHWhRszwnsHQF1AC1R80pz5D9cCJvdiovSOupl2ETewk56La0 8p+w==
MIME-Version: 1.0
X-Received: by 10.112.132.104 with SMTP id ot8mr2175032lbb.3.1413471200058; Thu, 16 Oct 2014 07:53:20 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.152.8.103 with HTTP; Thu, 16 Oct 2014 07:53:20 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com>
References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com>
Date: Thu, 16 Oct 2014 10:53:20 -0400
X-Google-Sender-Auth: DRTwXXVxAGhznevoPlzgc9W3VpM
Message-ID: <CALaySJ+G97TRRc-H2LCHpBfHi21t-iho=m+JXow+DkdV0UEy5g@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Content-Type: multipart/alternative; boundary="047d7b3a7ffec7a3a105058b6824"
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KZA3erl7ZSHowqFQBaqntn4nJzM
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "presnick@qti.qualcomm.com" <presnick@qti.qualcomm.com>, "paul.hoffman@vpnc.org" <paul.hoffman@vpnc.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2014 14:53:24 -0000

I will mark the report as Verified (and will change it to Technical), but
there is no way to have the RFC fixed without a new RFC that obsoletes it.
This is all stuff that should be checked in AUTH48, and is why the RFC
Editor recommends not relying only on the diff.

James, if you want to get it updated tout de suite, you can submit a
7386bis draft, which I will immediately last call.  To do the draft, get
the final 7386.xml from the RFC Editor, add an "obsoletes=7386" at the top
(and take off the special RFC Editor attributes), make sure all the tabs
are replaced by spaces and everything lines up correctly, and add a
paragraph to the Abstract and Introduction that says that this is a
replacement to RFC 7386 that corrects indentation errors.  Make no other
changes, and I'll note in the last call note that no other changes are in
scope.

The replacement RFC will have a new RFC number.

Barry

On Wednesday, October 15, 2014, Manger, James <
James.H.Manger@team.telstra.com> wrote:

> Thanks for reporting this as an errata Stephane. "Editorial" is the wrong
> classification however; it is "Technical". The indentation is critical to
> understanding the function. The function isn't merely to reinforce
> normative text -- the function is the only normative specification of the
> Merge-Patch processing rules. The other text only gives a casual
> description of some rules (in the introduction), calls attention to some
> corner cases, and provides examples.
>
> If the RFC editors cannot correct the indentation, we need a new RFC.
> Personally I don't think an accepted errata is sufficient. The doc is too
> unusable in its current state.
> Can this sort of critical typo be fixed without a new RFC number?
>
> P.S. Curiously, the "Diff2" format on tools.ietf.org [
> https://tools.ietf.org/rfcdiff?url2=rfc7386] shows the indentation as
> being correct in rfc7386.txt and draft-ietf-appsawg-json-merge-patch-07.
> Probably a tools glitch.
>
> --
> James Manger
>
>
> -----Original Message-----
> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org <javascript:;>]
> On Behalf Of RFC Errata System
> Sent: Thursday, 16 October 2014 5:38 AM
> To: paul.hoffman@vpnc.org <javascript:;>; jasnell@gmail.com <javascript:;>;
> barryleiba@computer.org <javascript:;>; presnick@qti.qualcomm.com
> <javascript:;>; superuser@gmail.com <javascript:;>;
> alexey.melnikov@isode.com <javascript:;>
> Cc: apps-discuss@ietf.org <javascript:;>; rfc-editor@rfc-editor.org
> <javascript:;>
> Subject: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132)
>
> The following errata report has been submitted for RFC7386, "JSON Merge
> Patch".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7386&eid=4132
>
> --------------------------------------
> Type: Editorial
> Reported by: Stéphane Bortzmeyer <bortzmeyer@nic.fr <javascript:;>>
>
> Section: 2
>
> Original Text
> -------------
> define MergePatch(Target, Patch):
>        if Patch is an Object:
>          if Target is not an Object:
>        Target = {} # Ignore the contents and set it to an empty Object
>          for each Name/Value pair in Patch:
>        if Value is null:
>          if Name exists in Target:
>            remove the Name/Value pair from Target
>        else:
>          Target[Name] = MergePatch(Target[Name], Value)
>          return Target
>        else:
>          return Patch
>
> Corrected Text
> --------------
>    define MergePatch(Target, Patch):
>      if Patch is an Object:
>        if Target is not an Object:
>          Target = {} # Ignore the contents and set it to an empty Object
>        for each Name/Value pair in Patch:
>          if Value is null:
>            if Name exists in Target:
>              remove the Name/Value pair from Target
>          else:
>            Target[Name] = MergePatch(Target[Name], Value)
>        return Target
>      else:
>        return Patch
>
> Notes
> -----
> Indentation of the pseudo-code example was correct in the Internet-Drafts
> but was  messed up in the final version. For instance, "Target = {}" should
> be under the two ifs. (Reported by James H. Manger on the appsawg mailing
> list.)
>
> 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 (IESG) can log in to change the
> status and edit the report, if necessary.
>
> --------------------------------------
> RFC7386 (draft-ietf-appsawg-json-merge-patch-07)
> --------------------------------------
> Title               : JSON Merge Patch
> Publication Date    : October 2014
> Author(s)           : P. Hoffman, J. Snell
> Category            : PROPOSED STANDARD
> Source              : Applications Area Working Group
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG
>
>