IETF Logo Mail Archive

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

"Manger, James" <James.H.Manger@team.telstra.com> Wed, 15 October 2014 23:06 UTC

Return-Path: <James.H.Manger@team.telstra.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 078FF1ACE0C for <apps-discuss@ietfa.amsl.com>; Wed, 15 Oct 2014 16:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] 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 vRrzV_dFkGZn for <apps-discuss@ietfa.amsl.com>; Wed, 15 Oct 2014 16:06:44 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id ED5B21ACE0F for <apps-discuss@ietf.org>; Wed, 15 Oct 2014 16:06:43 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,728,1406556000"; d="scan'208";a="45356767"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 16 Oct 2014 09:49:35 +1100
X-IronPort-AV: E=McAfee;i="5600,1067,7592"; a="267585682"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdvi.tcif.telstra.com.au with ESMTP; 16 Oct 2014 10:06:38 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 16 Oct 2014 10:06:38 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, RFC Errata System <rfc-editor@rfc-editor.org>, "paul.hoffman@vpnc.org" <paul.hoffman@vpnc.org>, "jasnell@gmail.com" <jasnell@gmail.com>, "barryleiba@computer.org" <barryleiba@computer.org>, "presnick@qti.qualcomm.com" <presnick@qti.qualcomm.com>, "superuser@gmail.com" <superuser@gmail.com>, "alexey.melnikov@isode.com" <alexey.melnikov@isode.com>
Date: Thu, 16 Oct 2014 10:06:37 +1100
Thread-Topic: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132)
Thread-Index: Ac/opzu+W2YDdLLNRk6rzRX7NGqo4QAIft1Q
Message-ID: <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com>
References: <20141015183752.37123181C73@rfc-editor.org>
In-Reply-To: <20141015183752.37123181C73@rfc-editor.org>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hk305cnw80dZLAmR2O-FfNOwlW4
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.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: Wed, 15 Oct 2014 23:06:54 -0000

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] On Behalf Of RFC Errata System
Sent: Thursday, 16 October 2014 5:38 AM
To: paul.hoffman@vpnc.org; jasnell@gmail.com; barryleiba@computer.org; presnick@qti.qualcomm.com; superuser@gmail.com; alexey.melnikov@isode.com
Cc: apps-discuss@ietf.org; rfc-editor@rfc-editor.org
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>

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

v2.23.0 | Report a Bug | By Email