Re: [core] Base-URI Re: [Cbor] WG Last Call on draft-ietf-core-problem-details

Christian Amsüss <christian@amsuess.com> Wed, 25 May 2022 13:33 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 96E7CC1D3C66; Wed, 25 May 2022 06:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 pLdpXhd9Wgzt; Wed, 25 May 2022 06:33:31 -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 4BD2EC1D3C67; Wed, 25 May 2022 06:33:27 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 24PDXNNK056357 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 May 2022 15:33:24 +0200 (CEST) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 063476865; Wed, 25 May 2022 15:33:23 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:21f0:500d:337c:8605]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AAAF4A776; Wed, 25 May 2022 15:33:22 +0200 (CEST)
Received: (nullmailer pid 809539 invoked by uid 1000); Wed, 25 May 2022 13:33:22 -0000
Date: Wed, 25 May 2022 15:33:22 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: draft-ietf-core-problem-details@ietf.org, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, cbor@ietf.org, httpapi@ietf.org
Message-ID: <Yo4wIupTzAARkYWm@hephaistos.amsuess.com>
References: <3a2fb1c8-5c50-fa7a-0672-a73c3b6f1a5f@ri.se> <YoesjAXIKQS+PBLX@hephaistos.amsuess.com> <18CB1C8E-651F-48C9-8D32-55E1CAEDC63D@tzi.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="0bubBDRHkYZukmWb"
Content-Disposition: inline
In-Reply-To: <18CB1C8E-651F-48C9-8D32-55E1CAEDC63D@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/j25pzrq7AWOKWPN3nE4vMpwnjVA>
Subject: Re: [core] Base-URI Re: [Cbor] WG Last Call on draft-ietf-core-problem-details
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.34
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: Wed, 25 May 2022 13:33:37 -0000

> Exactly (after s/URIs/URI references/).  
> So resolving the instance URI reference is not enough; preserving more of the context would be.

The changes currently in
https://github.com/core-wg/core-problem-details/pull/18 address my
concern here by the introduction of a base URI.

While I'd have preferred an outcome of removing the response code, and
making it up to the application to persist both response code and base
URI as a part of the context (which would make the road to CoRAL both
smoother and more interesting to users), this is satisfactory, and does
not limit the scope of what we can do later in a CoRAL based version.

> There probably should be a general means for preserving a base URI
> with a stored (or otherwise uprooted) representation of response
> content (think file-magic…).

Yes, and I've taken this up for exploration at
https://github.com/core-wg/coral/issues/27.

> Let’s discuss this today.

See you there
c

-- 
Beware paths which narrow future possibilities. Such paths divert you from infinity into lethal traps.
  -- Leto Atreides II