JSON Merge Patch
draft-ietf-appsawg-json-merge-patch-07
Yes
(Barry Leiba)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Alissa Cooper)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Spencer Dawkins)
(Ted Lemon)
Note: This ballot was opened for revision 06 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -06)
Unknown
Pete Resnick Former IESG member
(was Discuss)
Yes
Yes
(2014-08-21 for -06)
Unknown
My previous DISCUSS asked for some textual description of the pseudocode. It turns out that the WG attempted that and was unable to come up with something clear enough to produce interoperable implementations. That's a bummer, but I am willing to take the WG's word that they tried.
I will only suggest adding some text after the pseudocode to assist folks in noticing some of the "interesting" aspects of the patch procedure:
Note: This algorithm has some results that might not be immediately
obvious to the implementer:
- If the Patch is not itself an object, the Patch replaces the entire
contents of the Target.
- The Patch can only affect the entire value of a member of a Target
object. In particular, a Patch cannot change members of an array;
it can only replace or delete the entire array.
If the WG thinks there are other things worth mentioning, it might help the implementer. As I said previously, it did take me re-reading the pseudocode several times to truly understand the semantics, and if an implementer needs to structure their code differently than the pseudocode, it would be nice to point out some possibly tricky bits.
Adrian Farrel Former IESG member
No Objection
No Objection
(for -06)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -06)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -06)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -06)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -06)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -06)
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2014-08-21 for -06)
Unknown
Thanks for the discussion on checking the integrity of received patches, it was helpful.
Martin Stiemerling Former IESG member
No Objection
No Objection
(2014-08-15 for -06)
Unknown
no objection from my side and my checks where solely related to any Transport layer related issues.
Richard Barnes Former IESG member
No Objection
No Objection
(2014-08-20 for -06)
Unknown
One major note and a couple of minor notes: (0) In line 7 of the pseudocode, s/Key/Name/ (1) Is there any concern about confusion due to the fact that patches are syntactically indistinguishable from JSON? Presumably this is mitigated by the use of the media type, but it might be worth a mention, e.g., in the Security Considerations. (2) Thanks for the note about the fact that this document assumes that an attribute being absent and an attribute being null are equivalent. This might be worth reprising in the Security Considerations, in case there are usages of JSON that use this distinction to express security-relevant information. For example, if presence of an element is used to signal support for a feature, but null is allowed as a value.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -06)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-08-20 for -06)
Unknown
I didn't get why if Patch is not an object then MergePatch(foo, Patch) returns Patch.
Ted Lemon Former IESG member
No Objection
No Objection
(for -06)
Unknown