IETF Logo Mail Archive

Re: [httpapi] [Last-Call] [Ext] Re: Last Call: <draft-ietf-httpapi-rfc7807bis-04.txt> (Problem Details for HTTP APIs) to Proposed Standard

Erik Wilde <erik.wilde@dret.net> Wed, 16 November 2022 15:06 UTC

Return-Path: <erik.wilde@dret.net>
X-Original-To: httpapi@ietfa.amsl.com
Delivered-To: httpapi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A2CC14CEE9 for <httpapi@ietfa.amsl.com>; Wed, 16 Nov 2022 07:06:51 -0800 (PST)
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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 iUgs_5lmCq6e for <httpapi@ietfa.amsl.com>; Wed, 16 Nov 2022 07:06:49 -0800 (PST)
Received: from mxout014.mail.hostpoint.ch (mxout014.mail.hostpoint.ch [IPv6:2a00:d70:0:e::314]) (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 7B5F7C14CF03 for <httpapi@ietf.org>; Wed, 16 Nov 2022 07:06:48 -0800 (PST)
Received: from [10.0.2.46] (helo=asmtp013.mail.hostpoint.ch) by mxout014.mail.hostpoint.ch with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from <erik.wilde@dret.net>) id 1ovJzw-000Aee-Lr; Wed, 16 Nov 2022 16:06:44 +0100
Received: from [185.132.19.16] (helo=[192.168.1.167]) by asmtp013.mail.hostpoint.ch with esmtpa (Exim 4.95 (FreeBSD)) (envelope-from <erik.wilde@dret.net>) id 1ovJzw-000Kxg-HA; Wed, 16 Nov 2022 16:06:44 +0100
X-Authenticated-Sender-Id: erik.wilde@dret.net
Message-ID: <dbf69cb9-f88e-664a-8d87-ef6c44222bf9@dret.net>
Date: Wed, 16 Nov 2022 16:06:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: Julian Reschke <julian.reschke@gmx.de>, httpapi@ietf.org
References: <166627224606.10641.5749459667185024591@ietfa.amsl.com> <A98333C4-1FBB-4212-A378-818BCF61F093@tzi.org> <4754b49e-2aac-1059-c401-4ec3275ac46c@dret.net> <CFE79F91-1D2E-4733-A513-9DF6D71A3E52@tzi.org> <fb6f0eb5-177b-2b5d-73e4-7fecd2e8cf69@dret.net> <C4C39022-F299-4D3A-922E-481B1FBB5960@tzi.org> <5ffcf5ad-a530-a36d-14c4-5cb5cf8afce2@dret.net> <E73ED1FB-54A0-4E43-8E23-F926F3073BC5@tzi.org> <c70e846a-5668-60ef-cb60-1ea644642262@it.aoyama.ac.jp> <9A5D3E4F-C633-46A4-AF07-9E9136E61714@iana.org> <7404085B-FA52-4CE0-8120-92649C705ECC@mnot.net> <a89328b5-0ba1-49d7-30bc-f813eede4fc2@bucksch.org> <4ebb2a9c-d9c7-2e1d-b4e1-4763c9b81959@dret.net> <b1181f51-6df9-fe13-93b9-b9d513727cd9@bucksch.org> <50dcffb3-f1f3-a943-f467-2a765442c1fd@gmx.de>
From: Erik Wilde <erik.wilde@dret.net>
In-Reply-To: <50dcffb3-f1f3-a943-f467-2a765442c1fd@gmx.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/hZd9lnzEkWebJyPYNKJPaUe_vpA>
Subject: Re: [httpapi] [Last-Call] [Ext] Re: Last Call: <draft-ietf-httpapi-rfc7807bis-04.txt> (Problem Details for HTTP APIs) to Proposed Standard
X-BeenThere: httpapi@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/httpapi>, <mailto:httpapi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi/>
List-Post: <mailto:httpapi@ietf.org>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpapi>, <mailto:httpapi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2022 15:06:51 -0000

On 2022-11-16 13:26, Julian Reschke wrote:
> On 16.11.2022 12:03, Ben Bucksch wrote:
>> Personally, the solution I prefer is to change the definition of the
>> "type" field from a URI to a string. This still permits all current
>> values. It also makes the whole spec a lot more approachable for
>> developers, because type being a URI seems to be a common obstacle.
>> ...
> Unfortunately, you'll loose the most important property: being an
> identifier not requiring a registry.

that, and we cannot change data types that way and remain compatible. 
old code has to work with new error messages, and that old code is 
expecting types to be URIs. changing that type to a less constrained one 
(such as changing URI to string) would be a breaking change.

cheers,

dret.

-- 
Erik Wilde | mailto:erik.wilde@dret.net    |
            | https://youtube.com/ErikWilde |

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