Re: [core] content-formats for cbor YANG

Michel Veillette <Michel.Veillette@trilliantinc.com> Thu, 20 April 2017 16:58 UTC

Return-Path: <Michel.Veillette@trilliantinc.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F696127078 for <core@ietfa.amsl.com>; Thu, 20 Apr 2017 09:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.702
X-Spam-Level:
X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com
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 9oldcvEc0Kqg for <core@ietfa.amsl.com>; Thu, 20 Apr 2017 09:58:25 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0133.outbound.protection.outlook.com [104.47.34.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E072128DE5 for <core@ietf.org>; Thu, 20 Apr 2017 09:58:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2PtIDX0bWM+WFGtTyd/a6wcoiBPUZUnts6Zwls7zL8I=; b=uY2/DiICXWdgRx55p5/Tqmnqs3dxP8BXDN2cdNzePrvFm1aKQMKO63vX25HB7/ph82FF+mKiUe+zElmMRHIT79BSTaHqGAkk+7DKa9WSCbSinh9SbkPqLBXUfS+6LID92uIIG2qp9TDbtbHAnco5COOzJ/RIUqw06yqEWUFFrJA=
Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Thu, 20 Apr 2017 16:58:24 +0000
Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.1034.018; Thu, 20 Apr 2017 16:58:24 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Carsten Bormann <cabo@tzi.org>
CC: peter van der Stok <consultancy@vanderstok.org>, Core <core@ietf.org>
Thread-Topic: [core] content-formats for cbor YANG
Thread-Index: AQHSubKXN7UA6+6dAE+n0rfEL3aqF6HN9EUAgABIYfCAABcJAIAAGQHggAAJIICAAAMmQA==
Date: Thu, 20 Apr 2017 16:58:24 +0000
Message-ID: <BN6PR06MB23088F3C7FB189B774466177FE1B0@BN6PR06MB2308.namprd06.prod.outlook.com>
References: <c2b6fb6e92c6a5680e544963e88d5fa7@xs4all.nl> <09BD739F-89A1-4DA7-9006-E30AEAEE581E@tzi.org> <BN6PR06MB230807D8EF9B69A473254077FE1B0@BN6PR06MB2308.namprd06.prod.outlook.com> <063c4a22d221667a92b180e5dce7ea1f@xs4all.nl> <BN6PR06MB2308B088FCC1DE8AD1370C4FFE1B0@BN6PR06MB2308.namprd06.prod.outlook.com> <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org>
In-Reply-To: <102478F5-703D-46C0-9A0B-A21454F940DB@tzi.org>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=trilliantinc.com;
x-originating-ip: [207.96.192.122]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 7:7hqs+dD7DwHn0xtIfBQx4xWvl8OBpAM1K4k1cK8RVMv8Kr59Vxau6aJD1sWYukQfVnYNW3lJTo0tUyH/HjbEs/RRE8N26WaSw+r9F41O0MahS2nuaCeaHF6lKDqKS96qDp1OBgX0sGp+FSknFEYUiWC9PuC32mnEUcNQaAWPraQJj2uc7y0oJ8nS5ASGQF5PRqQuEylCYRjEO3862rDJe0pbWj/FJGp4qQAJOCfRL3xkhK44aJuVM3IWABgZFTsR2HCgG3EebWDcXK5Iew/MmfIoDwAgG8GhMC3yJAbY05q3plLYlgPRDH7TpyUgb6uw45wShQj3zu4AOWqLXv4gMw==
x-ms-office365-filtering-correlation-id: b2bbf719-c9ed-498c-1fbd-08d4880e7521
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR06MB2308;
x-microsoft-antispam-prvs: <BN6PR06MB23088BFDD97E8D99B396F947FE1B0@BN6PR06MB2308.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308;
x-forefront-prvs: 02830F0362
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39450400003)(39410400002)(39400400002)(377454003)(57704003)(13464003)(24454002)(189998001)(8936002)(77096006)(6506006)(110136004)(7736002)(81166006)(8676002)(305945005)(38730400002)(25786009)(53546009)(6916009)(2950100002)(5890100001)(4326008)(54356999)(2906002)(3846002)(102836003)(53936002)(6116002)(93886004)(561944003)(6246003)(3280700002)(86362001)(2900100001)(7696004)(99286003)(122556002)(66066001)(3660700001)(50986999)(9686003)(229853002)(33656002)(74316002)(55016002)(54906002)(5660300001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 16:58:24.0225 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/YbnkXkxrdhWeGLqT30w51vmfpMY>
Subject: Re: [core] content-formats for cbor YANG
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Apr 2017 16:58:27 -0000

Hi Carsten and thanks for your comments.

About (application/yang-set+cbor)
Do you propose to use it only for iPATCH /c request ?
Or also for GET /c response, PUT /c request and POST /c request ?

If we move in that direction (structural interoperability), do we need to define a different Content-Format for each one used by CoMI?
- value
- CBOR array (instance-identifier)
- CBOR array (value)
- CBOR array (instance-identifier, value)

Regards,
Michel

-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: Thursday, April 20, 2017 12:39 PM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: peter van der Stok <consultancy@vanderstok.org>; Core <core@ietf.org>
Subject: Re: [core] content-formats for cbor YANG


> On Apr 20, 2017, at 18:21, Michel Veillette <Michel.Veillette@trilliantinc.com> wrote:
> 
> Hi Peter
> 
> It still unclear to me what is the role of the CoAP method vs. the role of the Content-Format.
> The PUT, POST and iPATCH methods all share the same payload (i.e. CBOR array (instance-identifier, value)).
> 
> - In the case of the PUT, the existing datastore is deleted and replaced by the provided payload.
> - In the case of the POST, a new datastore is created with the provided payload.
> - In the case of the iPATCH, the existing datastore is updated based on the provided payload.
> 
> For these three use cases, the method defines what to do with the payload, not the Content-Format.
> My question is why iPATCH required a different Content-Format when PUT and POST use the same?

That is a good question.

We definitely need a different format for the FETCH request body, which is a list of IDs, not a set of ID-value pairs.  (We used to have this argument whether the response should be just a list of values or that set; I think we are now at the set selected, which is strictly speaking a bit different from the representation of the whole resource.)

The body of an (i)PATCH is different in meaning, not in structure, from the representation bearing formats.  It is a bit of a taste thing whether we attach media types to semantics or to structural interoperability.

I didn’t have a problem with Peter’s original proposal:

> Draft-ietf-core-yang-cbor deines the content-format application/yang+cbor which defines CBOR documents which contain the results of the mapping of a YANG document to CBOR as specified in the draft.
> 
> Draft-ietf-core-comi defines two additional content-formats:
> 1) application/yang-fetch+cbor that specifies the contents and semantics of a FETCH CoMI request payload
> 2) application/yang-patch+cbor that specifies the contents and semantics of a PATCH CoMI request payload

Just calling the thing application/cbor just tells us the serialization format, by the way; this is a bit like sending text/html as text/plain because any text also is structurally compatible with the latter.

Andy’s argument that yang-patch is taken for the different yang-patch format used with XML/JSON is a good one.  Note that there is no coap in the comi patch format either, so I don’t like application/coap-patch+cbor.  Right now I’m favoring application/yang-set+cbor.

Grüße, Carsten