[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