[core] Simplify draft-ietf-core-comi-12.txt

Carsten Bormann <cabo@tzi.org> Sat, 18 March 2023 21:23 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F2D21C14F73F for <core@ietfa.amsl.com>; Sat, 18 Mar 2023 14:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.486
X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6GdkvXk4j01Q for <core@ietfa.amsl.com>; Sat, 18 Mar 2023 14:23:27 -0700 (PDT)
Received: from smtp.uni-bremen.de (mail.uni-bremen.de []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81253C14F5E0 for <core@ietf.org>; Sat, 18 Mar 2023 14:23:26 -0700 (PDT)
Received: from [] (p548dc9a4.dip0.t-ipconnect.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 4PfDWH5rshzDCbK; Sat, 18 Mar 2023 22:23:23 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CF55D51C-4308-4951-88F1-205F1FE62753@tzi.org>
Date: Sat, 18 Mar 2023 22:23:23 +0100
X-Mao-Original-Outgoing-Id: 700867403.492543-7300893a5492e0c2de0366602384b58e
Content-Transfer-Encoding: quoted-printable
Message-Id: <71251F9E-9D4E-4724-8318-C66CAAFAC6A2@tzi.org>
References: <167873913517.793.14886599926050650204@ietfa.amsl.com> <CF55D51C-4308-4951-88F1-205F1FE62753@tzi.org>
To: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Pa2hbwmKiUc8657ry7KNr-0drYs>
Subject: [core] Simplify draft-ietf-core-comi-12.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 18 Mar 2023 21:23:33 -0000

In the interim last Wednesday, we were seriously wondering why we need both GET/PUT/POST and FETCH/iPATCH for COMI.  The consensus of the room was that the easiest way to solve the problems with generating the URIs for GET/PUT/POST was to move over to FETCH/iPATCH completely.

I have created a first draft of this “simplified” version of core-comi.
No base64 encoding any more…
All CoAP method/content-format combinations that would have required base64-encoding instance identifiers on a URI have been removed.

GET/PUT/POST/DELETE are still in there for full datastore access.
I’m not sure about the use case for this, but since it doesn’t need instance identifiers in a URI, I left it in.  Please advise.

I also simplified the POST request for RPC/Action to carry application/yang-instances+cbor as a payload.
This was a single "application/yang-data+cbor; id=sid", but this is now no longer used by CORECONF (*) (and it doesn't carry an instance identifier).

event-streams are still fetched using GET as all the information that is needed is in
the event stream URI, but I don’t know a good way to do ?f= on event stream resources.  Should this be moved to FETCH as well?

(*) I don’t know how to do errors in the way COMI has done them before.
These don’t cleanly map to application/yang-instances+cbor, as there is no data node involved.  (By now, we have RFC 9290…  Does this help here?)

Please view the draft draft at:


A diff from main (~ -12) can be seen at:



Grüße, Carsten