1. Summary
Murray Kucherawy is the document shepherd.
Barry Leiba is the responsible Area Director.
From the Abstract:
This specification defines the JSON merge patch format and processing
rules. The merge patch format is primarily intended for use with the
HTTP PATCH method as a means of describing a set of modifications to
a subset of the target resource's content.
2. Review and Consensus
The document was adopted in May, 2013, and had some active development
on the apps-discuss list. The author then reached a point where he could
no longer support the work, and the document was parked for several
months while a new author was saught. Recently Paul Hoffman stepped forward
to complete the work.
The quality and quantity of reviews have been good, and include comments
from the media types Designated Expert. WGLC was completed in October, 2013,
resulting in further changes. The result appears to have consensus of the
working group (though see "Other Points" below).
3. Intellectual Property
The authors both affirm that they are submitting the document in full
compliance with BCP 78 and 79, and know of no outstanding IPR claims.
4. Other Points
IANA Considerations contained the following note, which was removed
in version -04:
NOTE: There were a few notes that the charset media type parameter
is unacceptable for a +json media type.
I asked the media types Designated Expert for his opinion, and he replied:
If I understand the issue correctly, it's that the application/json type
goes out of its way NOT to define a charset parameter, requiring instead
that compliant implementation be able to distinguish and handle utf-8,
utf-16, or utf-32, whereas this media type does define one.
IMO the parameter is a bad idea since it duplicates information that's
provided by the type itself, and thus is at best harmless and at worst
could create a silly state.
That said, I don't really see this as a registration issue. The suffix
registration for +json doesn't say "thou shalt not use charset parameters
for this type" - it probably should given the language in the
application/json registration, but it doesn't. And as a reviewer I try to
stick with enforcing the rules that are there, as opposed to imposing my
own tastes on the matter. So what I'd do is ask why the parameter is there
and recommend removing it absent a good reason for having it. But if that
suggestion was rejected, I'd approve the type, albeit reluctantly.
But this is a standards-track type in an RFC, which means that it's up to
the IESG to review and approve the type, not me. And the IESG's powers
are considerably broader. If I were on the IESG, I would insist on either
the removal of the parameter or the inclusion of a compelling explanation
for why it is there.
And if that explanation included "this type uses charsets other than the
three allowed by application/json" I'd then insist on the removal of the
suffix since this is not, properly speaking JSON as presently defined.