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
- [core] WG Last Call on draft-ietf-core-problem-de… Marco Tiloca
- Re: [core] [httpapi] WG Last Call on draft-ietf-c… Roberto Polli
- Re: [core] [Cbor] [httpapi] WG Last Call on draft… Carsten Bormann
- Re: [core] [Cbor] [httpapi] WG Last Call on draft… Roberto Polli
- Re: [core] WG Last Call on draft-ietf-core-proble… Marco Tiloca
- Re: [core] WG Last Call on draft-ietf-core-proble… Thomas Fossati
- Re: [core] [Cbor] WG Last Call on draft-ietf-core… Carsten Bormann
- Re: [core] WG Last Call on draft-ietf-core-proble… Christian Amsüss
- Re: [core] WG Last Call on draft-ietf-core-proble… Thomas Fossati
- Re: [core] WG Last Call on draft-ietf-core-proble… Christian Amsüss
- Re: [core] [Cbor] WG Last Call on draft-ietf-core… Marco Tiloca
- Re: [core] WG Last Call on draft-ietf-core-proble… Thomas Fossati
- [core] Base-URI Re: [Cbor] WG Last Call on draft-… Carsten Bormann
- [core] "Ignore unknown" -- Re: [Cbor] WG Last Cal… Carsten Bormann
- Re: [core] [Cbor] WG Last Call on draft-ietf-core… Carsten Bormann
- Re: [core] Base-URI Re: [Cbor] WG Last Call on dr… Christian Amsüss