Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
Matthew Morley <matt@mpcm.com> Mon, 17 December 2012 00:33 UTC
Return-Path: <mmorley@mpcm.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33A921F8526 for <ietf@ietfa.amsl.com>; Sun, 16 Dec 2012 16:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izDT-OIxGOSH for <ietf@ietfa.amsl.com>; Sun, 16 Dec 2012 16:33:38 -0800 (PST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8583321F8507 for <ietf@ietf.org>; Sun, 16 Dec 2012 16:33:38 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id fc26so6398550vbb.31 for <ietf@ietf.org>; Sun, 16 Dec 2012 16:33:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=YWNL5PMJIo9RTkUe18XEXF22Cu5izble7vJ/5tBhSoU=; b=ak5/zjcRi93HNs69tW3UEE9vTvsbnzvjqT5jh1kYI03wR0PWrKwZXrmbv4of5Salgz X6ewS2Aoni4hBv4lM2NRwU/MAb4GZtDb2jRzqKGYd6gTEAwqeLF33uG5RAsKVE/QYnP3 2qFDhMk88Ob3VpOfTHFjOMjezToLUsHnrg1f44BG9LpyJqzWrjnWsy3Ykx2Gwzk0HlfR PtHujs9PtxIbGGuPEMLlzHwKZ679MKq8h19LH5GmnUvAdFro+PD1VAs3gYlbVSODuvra axVzpVBQV5QrIanjET0xZXViFRgdQZBQkcDER0/CSDBgszQxsPqiZojv506YdqnBFa7k IW5w==
MIME-Version: 1.0
Received: by 10.220.219.204 with SMTP id hv12mr20181599vcb.71.1355704417586; Sun, 16 Dec 2012 16:33:37 -0800 (PST)
Sender: mmorley@mpcm.com
Received: by 10.220.227.197 with HTTP; Sun, 16 Dec 2012 16:33:37 -0800 (PST)
In-Reply-To: <CABP7RbfA33huBFadMeXTTEt=MkjW8-d4DFH7+GLXGurnm9sSRw@mail.gmail.com>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <CABP7RbeNsZ_rBWRjou=VG+hBhUKaOz+y1a0sSChwWiHte9znnQ@mail.gmail.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> <CAChr6SxZRc3B_HCbw76kLe2dsRSr43r-gLpfMVnCUfJTrZdTLA@mail.gmail.com> <CABP7RbfA33huBFadMeXTTEt=MkjW8-d4DFH7+GLXGurnm9sSRw@mail.gmail.com>
Date: Sun, 16 Dec 2012 19:33:37 -0500
X-Google-Sender-Auth: t1EVySSBC5Z8_bAkNvpNHwqwiK4
Message-ID: <CAOXDeqpPE4eNy_qJpDPdPHbCQakG9-hDcNZ3Sj9r4kWedByVzQ@mail.gmail.com>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
From: Matthew Morley <matt@mpcm.com>
To: James M Snell <jasnell@gmail.com>
Content-Type: multipart/alternative; boundary="14dae9cfcea43b0e9d04d101883e"
X-Gm-Message-State: ALoCoQnEVlSgrgS1lDjHwNc7DsKR/Fq8MylEj9dThURQ6xrnWHCNjxLOSgjGu4tQ0UODjSc43Pxr
X-Mailman-Approved-At: Mon, 17 Dec 2012 08:33:54 -0800
Cc: IETF Discussion <ietf@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Dec 2012 00:33:40 -0000
I am usually lurking and struggling to keep up with these posts. But, I concur with James, this really is a non-issue in practice. The JSON Pointer expresses a path down a JSON object to a specific context. The Patch expresses a change within or to that context. Everything about the both standards is about that end context. If you want to confirm the type of the context before applying a patch, this should probably be part of a test operation. I'm not sure if this is possible at this point (?), but that is where the logic should exist. On Sun, Dec 16, 2012 at 12:22 AM, James M Snell <jasnell@gmail.com> wrote: > > > > On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre <sayrer@gmail.com> wrote: > >> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler >> <markus.lanthaler@gmx.net> wrote: >> > >> > Hmm.. I think that’s quite problematic. Especially considering how JSON >> Pointer is used in JSON Patch. >> >> I agree--I provided the same feedback privately. It seems >> straightforwardly unsound. >> >> > In practice it doesn't seem to be much of an issue. > > Specifically, if I GET an existing document and get an etag with the JSON, > then make some changes and send a PATCH with If-Match, the fact that any > given pointer could point to an array or object member doesn't really > matter much. > > For example: > > > GET /the/doc HTTP/1.1 > > < HTTP/1.1 200 OK > ETag: "my-document-tag" > Content-Type: application/json > > {"1":"foo"} > > > PATCH /the/doc HTTP/1.1 > If-Match: "my-document-etag" > Content-Type: application/json-patch > > [{"op":"add","path":"/2","value":"bar"}] > > Generally speaking, someone should not be using PATCH to perform a partial > modification if they don't already have some knowledge in advance what they > are modifying. The only time the apparent ambiguity becomes an issue is > when a client is blindly sending a patch to an unknown endpoint... in which > case, you get whatever you end up with. > > - James > > > >> - Rob >> >> >> > >> > -- >> > >> > Markus Lanthaler >> > >> > @markuslanthaler >> > >> > >> > >> > >> > >> > >> > >> > From: James M Snell [mailto:jasnell@gmail.com] >> > Sent: Friday, December 14, 2012 5:41 PM >> > To: Markus Lanthaler >> > Cc: IETF Discussion; IETF Apps Discuss >> > Subject: Re: [apps-discuss] Last Call: >> <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard >> > >> > >> > >> > JSON Pointer does not distinguish between objects and arrays. That is >> not determined until the pointer is applied to an actual object instance... >> the pointer "/1" is valid against {"1":"a"} or ["a","b"] >> > >> > >> > >> > On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler < >> markus.lanthaler@gmx.net> wrote: >> > >> > I've asked that before but didn't get an answer. So let me ask again >> (even >> > though I'm quite sure it has already been asked by somebody else). >> > >> > How does JSON Pointer distinguish between objects and arrays? E.g. >> consider >> > the following JSON document: >> > >> > { >> > "foo": "bar", >> > "1": "baz" >> > } >> > >> > As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even >> > though that's probably not what the author intended. Is there a way to >> avoid >> > that? >> > >> > >> > Thanks, >> > Markus >> > >> > >> > >> > -- >> > Markus Lanthaler >> > @markuslanthaler >> > >> > >> > >> > >> > >> > > -----Original Message----- >> > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> > > bounces@ietf.org] On Behalf Of The IESG >> > > Sent: Tuesday, December 11, 2012 4:01 PM >> > > To: IETF-Announce >> > > Cc: apps-discuss@ietf.org >> > > Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer- >> > > 07.txt> (JSON Pointer) to Proposed Standard >> > > >> > > >> > > The IESG has received a request from the Applications Area Working >> > > Group >> > > WG (appsawg) to consider the following document: >> > > - 'JSON Pointer' >> > > <draft-ietf-appsawg-json-pointer-07.txt> as Proposed Standard >> > > >> > > The IESG plans to make a decision in the next few weeks, and solicits >> > > final comments on this action. Please send substantive comments to the >> > > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments >> may >> > > be >> > > sent to iesg@ietf.org instead. In either case, please retain the >> > > beginning of the Subject line to allow automated sorting. >> > > >> > > Abstract >> > > >> > > >> > > JSON Pointer defines a string syntax for identifying a specific >> > > value >> > > within a JSON document. >> > > >> > > >> > > >> > > >> > > The file can be obtained via >> > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ >> > > >> > > IESG discussion can be tracked via >> > > >> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ >> > > >> > > >> > > No IPR declarations have been submitted directly on this I-D. >> > > >> > > >> > > _______________________________________________ >> > > apps-discuss mailing list >> > > apps-discuss@ietf.org >> > > https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > >> > >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- Matthew P. C. Morley
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Manger, James H
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Abdussalam Baryun
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Abdussalam Baryun
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Paul C. Bryan
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Murray S. Kucherawy
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Carsten Bormann
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Paul C. Bryan
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Conal Tuohy
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Jared Rosoff
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Jared Rosoff
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Jared Rosoff
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Hector Santos
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre