[core] Re: I-D Action: draft-ietf-core-uri-path-abbrev-02.txt
Jon Shallow <supjps-ietf@jpshallow.com> Fri, 24 October 2025 09:40 UTC
Return-Path: <supjps-ietf@jpshallow.com>
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 652C67B8EFB3 for <core@mail2.ietf.org>; Fri, 24 Oct 2025 02:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=jpshallow.com
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 x2GccrtQ_fBU for <core@mail2.ietf.org>; Fri, 24 Oct 2025 02:40:35 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [31.22.13.189]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D92797B8EFAE for <core@ietf.org>; Fri, 24 Oct 2025 02:40:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jpshallow.com; s=key; h=Sender:Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q71T2wZBzTo3RAgONZXfGu8JM2q2UotThNv3Qyh1j5A=; b=HsAZaOOeeNh7eS6q+YJGsfeb/z 6hkm6OvxgJXgXUxKUrWMg5apRQ44bIs/HxgPKgeCIUJpmxMasF/ZRzKiD83vzbLuD7HlHM62fCGQk VZLzsTuQmtbhIcvfAC99wmsJfY+wpVVNNtDYwJM9q2XYQywWw7buxO8FYg8Tv/52SIkDzl2sQY961 zI9CLB36lacshcrRNbatqI5M67g+d+XFyKzQXHf7Annrddq1b2idLVFd5fyA1jzhLPCkLUX5NKQcT jtHCmTDBIsoipEjkAozmFzWBHD81d9mitdfcm5nwaeEU8idhAcr7qPS5Qgv/qfc6PLm7J/nu+lFSD Fj2MIt1g==;
Received: from router.jpshallow.com ([192.168.0.1] helo=DESKTOP433R5TL) by mail.jpshallow.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <jon@jpshallow.com>) id 1vCEHb-0007EX-OW; Fri, 24 Oct 2025 10:40:27 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: 'Christian Amsüss' <christian@amsuess.com>
References: <176096824970.2064129.8396930767660720618@dt-datatracker-84f8f646b-tg6mn> <aPZAKfIwf7s3cGTN@hephaistos.amsuess.com> <001601dc43fb$4dac6bf0$e90543d0$@jpshallow.com> <aPnwnB51Uz6QZ5RY@hephaistos.amsuess.com>
In-Reply-To: <aPnwnB51Uz6QZ5RY@hephaistos.amsuess.com>
Date: Fri, 24 Oct 2025 10:40:27 +0100
Message-ID: <015001dc44ca$3adf2f60$b09d8e20$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMO11L73KjfYSzX4XGFzmVvPnhX4QJnjRo6AFQmUGwB/cQxKLJGED8Q
Content-Language: en-gb
Sender: supjps-ietf@jpshallow.com
Message-ID-Hash: U55MKK2GSUCGUUGTGFZ2RIJHAQJK56YV
X-Message-ID-Hash: U55MKK2GSUCGUUGTGFZ2RIJHAQJK56YV
X-MailFrom: supjps-ietf@jpshallow.com
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
CC: core@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: supjps-ietf@jpshallow.com
Subject: [core] Re: I-D Action: draft-ietf-core-uri-path-abbrev-02.txt
List-Id: "Constrained RESTful Environments (CoRE) Working Group list" <core.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/9aXwUrb8nrs4GfImpfetwPgETcw>
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>
Hi Christian, I don't have any concrete examples where discovering UPA helps - apart from perhaps a multicast scenario where there may be legacy servers responding. Also "in which case discovery can indicate a short non-well-known URI" which is similar to also reporting the upa=nnn as an alternative for clients that can use it. "concerns of lifetime" leads me to ask - should we have a Location-Path-Abbrev in a response where the server after (POST/PUT) dynamically adds in a new Uri-Path-Abbrev mapping? Appreciate the client is likely to remove that dynamic resource with a DELETE (and hence should know better), but a 4.02 response following a later use of the Uri-Path-Abbrev mapping for the now deleted resource is a bit confusing compared to a (not allowed) 4.04. This then leads me to ask - if the server understands Uri-Path-Abbrev, but not the particular value, should the response be, say, 4.07 (Specific Uri-Path-Abbrev value not supported)? Regards Jon -----Original Message----- From: 'Christian Amsüss' <christian@amsuess.com> Sent: 23 October 2025 10:09 To: Jon Shallow <supjps-ietf@jpshallow.com> Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-uri-path-abbrev-02.txt > Should a response to .well-known/core include something like a 'upa=nnn' > attribute for any known Uri-Path-Abbrev option values to indicate that > this resource can be accessed using Uri-Path-Abbrev? I don't think so. .well-known URIs are there because something is used without prior discovery. Either support for something is discovered (in which case discovery can indicate a short non-well-known URI), or it is available without discovery (in which case Uri-Path-Abbrev makes sense). Also, discovery carries with it concerns of lifetime (the time that any discovered EST resources would be available for was part of the early discussion), and leaving this out simplifies things. Do you have any concrete example where you think discovery of an UPA would be useful? (Best that comes to mind for me is .well-known/edhoc, but for that there's the updated ACE EDHOC profile document that just makes support for the compressed form mandatory, and thus discovery moot.) BR c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [core] I-D Action: draft-ietf-core-uri-path-abbre… internet-drafts
- [core] Re: I-D Action: draft-ietf-core-uri-path-a… Christian Amsüss
- [core] Re: I-D Action: draft-ietf-core-uri-path-a… Jon Shallow
- [core] Re: I-D Action: draft-ietf-core-uri-path-a… 'Christian Amsüss'
- [core] Re: I-D Action: draft-ietf-core-uri-path-a… Michael Richardson
- [core] Re: I-D Action: draft-ietf-core-uri-path-a… Jon Shallow
- [core] Re: I-D Action: draft-ietf-core-uri-path-a… Esko Dijk
- [core] Re: I-D Action: draft-ietf-core-uri-path-a… Michael Richardson
- [core] Re: I-D Action: draft-ietf-core-uri-path-a… Esko Dijk