Shepherd writeup
rfc7386-07

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.
Back