IETF Logo Mail Archive

[core] Re: [lamps] Re: EST /.well-known/est registry

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 16 July 2026 10:12 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@mail2.ietf.org
Delivered-To: core@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A01C6117BA4DC; Thu, 16 Jul 2026 03:12:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784196761; bh=TZcE2YRfJw+VNZBaP2Tepxe7gjR1s4SxWEfA5HVEibM=; h=From:To:Subject:In-Reply-To:References:Date; b=c6ezEOrV8K4LuO2z5BrdgcvhLjvoNOJXCyN7HVEFGEgZMAelGE7skpSKd0tKSKTQE 5x1WoBxik/W1Q4HZ3JhYb5Dlp9EsS1doSzyCxCTsIdLnTd/Bti31K9hze8pV9pFXMc jJObjDyZvsUaxG6bdnQDVE/7FVTTtjDbbdE8OpI0=
X-Virus-Scanned: amavisd-new at ietf.org
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_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_9Wwbn8JsCG; Thu, 16 Jul 2026 03:12:41 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 470E6117BA4D4; Thu, 16 Jul 2026 03:12:41 -0700 (PDT)
Received: from dyas.sandelman.ca (unknown [62.218.44.76]) by relay.sandelman.ca (Postfix) with ESMTPS id 88C681F685; Thu, 16 Jul 2026 10:12:40 +0000 (UTC)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 676B7A13F1; Thu, 16 Jul 2026 06:12:39 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>, Russ Housley <housley@vigilsec.com>, "lamps@ietf.org" <lamps@ietf.org>, "core@ietf.org" <core@ietf.org>
In-Reply-To: <PAXPR10MB4898AA503521E2E47CF1B11BFEC72@PAXPR10MB4898.EURPRD10.PROD.OUTLOOK.COM>
References: <15098.1783962252@obiwan.sandelman.ca> <870A3B63-2253-4695-9A51-A7EC6796BC91@vigilsec.com> <168979.1784050486@dyas> <PAXPR10MB4898485B7672C754037D8F1CFEF82@PAXPR10MB4898.EURPRD10.PROD.OUTLOOK.COM> <305759.1784124938@dyas> <PAXPR10MB4898AA503521E2E47CF1B11BFEC72@PAXPR10MB4898.EURPRD10.PROD.OUTLOOK.COM>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; Emacs 29.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 16 Jul 2026 12:12:39 +0200
Message-ID: <487109.1784196759@dyas>
Message-ID-Hash: YQMMMZ2HRIRTJ4OCYYQ5O3ZS3HG5KFEO
X-Message-ID-Hash: YQMMMZ2HRIRTJ4OCYYQ5O3ZS3HG5KFEO
X-MailFrom: mcr+ietf@sandelman.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-core.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [core] Re: [lamps] Re: EST /.well-known/est registry
List-Id: "Constrained RESTful Environments (CoRE) Working Group list" <core.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/hocPy_UJu-SglmexHj3jAP6qlTk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Owner: <mailto:core-owner@ietf.org>
List-Post: <mailto:core@ietf.org>
List-Subscribe: <mailto:core-join@ietf.org>
List-Unsubscribe: <mailto:core-leave@ietf.org>

Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> wrote:
    > Thank you for your quick review and pointing at RFC 8295 for further
    > path segments to be added.  However, I'm not sure if I fully understand
    > your suggestions. I'm not a CORE expert either.  My goal is simply to
    > include in this new register only the path segments as defined in other
    > RFCs.

Yes, you did a good initial job...
I'm suggesting that rather than having an entry for:
    /simpleenroll   7030
and /sen            9148

that we have a single entry:
    /simpleenroll, /sen, 302,            SimpleEnroll, 7030, 9148, uri-path-abbrev

    > If any extension to the path segment registration, e.g., based on
    > draft-ietf-core-uri-path-abbrev, is needed, I vote for doing so in a
    > rfc7030bis.

Yes, that would make sense...
I'm open to adding the third (abbrev) column in the uri-path-abbrev document
itself, but I think that uri-path-abbrev will get shipped first.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

v2.46.0 | Report a Bug | By Email | System Status