Re: [core-parameters] Content-Format for application/sdf+json

Carsten Bormann <cabo@tzi.org> Mon, 11 March 2024 12:35 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core-parameters@ietfa.amsl.com
Delivered-To: core-parameters@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33628C14F6BC for <core-parameters@ietfa.amsl.com>; Mon, 11 Mar 2024 05:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB37MsyegQ8Y for <core-parameters@ietfa.amsl.com>; Mon, 11 Mar 2024 05:34:58 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (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 4502DC14F6B8 for <core-parameters@ietf.org>; Mon, 11 Mar 2024 05:34:56 -0700 (PDT)
Received: from [192.168.217.145] (p548dcbf2.dip0.t-ipconnect.de [84.141.203.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Ttbnn33PDzDCgC; Mon, 11 Mar 2024 13:34:53 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <DU0P190MB197812E7D586FE73586F5110FD242@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
Date: Mon, 11 Mar 2024 13:34:52 +0100
Cc: "core-parameters@ietf.org" <core-parameters@ietf.org>
X-Mao-Original-Outgoing-Id: 731853292.25498-0cc7bad2a3f9c89f5d85426e3faa2b6a
Content-Transfer-Encoding: quoted-printable
Message-Id: <74E20465-DE83-4BA1-9718-1F0652F8EC25@tzi.org>
References: <02330D12-3DA3-463D-86BA-D53DCF98346E@tzi.org> <74264B36-059A-460D-A43B-170353F9A324@tzi.org> <DU0P190MB197812E7D586FE73586F5110FD242@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core-parameters/L5oh9Ye_0NUfLyVoJIyfmNMi3ls>
Subject: Re: [core-parameters] Content-Format for application/sdf+json
X-BeenThere: core-parameters@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Expert review of CoAP parameters." <core-parameters.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core-parameters/>
List-Post: <mailto:core-parameters@ietf.org>
List-Help: <mailto:core-parameters-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2024 12:35:04 -0000

Hi Esko,


On 2024-03-11, at 12:00, Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
> Maybe the draft could hint how this format is going to be used over CoAP? E.g. a future IoT device can host its own sdfThing description; or an action resource could have an associated sdfAction description hosted.

That is certainly possible, but SDF wasn’t really designed to be particularly good for this application.  Another application that is becoming more common is to use a content-format number in places like COSE’s “content type” (3) header parameter (RFC 9052) or in formats such as RFC 8710 or RFC 9193, or via Section 4.3 of RFC 9277.

More generally speaking, the availability of a content-format number for an IoT-related format is increasingly taken for granted — they also don’t cost much (at least the 2-byte variant), so we are registering these now as a matter of course.

> The registration looks good - allocation should be handled in the upcoming IANA review of the draft I think.

Right — it wouldn’t hurt to earmark a number, but it isn’t particularly needed at this point.

Grüße, Carsten