JavaScript Object Notation (JSON) Patch
RFC 6902

Note: This ballot was opened for revision 08 and is now closed.

Barry Leiba Yes

(Pete Resnick) Yes

Comment (2013-01-08 for -09)
No email
send info
Section 4:

   Additionally, operation objects MUST have exactly one "path" member,
   whose value MUST be a string containing a [JSON-Pointer] value that
   references a location within the target document to perform the
   operation (the "target location").

First MUST is fine. On the second, are you saying "MUST be a string" or "MUST be a JSON-Pointer value" or "MUST reference a location within the target document" or some combination? And why not just "...whose value is a string..."? What is that MUST adding besides confusion? What might I think is a good idea to do that this MUST is reminding me I MUST NOT do?

   Members that are not
   explicitly defined for the operation in question MUST be ignored.

You mean, "The operation must complete as if the undefined member did not appear in the object."? Might be worth adding that. Also, as per Stephen's comment, you should probably mention explicitly, "other than op and path".

Section 4.3:

   The operation object MUST contain a "value" member
   that specifies the replacement value.

What else could it contain? How could I get this wrong? Or did you instead mean "The operation object MUST contain a "value" member, which specifies the replacement value."? (See also section 4.6.)

Section 4.5: Perhaps there should be more explanation or a more explicit back-pointer to the "add" section, assuming that this has the same "array insert/other object replace or add" behavior that "add" does.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-01-07 for -09)
No email
send info
- The abstract is a tiny bit misleading, since this is mostly
defining mechanisms and not the media type. I'd just move the
mention of the media type to the end of the abstract.

- Would it be useful to have an example of an HTTP PATCH method
invocation with this media type?

- Section 4: I'm not 100% clear on whether or not I MUST ignore
an unknown operation. You say that the value of the "op" member
MUST be one of those listed, but then you say members that are
not explicitly defined for the operation MUST be ignored. I
think you mean that an unknown op value is an error, but its
not quite crystal clear.

- 4.1: This bit isn't very clear to me: 'For example, "add"ing
to the path "/a/b" to this document:' Too many to's maybe.

- 4.1: This doesn't say there MUST be a value member, but 4.3
does. Maybe better to be consistent.

- 4.6: Just checking - is false==null in this context or not? Its
fine if that's clear enough already to JSON folks, but its not
clear to me. (I assume you want false!=null)

- A.2: Just checking - I guess its clear that array indices
start at 0? If not maybe good to say that, since its only here
that that becomes apparent, if you didn't already know.

- A.10: The value of value surprised me here, but makes sense I
guess. Would it be worth highlighting this in section 4 too?

- A.12: Thanks for that - I was wondering about it:-)

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Robert Sparks) No Objection

Comment (2013-01-08 for -09)
No email
send info
The discussion of JSON parsers that hide duplicate elements in the example in A.13 raises a question.

What makes "last" special in this case? Why would we encourage the use of a parser that hid duplicate elements returning
the last value over one that always returned the first? Is there a normative requirement somewhere else you can point to that explains that choice?

(btw, why did RFC4627 only say "The names within an object SHOULD be unique."?)

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-01-08 for -09)
No email
send info
Is there going to be a time when you're going to want to test other ways like greater than or less than?  Wouldn't "equality" be better name instead of test?