IETF Logo Mail Archive

Re: [core] I-D Action: draft-ietf-core-transport-indication-05.txt

Christian Amsüss <christian@amsuess.com> Tue, 19 March 2024 06:05 UTC

Return-Path: <christian@amsuess.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 358E8C14F70A for <core@ietfa.amsl.com>; Mon, 18 Mar 2024 23:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 2dXfJGqoD9M3 for <core@ietfa.amsl.com>; Mon, 18 Mar 2024 23:05:39 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (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 0959CC14EB17 for <core@ietf.org>; Mon, 18 Mar 2024 23:05:37 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.2/8.17.2) with ESMTPS id 42J65abx007561 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <core@ietf.org>; Tue, 19 Mar 2024 07:05:36 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 08A4735D71 for <core@ietf.org>; Tue, 19 Mar 2024 07:05:35 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bfbd:e9f4:2c0a:95da]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0D8F032469 for <core@ietf.org>; Tue, 19 Mar 2024 07:05:34 +0100 (CET)
Received: (nullmailer pid 27767 invoked by uid 1000); Tue, 19 Mar 2024 06:05:33 -0000
Date: Tue, 19 Mar 2024 16:05:33 +1000
From: Christian Amsüss <christian@amsuess.com>
To: core@ietf.org
Message-ID: <ZfkrLT9PscS8b-m4@hephaistos.amsuess.com>
References: <171082427050.47754.4609453808533073649@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="JfSFvREf/s+QroAc"
Content-Disposition: inline
In-Reply-To: <171082427050.47754.4609453808533073649@ietfa.amsl.com>
X-Scanned-By: MIMEDefang 2.86
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Te89Dw5Edsx8N6KymowWmHMWPVs>
Subject: Re: [core] I-D Action: draft-ietf-core-transport-indication-05.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: Tue, 19 Mar 2024 06:05:41 -0000

Hello CoRE,

On Mon, Mar 18, 2024 at 09:57:50PM -0700, internet-drafts@ietf.org wrote:
>    Name:    draft-ietf-core-transport-indication-05.txt

the -04 update before the cut-off added appendices resulting from
IETF118 discussions, on how SVCB could have been used (no attempt to
retrofit it because the parts where that would have helped already have
their schemes) and where it falls short (sketching what would be needed
to make SVCB parameters available in literals). I did not manage to
apply the results of these appendices and the IETF118 (esp. T2TRG)
discussions to the rest of the document in time for the cut-off, but -05
now covers them.

In particular, there is now an explicit section 6 guiding upcoming
transports in their choice of schemes, describing how to use coap://
URIs in any new protocols, by example of CoAP-over-GATT (which has
consequentially been updated to use coap://001122334455.ble.arpa/ style
URIs) and slipmux (which I'd love to see updated).

Best regards
Christian

-- 
We are dreamers, shapers, singers, and makers.
  -- Elric

v2.23.0 | Report a Bug | By Email