Subject: [apps-discuss] [Editorial Errata Reported] RFC6902 (4460)

From: RFC Errata System <[email-masked]>
Date: Sat, 29 Aug 2015 02:41:48 -0700 (PDT)

The following errata report has been submitted for RFC6902,
"JavaScript Object Notation (JSON) Patch".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6902&eid=4460

--------------------------------------
Type: Editorial
Reported by: Lucas Bickel <[email-masked]>

Section: 4.1

Original Text
-------------
   However, the object itself or an array containing it does need to
   exist, and it remains an error for that not to be the case.  For
   example, an "add" with a target location of "/a/b" starting with this
   document:

   { "a": { "foo": 1 } }

   is not an error, because "a" exists, and "b" will be added to its
   value.  It is an error in this document:

   { "q": { "bar": 2 } }

   because "a" does not exist.

Corrected Text
--------------
   However, the object itself or an array containing it does need to
   exist, and it remains an error for that not to be the case.  For
   example, an "add" with a target location of "/a/b" starting with this
   document:

   { "a": { "foo": 1 } }

   is not an error, because "a" exists, and "b" will be added to its
   value.  It is an error in this document:

   { "q": { "bar": 2 } }

   because "a" does not exist. Considering a target location of "/a/1"
   it should be not be an error in this document:

    { "a": [ "foo" ] }

    while the same "add" into this document will be an error:

    { "a": [ ] }

    because "/a/0" does not exist.

Notes
-----
Adding to an object has such a nice example that explains the error cases. I think adding to a sequential array should have one as well.

To my understanding this is already pretty clear from RFC6901, I feel it will make the spec easier to implement if we have an example right here.

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. 

--------------------------------------
RFC6902 (draft-ietf-appsawg-json-patch-10)
--------------------------------------
Title               : JavaScript Object Notation (JSON) Patch
Publication Date    : April 2013
Author(s)           : P. Bryan, Ed., M. Nottingham, Ed.
Category            : PROPOSED STANDARD
Source              : Applications Area Working Group APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Sat, 29 Aug 2015 09:52:56 -0400

Thanks for the comment, Lucas.  The errata report has been posted to
the apps-discuss list, and I'm going to forward it to the json mailing
list so it's recorded there for future reference.  The errata system,
though, isn't meant for suggestions, but for recording actual errors
in the documents -- so I'm going to mark this "rejected" with a
comment that the suggestion should be consider if a new version of the
document is done.

Barry, ART AD