Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-04.txt

From: [email-masked]
Date: Fri, 04 Jul 2014 11:44:45 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : JSON Merge Patch
        Authors         : Paul Hoffman
                          James M Snell
	Filename        : draft-ietf-appsawg-json-merge-patch-04.txt
	Pages           : 8
	Date            : 2014-07-04

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 target resource's content.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-merge-patch-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Jul 2014 11:48:22 -0700

Greetings again. This draft incorporates the proposed changes from Carsten and James, as well as removing the charset option from the MIME type (based on input from Ned Freed). 

Please review my new pseudocode, and the new examples at the end.

--Paul Hoffman

---

From: James M Snell <[email-masked]>
Date: Fri, 4 Jul 2014 11:51:17 -0700

+1...
On Jul 4, 2014 11:48 AM, "Paul Hoffman" <[email-masked]> wrote:

> Greetings again. This draft incorporates the proposed changes from Carsten
> and James, as well as removing the charset option from the MIME type (based
> on input from Ned Freed).
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Manger, James" <[email-masked]>
Date: Sat, 5 Jul 2014 23:37:15 +1000

+1

Pseudo code works well for describing the merge process.

The only remaining non-editorial change required is to remove the following sentence from section 1 "Introduction":

   A JSON merge patch document can only be a JSON array or a JSON
   object.

The pseudo code does not implement this restriction. Two of the test cases in appendix A violate this restriction.

Editorial suggestions:

* Change "marge" to "merge" [section 2, 2nd paragraph, page 3]

* The abstract and into both include the following phrase that is a bit awkward:

   modifications to a subset of target resource's content.

Might read better as:

   modifications to a target resource's content.

* It would be worth explicitly stating that the target resource and merge patch are JSON values. Add a sentence to the end of the 2nd paragraph of section 2 so it reads:

   MergePatch ... takes two arguments: the target resource document
   and the merge patch document. The Target argument can be any
   JSON value, or undefined. The Patch argument can be any JSON value.

* Is the contact in the media type registration (section 4 "IANA Considerations") usually an author as in the draft, or is it better to use, say, IESG <[email-masked]>?

* In section 4 "IANA Considerations" change:
  "same encoding considerations specified in Section 6 [RFC7159]."
  To
  "same encoding considerations specified in Section 8 [RFC7159]."

--
James Manger

-----Original Message-----
From: apps-discuss [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Saturday, 5 July 2014 4:48 AM
To: IETF Apps Discuss
Subject: [apps-discuss] draft-ietf-appsawg-json-merge-patch-04: now with a new processing model

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 5 Jul 2014 22:25:58 +0200

> The pseudo code does not implement this restriction. Two of the test cases in appendix A violate this restriction.

Correct,  With the new stance on this in RFC 7159, it would also be a rather undesirable restriction.

I agree with your editorial points (except that I don’t have an opinion about contacts in media type registrations).

Other editorial points:

— Please make use of the errata to RFC 2119 (add “NOT RECOMMENDED”).
[This really should be in IDNITS…]

— s/execute the following function/realize the effect of the following function/
We are not constraining implementations here.
[The MUST in section 2 is above my threshold for gratuitous MUSTs as well.]

— s/Section 5 [RFC5789]/Section 5 of [RFC5789]/
(and similarly s/Section 8 [RFC7159]/Section 8 of [RFC7159]/)

— please left-align the headings in Annex A (this makes the examples easier to process automatically, see https://gist.github.com/cabo/7888768).

I’m not entirely sure that RFC5789 is really a normative reference, as "The merge patch format is primarily intended for use with the HTTP PATCH method” and might very well used outside it.

Apart from the one remnant sentence and the editorial points, this is ready to ship.

Grüße, Carsten

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 5 Jul 2014 21:40:24 -0700

> Apart from the one remnant sentence and the editorial points, this is
I'm inclined to wait until these can be handled in a revision (which will
have to wait until the embargo is lifted in Toronto) before sending it to
Barry, but if people (including Barry) are OK with these being handled as
part of IETF Last Call instead, then I'm happy to send it sooner.  Opinions?

-MSK

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 6 Jul 2014 06:43:22 +0200

There is an AD override for the embargo.
I have no idea how much of a waste of time it is for everyone involved, but this strikes me as a good use of the concept.

Grüße, Carsten

On 06 Jul 2014, at 06:40, Murray S. Kucherawy <[email-masked]> wrote:

> I'm inclined to wait until these can be handled in a revision (which will have to wait until the embargo is lifted in Toronto) before sending it to Barry, but if people (including Barry) are OK with these being handled as part of IETF Last Call instead, then I'm happy to send it sooner.  Opinions?
> 
> -MSK

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 6 Jul 2014 06:51:14 -0700

We are in no rush for this document. I will include the changes that come in the next few weeks, issue a new draft on the 21st, give people a few days to be sure the changes are OK (since Barry will be too busy with the meeting anyway), and then ask Murray to move it to Barry.

--Paul Hoffman