Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

"Murray S. Kucherawy" <> Tue, 08 January 2013 04:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EB4C11E8097; Mon, 7 Jan 2013 20:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id utRG83JWgdBS; Mon, 7 Jan 2013 20:40:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C276021F846E; Mon, 7 Jan 2013 20:40:20 -0800 (PST)
Received: by with SMTP id em20so8112lab.28 for <multiple recipients>; Mon, 07 Jan 2013 20:40:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WWhwUo8iuICmHP0k/Wkr1TSkhuqa4juxuM6ZL+Wc5iY=; b=Q6pZjTpZAvnld7wxtJ+TqIdPVhDzFpnaLNvvfMsHxrnqMYlmSGFex/AzumtJ29+QAV dYTRV/oFAn9t1xQdLCqTvEAc5UXSzP9zWB1z9CD0atvJ/RyLyTgrXpICJLcWu8sRejX/ PMwne6tq1cdmM8Kc9x/4YQ8cYBViorkfBZDRlbf6KHWRJU5dztoHoDIX8YMc8J1jHz5M 2QeWIa4WcoAEZiowsUblOkWQUXFfdX0FbgaITz/+PqnPCPkGcdx12R9W67lg97lQIewl cvJK7OO2WyuBcTT39iWbTA1Q5qwE6zeBMj8VwjrD0XD36/9iIs27W7lTy12zYES7N5pX Jeww==
MIME-Version: 1.0
Received: by with SMTP id w8mr26229283lbz.49.1357620019682; Mon, 07 Jan 2013 20:40:19 -0800 (PST)
Received: by with HTTP; Mon, 7 Jan 2013 20:40:19 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <1357515310.6827.23.camel@polyglot> <> <>
Date: Mon, 07 Jan 2013 20:40:19 -0800
Message-ID: <>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
From: "Murray S. Kucherawy" <>
To: "Paul C. Bryan" <>
Content-Type: multipart/alternative; boundary="bcaec554e0f6035f4004d2bf8b75"
Cc: Mark Nottingham <>, IETF Discussion <>, IETF Apps Discuss <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Jan 2013 04:40:22 -0000

I apologize for being absent for this thread until now.  Vacation and
medical matters interfered with me keeping current.

First, with my participant hat on:

I've been occasionally comparing this work to conventional UNIX "patch" to
try to maintain a point of reference as these works developed.  As such,
I'm swayed by the argument (which, as I recall, was part of working group
deliberations prior to WGLC) that we have the "test" operations, so people
generating patch documents should use them to ensure proper context before
applying any of the operations that alter the target.  UNIX "patch"
accomplishes this by default by surrounding the lines to be changed in the
target with context lines that aren't changed, and so must exist precisely
as-is before the change can be made or the change is rejected.  Consider a
target file comprising 26 lines, each containing the next character of the
upper-case English alphabet and a newline, but the M and the N lines are
swapped.  A typical patch to fix this would look like so:

--- x   Mon Jan  7 20:27:36 2013
+++ y   Mon Jan  7 20:27:40 2013
@@ -10,8 +10,8 @@

The default for UNIX "diff" is to produce three lines of context above and
below the change to be made to ensure the change is being made in the right
place.  One could also request no lines of context, yielding:

--- x   Mon Jan  7 20:27:36 2013
+++ y   Mon Jan  7 20:27:40 2013
@@ -13 +12,0 @@
@@ -14,0 +14 @@

But this doesn't bother to check any context, except of course to ensure
that the target file is at least 14 lines long.  Although the top one is
clearly safer, both are actually legal patches.

In my view, these two JSON documents present a language for referencing and
object and changing it, and also for querying for context, just like the
conventional UNIX diff/patch format does.  But in neither the UNIX case nor
the proposed JSON case is the context part mandatory to use (though one
could certainly argue it's foolish to skip doing so).  That seems fine to

Then, with my co-chair hat on:

Although I hear and understand Robert's position that this is an important
thing that needs to be addressed, it is not my view after reviewing this
thread that there's rough consensus to reopen the question.  Please note
that this is not an "it's too late in the process to change this" position,
but rather one that notes that the burden of supporting a change to
something that already has rough consensus is on the person proposing the
change, and I don't believe Robert has succeeded here.

That said, I would ask the document editors to consider adding a paragraph
or an appendix indicating this issue was considered during development of
the work and the current format was deliberately selected, preferably with
some supporting text.  This will ensure future readers will not interpret
the chosen design as a bug, but rather an intentional design choice.

-MSK, APPSAWG co-chair

On Mon, Jan 7, 2013 at 5:33 PM, Paul C. Bryan <> wrote:

> **
> On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote:
>  This last assertion really isn't qualified very well.
> It would have been better for me to state this is my opinion, based on
> discussions that were animated from similar objections raised in the past.
> Paul
> _______________________________________________
> apps-discuss mailing list