[Json] merge-patch in APPSA and i-json in JSON

Larry Masinter <masinter@adobe.com> Tue, 08 July 2014 17:27 UTC

Return-Path: <masinter@adobe.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF81B2BDB; Tue, 8 Jul 2014 10:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKJL0sDphDmb; Tue, 8 Jul 2014 10:27:13 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D17C1B2B67; Tue, 8 Jul 2014 10:27:13 -0700 (PDT)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.985.8; Tue, 8 Jul 2014 17:27:11 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Tue, 8 Jul 2014 17:27:11 +0000
From: Larry Masinter <masinter@adobe.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "json@ietf.org" <json@ietf.org>
Thread-Topic: merge-patch in APPSA and i-json in JSON
Thread-Index: Ac+a0HjpTP2xgtp6TJenjlRnxiyQMg==
Date: Tue, 08 Jul 2014 17:27:10 +0000
Message-ID: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.184.24.49]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0266491E90
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(80022001)(101416001)(15202345003)(107046002)(107886001)(15975445006)(229853001)(76576001)(4396001)(77982001)(85306003)(86362001)(54356999)(50986999)(81542001)(83072002)(19580395003)(83322001)(85852003)(21056001)(76482001)(74502001)(74316001)(105586002)(99396002)(74662001)(81342001)(79102001)(92566001)(106356001)(33646001)(46102001)(64706001)(2656002)(95666004)(99286002)(87936001)(31966008)(20776003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/json/58v7IWdUmJx_8hGfIWM8FDvk0xA
Subject: [Json] merge-patch in APPSA and i-json in JSON
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jul 2014 17:27:16 -0000

I don't like to cross-post, but it seems appropriate for this narrow topic:

JSON WG is defining i-json profile in draft-ietf-json-i-json
APPSA WG is defining merge operation data structure in draft-ietf-appsawg-json-merge-patch 
Both are nearing WG last call.

Reading in prep for Toronto, I have questions I can't readily answer looking at the two documents:
- Does application/merge-patch+json require/default to the i-json profile?
- Is merge operation defined for target JSON that isn't i-json?
- If so, does it preserve i-json? (is the result i-json if the original was  i-json?
- Or is merge required to, or allowed to, ALWAYS produce i-json?

You'd think it should be easy to answer these questions given the two documents. Perhaps I'm missing the obvious. If there's a problem, I'm not sure which one would need to change. Possibly both. Could we see some editorial collaboration to make the answers clearer? 

Larry
--
http://larry.masinter.net